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