Subject: Re: martin fowler and jsp evils... - msg#00017

Previous Message by Date: click to view message preview

Re: Re: Xmlc: error reporting (was : martin fowler and jsp evils...)

I am glad to see the eclipse plug-in for XMLC. Would you consider developing it using 2.2 instead of 2.1? I would consider it, certainly. Is there a list of differences? The compiling error of XMLC (and runtime errors) are directed to an XMLCLogger. The default implementation of this interface is to used to stderr. The Logger's API has been changed a bit between 2.1 and 2.2. The stream used by the logger is no longer exposed so Log4J or logging in JDK 1.4 can be plug in. Thanks. David Li On Wednesday, Jan 15, 2003, at 00:14 Asia/Shanghai, <dcorbin@xxxxxxxxxxxxxx> wrote: Hi All, So, I'm hoping to get Martin on board with xmlc and the value of DOM-based presentation development. Seeing the posting about http://xmlceclipse.sourceforge.net really pumped me up. This community needs folks to beat the drum and get the word out. xmlc is still one of the best kept secrets out there. Yes. As the primary developer of this plugin, let me take the opportunity to plead for more help! I know we're all juggling lot of balls, but any help would be appreciated. I have a specific question, and I have not *recently* delved into the XMLC source. It seems to me the last time I was there, that errors/warnings when compiling XMLC where shot straight to stderr without any higher-level mechanism. Is this correct? Is this a byproduct of using many different parsers? Correct reporting of errors in Eclipse is going to be hard if it continues this way. David Corbin _______________________________________________ XMLC mailing list XMLC@xxxxxxxxxxx http://www.enhydra.org/mailman/listinfo.cgi/xmlc _______________________________________________ XMLC mailing list XMLC@xxxxxxxxxxx http://www.enhydra.org/mailman/listinfo.cgi/xmlc

Next Message by Date: click to view message preview

Re: martin fowler and jsp evils...

