Re: martin fowler and jsp evils...

In addition to the message I just posted in reply to email, I thought I'd
add one thing I forgot.

You can always provide alternate stylesheets which users can choose from
and may make permanent via a cookie to store the state of this stylesheet
they prefer.  For an example, check out this page I made for a
demonstration.

http://www.visi.com/~hoju/barracuda/barracuda.html

Click the radio buttons near the top of the page to change the
stylesheet.  Notice how drastic the difference can be between
alternate stylesheets!  Choose the second or third radio button and
then close your browser.  Now open the browser back up and come back
to the page.  Notice that you are viewing the stylesheet which you
last chose before you left the page previously?  Cool, 
heh?

You really should look at the page in Mozilla or a Mozilla
derivative.   It is amazing what one can do in Mozilla. 
IE work, buggily.  Opera gets it mostly right, but still doesn't
look pretty like Mozila.

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