[
Lists Home |
Date Index |
Thread Index
]
This is an interesting question. I worked on a similar project where we had
to make a similar choice between JSP/Servlet versus XSL.
Once you go over the learning curve of understanding the nuances of XSL,
writing stylesheet felt natural and "right" thing to do from a programming
perspective. It definitely was less number of lines of code.
I didn't run any benchmarks, but I would venture to say that XSL solution
will be better performing than JSP's. I guess, I have faith in several
optimizations build into transformers.(open to comments, otherwise).
While writing XSL, it almost reminded me of how I had to make choices
between whipping out 4 lines of perl code versus designing a set of java
classes to solve a problem. It was clear that perl code was more like "write
only" (it was faster to write a new perl script, then try to understand and
debug somebody's old script) and hence, java solution was the right thing
from software maintainability perspective.
However, in the case of XSL versus JSP/Servlet, its hard to argue one is
more maintainable than the other. I would say it depends on the skill levels
on the project. Having said that, debugging tools for java world are quite
mature compared to XSL.
As Mike suggested, would love to hear from more people who were in same boat
and the choices they made.
--Naren
-----Original Message-----
From: Leigh Dodds [mailto:ldodds@ingenta.com]
Sent: Thursday, March 07, 2002 7:02 AM
To: Mike Champion; xml-dev@lists.xml.org
Subject: RE: [xml-dev] JSP or XSL?
> ...
> 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
technology.
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:
http://www-106.ibm.com/developerworks/library/j-jsptags.html?n-j-12131
> 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
code.
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
than presentation.
- what are your JSP pages doing?
Design patterns for web architectures [1] 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 [2]. XSLT
is a Transform [3] 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.
Cheers,
L.
[1]. http://www.martinfowler.com/isa/index.html
[2]. http://www.martinfowler.com/isa/serverPage.html
[3]. http://www.martinfowler.com/isa/transformView.html
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
|