Hi David, Well, what a coincidence...or maybe I obtained the info from reading that page a while ago and now it is just part of my lexicon thanks to your great book :-) One way around the accessibility issues is to provide a user with a set of CSS classes which they can add to their user stylesheet.  They can override any CSS class declarations with their own.  Both Opera and Mozilla support user stylesheets.  I think IE5 Mac also supports them. Try them out in Mozilla by looking in your "chrome" directory under your Mozilla or Phoenix profiles directory (for the appropriate user).  Look for the "userContent-example.js".  Copy that to "userContent.js".  Now add any CSS declarations you want.  Here is one I've added to make browsing Microsoft's knowledge base articles a nicer experience... /* Fix for Microsoft Knowledge Base articles, to stop the overlapping text. */ .KBPUBV2 LI, .KBPUBV2 OL LI, .KBPUBV2 UL LI, .KBPUBV2 UL UL, .KBPUBV2 UL UL LI, .KBPUBV2 .appliesto, .KBPUBV2 .appliesto UL, .KBPUBV2 .appliesto UL UL, .KBPUBV2 .appliesto UL LI, .KBPUBV2 .postappliesto, .KBPUBV2 .postappliesto UL, .KBPUBV2 .postappliesto UL UL, .KBPUBV2 .postappliesto UL LI {     margin: 5px !important; } Note the !important rule which will override even author-specified !important rules. Other than this, what does Apple suggest here?  There are best-practices in using CSS to account for those with various impairments to vision or colorblindness.  It just needs to be very carefully planned out which doesn't often happen in web development.  Maybe this is something that should be written as a white paper for XMLC developers.  Not only would it encourage even cleaner separation of presentation from logic, but it would also make it so that developers wouldn't have to reinvent the wheel every time they want to do something like this.  There is just no time to reinvent anything these days. Jake At 08:13 PM 1/14/2003 -0700, you wrote: Hi Jacob! In my xmlc book (page 66), I reflect your initial approach below. Mapped to the $10 thing, it's something like... if ( amount >= $10) //pseudocode     cell.getAttributeNode("class").setValue("dollarAmountMore"} else    cell.getAttributeNode("class").setValue("dollarAmountLess"} Then I relied on the CCS file to associate the appropriate color (or whatever) to the class.  The issue/consideration is "accessibility" as Apple likes to call it.  If you have the attribute behavior embedded in your business rules, or generated on the fly, then a person who is color blind cannot change the "red" to be "bold" or whatever works for that individual. David Jacob Kjome wrote: Hello David, In that case, I'd have a CSS file defining classes called "dollarAmountLess" and "dollarAmountMore" and use it like this... <span id="DollarAmount" class="dollarAmountLess">[$8.00] mockup data</span> I would use XMLC to modify this class to the appropriate value depending on what the business rules tell me about the state of this piece of data. Then, in my css file, I'd have: .dollarAmountMore { color: blue; } .dollarAmountless { color: red; } That would be a simple case taking advantage of standard XMLC programming and standard static CSS.  The disadvantage of this is that as soon as you come up with a new business rule of, say, a case where a dollar amount between 10 and 15 dollars is to be green, then you have to go in an update your business rules and the CSS with newly defined classes to account for the new rule.  The XMLC logic could stay the same because the business rule would be sending a string which the XMLC logic would blindly plop into the class value for the DolarAmount element. The alternative would be to generate dynamic CSS.  In that case, you could have: <span id="DollarAmount" class="dollarAmount">[$8.00] mockup data</span> In this case, you need no XMLC logic whatsoever because the class is already there in the template (unless you wanted to add it just in case your developer didn't add it).  Your business rules would determine the value and then generate dynamic CSS to define the dollarAmount class to have the corresponding features such as... .dollarAmount { color: red; } The <link> element pointing to the CSS would just be a dynamic URL which would return a CSS stream with the dynamically set value. The disadvantage to this is that it is a bit more involved in implementing and might add extra load to the server, although the details might take advantage of some smartness to allow for caching of some sort. Otherwise, dynamic _javascript_ could be generated.  In that case, you'd just use the Browser DOM to access the DollarAmount element and set the color of that node via the DOM rather than through CSS.  In this case, you'd use dynamically streamed _javascript_ rather than dynamically streamed CSS.  You wouldn't even need the classname there anymore. I think the latter two strategies provide the most separation from the presentation since they don't rely on multiple class names like the first case.  In all cases, this logic to enable this to work is outside of the XMLC template itself. Anyone else have ideas about this? Jake Tuesday, January 14, 2003, 12:53:58 PM, you wrote: JSPs: He then launched into the evils of JSP and how they threaten good layering more than any other aspect of J2EE. E.g., task: turn a dollar amount red if less than $10.  Most often, JSP developers will stick the business logic in the JSP rather than confine it to the Domain layer.  It's just too easy to do violate good layering when using JSPs. DL> However, our problem would be how do I make it red with DOM? ;) DL> I think we should start a XMLC patterns that suggest the best practice DL> of using the DOM API to accomplish common tasks. I have asked the group DL> to send me codes of their practices of XMLC. I could compile a list of DL> common patterns for XMLC while I am at it. DL> David Li DL> _______________________________________________ DL> XMLC mailing list DL> XMLC@xxxxxxxxxxx DL> http://www.enhydra.org/mailman/listinfo.cgi/xmlc -- David H. Young 1.831.246.1692 (cell) http://www.kspar.net _______________________________________________ XMLC mailing list XMLC@xxxxxxxxxxx http://www.enhydra.org/mailman/listinfo.cgi/xmlc

Previous Message by Thread: click to view message preview

Re[2]: martin fowler and jsp evils...

