Lists Home |
Date Index |
> JSP seems to me like roughly the same design pattern as XSLT: you
> start with a template and fill in the empty spaces by with some code
> (procedural in JSP, declarative in XSLT)...
I don't think it's as clear cut as that. If you write JSPs that consist of great
chunks of Java code then you're not really taking best advantage of the
Once you move into producing JSP tag libraries, then your JSPs can become
much more declarative -- at least from the perspective of the tag library
user. The dirty code used to implement those tags is nicely hidden as it
should be. And as it is in the implementation of an XSLT engine.
There's a nice developerWorks article on this:
> I would be very interested in seeing a few non-trivial problems of this
> sort being addressed both ways, with the solutions shared/critiqued,
> so that we can all get a better handle on the guidelines for when a
> JSP (or ASP, or PHP, or "DOM code filling in an XML template") approach is
> more effective, and when a pure XSLT approach is more effective.
> Has anyone done something like this before?
Sounds like another decision tree Mike! :)
Some things to consider:
- who is authoring your JSP pages?
If it's a web developer, give them declarative tag libraries, not chunks of
If you're just spitting out XML for later processing, then maybe tag libraries
aren't such a strong requirement. But even so you get benefits from
reuse. Cocoon XSP is used in this way. It's for data generation, rather
- what are your JSP pages doing?
Design patterns for web architectures  suggest that the shouldn't
be doing more than presentation tasks, i.e. implementing the View
of an MVC architecture. JSP pages are basically Template views . XSLT
is a Transform  View.
- where does the data come from? Is it being pulled into a template, or pushed in from outside?
If all the data is presented to the page, and it merely formats it then that's
a push approach. The page is then coupled to the data generator which
has to provide all required data.
If data is pulled in as required, then that's the opposite. There's less
coupling (just location, and format).
In reality a mixture of the two is likely.