I used XSLT as a template mechanism and my feeling is that it is too heavy
and too problematic for that purpose. WebMacro, Velocity and FreeMarker
are less problematic and lighter.

I have seen people trying to use XSLT for business logic just because they
want to do everything with it, and they turned simple problems into very
complicated ones. Just take a look at the XSLT mailing list archives and
you too will have e good idea of what I am talking about.

With designers and "scripters", it gets even worse:
 - They can not use DreamWeaver and other visual design tools to
   manipulate the template;
 - They don't really understand the idea behind XSLT that affects many of
   its constructions (the stream of nodes thing and how transformations
   pipe those nodes);
 - They get lost with syntax issues all the time, even stumbling in things
   like the importance of the value in the "xmlns:xsl" property in the
   "xsl:stylesheet" tag, as in:
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
   (If you change that value to what was used by Internet Explorer's
    version of the MSXML parser, most other XSLT engines will do nothing
    with it and MSXML3 will try using IE's XSLT dialect instead of the
    standard.)


Now, this designers and scripters with a low level of sophistication are
very productive with simpler template mechanisms like WebMacro, Velocity
or Freemarker. And there are a lot more of them then full fledged
programmers.

We need the few full fledged programmers we have to work in the core
business logic instead of having them solving XSLT related issues.


OTOH, JSP's custom taglibs provide a mechanism to build simple dialects
that make those scripters that understand SQL (we have several)
productive on the simple logic that is necessary to build the data for
a report - and most of our dynamic pages are reports.

With taglibs for retrieving SQL data and applying a Velocity/WebMacro
template to it, one can do a lot.

With a caching taglib around JSP code which results can be cached, one
can do a lot working with a lot of performance.


For me, this is just a real world scenario.


Have fun,
Paulo Gaspar

> -----Original Message-----
> From: Nick Bauman [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 13, 2001 02:23
>
> Somewhat unrelated, I hear a lot of people going gaga over XSLT for web
> development. I understand the desire: a single document represents the
> data of the page, while other documents are used to convert that data for
> different clients / views with an emphasis on content seperation from
> presentation logic.
>
> But AFAIK, this is only 1/2 the battle. I still have business logic which
> cannot be handled in the XSLT code. Add the amount of work just to get the
> presentation away from the content in a standards-compliant fashion
> (work in both a human and a computer terms) isn't worth it unless, say, I
> was going to implement web, WAP and Palm OS views for the Library of
> Congress or the Human Genome Project. But all that just for Acme Widgets,
> who has, at the most, 2000 products.
>
> Kinda like using the Space Shuttle to go grocery shopping.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to