Hello David, In that case, I'd have a CSS file defining classes called "dollarAmountLess" and "dollarAmountMore" and use it like this... <span id="DollarAmount" class="dollarAmountLess">[$8.00] mockup data</span> I would use XMLC to modify this class to the appropriate value depending on what the business rules tell me about the state of this piece of data. Then, in my css file, I'd have: .dollarAmountMore { color: blue; } .dollarAmountless { color: red; } That would be a simple case taking advantage of standard XMLC programming and standard static CSS. The disadvantage of this is that as soon as you come up with a new business rule of, say, a case where a dollar amount between 10 and 15 dollars is to be green, then you have to go in an update your business rules and the CSS with newly defined classes to account for the new rule. The XMLC logic could stay the same because the business rule would be sending a string which the XMLC logic would blindly plop into the class value for the DolarAmount element. The alternative would be to generate dynamic CSS. In that case, you could have: <span id="DollarAmount" class="dollarAmount">[$8.00] mockup data</span> In this case, you need no XMLC logic whatsoever because the class is already there in the template (unless you wanted to add it just in case your developer didn't add it). Your business rules would determine the value and then generate dynamic CSS to define the dollarAmount class to have the corresponding features such as... .dollarAmount { color: red; } The <link> element pointing to the CSS would just be a dynamic URL which would return a CSS stream with the dynamically set value. The disadvantage to this is that it is a bit more involved in implementing and might add extra load to the server, although the details might take advantage of some smartness to allow for caching of some sort. Otherwise, dynamic Javascript could be generated. In that case, you'd just use the Browser DOM to access the DollarAmount element and set the color of that node via the DOM rather than through CSS. In this case, you'd use dynamically streamed Javascript rather than dynamically streamed CSS. You wouldn't even need the classname there anymore. I think the latter two strategies provide the most separation from the presentation since they don't rely on multiple class names like the first case. In all cases, this logic to enable this to work is outside of the XMLC template itself. Anyone else have ideas about this? Jake Tuesday, January 14, 2003, 12:53:58 PM, you wrote: >> JSPs: He then launched into the evils of JSP and how they threaten good >> layering more than any other aspect of J2EE. >> E.g., task: turn a dollar amount red if less than $10. Most often, JSP >> developers will stick the business logic in the JSP rather than confine >> it to the Domain layer. It's just too easy to do violate good layering >> when using JSPs. DL> However, our problem would be how do I make it red with DOM? ;) DL> I think we should start a XMLC patterns that suggest the best practice DL> of using the DOM API to accomplish common tasks. I have asked the group DL> to send me codes of their practices of XMLC. I could compile a list of DL> common patterns for XMLC while I am at it. DL> David Li DL> _______________________________________________ DL> XMLC mailing list DL> XMLC@xxxxxxxxxxx DL> http://www.enhydra.org/mailman/listinfo.cgi/xmlc -- Best regards, Jacob mailto:hoju@xxxxxxxx

Next Message by Thread: click to view message preview

Re: martin fowler and jsp evils...

Hi David, Well, what a coincidence...or maybe I obtained the info from reading that page a while ago and now it is just part of my lexicon thanks to your great book :-) One way around the accessibility issues is to provide a user with a set of CSS classes which they can add to their user stylesheet.  They can override any CSS class declarations with their own.  Both Opera and Mozilla support user stylesheets.  I think IE5 Mac also supports them. Try them out in Mozilla by looking in your "chrome" directory under your Mozilla or Phoenix profiles directory (for the appropriate user).  Look for the "userContent-example.js".  Copy that to "userContent.js".  Now add any CSS declarations you want.  Here is one I've added to make browsing Microsoft's knowledge base articles a nicer experience... /* Fix for Microsoft Knowledge Base articles, to stop the overlapping text. */ .KBPUBV2 LI, .KBPUBV2 OL LI, .KBPUBV2 UL LI, .KBPUBV2 UL UL, .KBPUBV2 UL UL LI, .KBPUBV2 .appliesto, .KBPUBV2 .appliesto UL, .KBPUBV2 .appliesto UL UL, .KBPUBV2 .appliesto UL LI, .KBPUBV2 .postappliesto, .KBPUBV2 .postappliesto UL, .KBPUBV2 .postappliesto UL UL, .KBPUBV2 .postappliesto UL LI {     margin: 5px !important; } Note the !important rule which will override even author-specified !important rules. Other than this, what does Apple suggest here?  There are best-practices in using CSS to account for those with various impairments to vision or colorblindness.  It just needs to be very carefully planned out which doesn't often happen in web development.  Maybe this is something that should be written as a white paper for XMLC developers.  Not only would it encourage even cleaner separation of presentation from logic, but it would also make it so that developers wouldn't have to reinvent the wheel every time they want to do something like this.  There is just no time to reinvent anything these days. Jake At 08:13 PM 1/14/2003 -0700, you wrote: Hi Jacob! In my xmlc book (page 66), I reflect your initial approach below. Mapped to the $10 thing, it's something like... if ( amount >= $10) //pseudocode     cell.getAttributeNode("class").setValue("dollarAmountMore"} else    cell.getAttributeNode("class").setValue("dollarAmountLess"} Then I relied on the CCS file to associate the appropriate color (or whatever) to the class.  The issue/consideration is "accessibility" as Apple likes to call it.  If you have the attribute behavior embedded in your business rules, or generated on the fly, then a person who is color blind cannot change the "red" to be "bold" or whatever works for that individual. David Jacob Kjome wrote: Hello David, In that case, I'd have a CSS file defining classes called "dollarAmountLess" and "dollarAmountMore" and use it like this... <span id="DollarAmount" class="dollarAmountLess">[$8.00] mockup data</span> I would use XMLC to modify this class to the appropriate value depending on what the business rules tell me about the state of this piece of data. Then, in my css file, I'd have: .dollarAmountMore { color: blue; } .dollarAmountless { color: red; } That would be a simple case taking advantage of standard XMLC programming and standard static CSS.  The disadvantage of this is that as soon as you come up with a new business rule of, say, a case where a dollar amount between 10 and 15 dollars is to be green, then you have to go in an update your business rules and the CSS with newly defined classes to account for the new rule.  The XMLC logic could stay the same because the business rule would be sending a string which the XMLC logic would blindly plop into the class value for the DolarAmount element. The alternative would be to generate dynamic CSS.  In that case, you could have: <span id="DollarAmount" class="dollarAmount">[$8.00] mockup data</span> In this case, you need no XMLC logic whatsoever because the class is already there in the template (unless you wanted to add it just in case your developer didn't add it).  Your business rules would determine the value and then generate dynamic CSS to define the dollarAmount class to have the corresponding features such as... .dollarAmount { color: red; } The <link> element pointing to the CSS would just be a dynamic URL which would return a CSS stream with the dynamically set value. The disadvantage to this is that it is a bit more involved in implementing and might add extra load to the server, although the details might take advantage of some smartness to allow for caching of some sort. Otherwise, dynamic _javascript_ could be generated.  In that case, you'd just use the Browser DOM to access the DollarAmount element and set the color of that node via the DOM rather than through CSS.  In this case, you'd use dynamically streamed _javascript_ rather than dynamically streamed CSS.  You wouldn't even need the classname there anymore. I think the latter two strategies provide the most separation from the presentation since they don't rely on multiple class names like the first case.  In all cases, this logic to enable this to work is outside of the XMLC template itself. Anyone else have ideas about this? Jake Tuesday, January 14, 2003, 12:53:58 PM, you wrote: JSPs: He then launched into the evils of JSP and how they threaten good layering more than any other aspect of J2EE. E.g., task: turn a dollar amount red if less than $10.  Most often, JSP developers will stick the business logic in the JSP rather than confine it to the Domain layer.  It's just too easy to do violate good layering when using JSPs. DL> However, our problem would be how do I make it red with DOM? ;) DL> I think we should start a XMLC patterns that suggest the best practice DL> of using the DOM API to accomplish common tasks. I have asked the group DL> to send me codes of their practices of XMLC. I could compile a list of DL> common patterns for XMLC while I am at it. DL> David Li DL> _______________________________________________ DL> XMLC mailing list DL> XMLC@xxxxxxxxxxx DL> http://www.enhydra.org/mailman/listinfo.cgi/xmlc -- David H. Young 1.831.246.1692 (cell) http://www.kspar.net _______________________________________________ XMLC mailing list XMLC@xxxxxxxxxxx http://www.enhydra.org/mailman/listinfo.cgi/xmlc