Great topic! As a plug, check our second JSP talk at JavaOne:
http://jsp.java.sun.com/javaone/javaone2000/event.jsp?eventId=1545&trackId=3&eventType=TS
It is hard to say "thou shall do this" and "this is best", but we will
try to present and discuss all the useful variations on the models that
we have seen. Do not trust the dates yet, we are trying to get a better
location and larger room since last year the JSP & Servlet talk were
attended by about 7K people each. We also should touch the topic at the
BOF on case studies and at the BOF on taglib case studies.
If we had a good talk on this ready, I'd point you to it; at this
moment, the best one we have is what we did at O'Reilly at:
http://java.sun.com/products/jsp/pdf/talks/OReillyJava2000.pdf
Coincidentally just yesterday Danny and I were talking with some
developers that were organizing their layer as
(A)
EJBs =>
Objects with a "toXML()" method =>
grouped into XML doc by a Servlet =>
presented by an XSLT stylesheet
Essentially they are using XSLT as a templating mechanism. If I
remember right they had something like 30 servlets and about 70
stylesheets.
We talked about some other alternatives, for example
(B)
EJBs =>
Objects with a "toXML()" method =>
grouped into XML doc by a JSP using taglibs =>
presented by a XSLT stylesheet
(C)
EJBs ->
Objects with a "toXML()" method =>
grouped and presented by a JSP using taglibs
(D)
EJBs =>
Objects =>
accessed and presented by a JSP using taglibs.
The design center of XSLT is a recursive-based tree-focused
transformation mechanism. If you stay close to its design center you
get its benefits, if you move away from that design center you loose
those benefits.
Intrinsic to XSLT is that it manipulates one tree. Accidental, but
relevant, is that there is no portable standard for delivering function
extensions, nor element extensions [[function extensions are much easier
to define, element extensions are quite harder]]
The design center for JSPs (and similar technologies) is collecting /
manipulating template data (be it raw stream or XML fragments) and
dynamic data. JSP 1.1 has a standard extension mechanism and can easily
handle multiple sources and we have tried to encourage tool manipulation
of JSPs.
I am a big proponent of tag libraries. You can use them to abstract a
query, or a cache directive, or the application of an XSLT
transformation to a data source. For example, somebody had an
organization that looked as
(E)
Multiple XML sources (e.g. JDBC returning an XML table, or XQL) =>
Extracted and sorted using XSLT =>
injected into template data using a custom action inside a JSP
template
When combined with a relatively simple Dreamweaver wizard, this
delivered a very good end-user experience, with the author (designer I
think some used) using Dreamweaver to compose a prototype of the JSP
page, then select a region to replicate (as rows in a dynamic table),
invoke the wizard, select the source, then select the columns to use,
then click to get the JSP. Repeat for all sources involved in your
typical multi-pane presentation. This same user experience can be
achieved when the data sources are not XML-based, e.g. bypassing the XML
table, or just if they come from some EJB, or what-have-you.
JSPs are really good at this multi-source, expose the template,
approach.
Now a different topic is how to organize your layer if you have multiple
clients, say a WAP and an XHTML client. Some architectures suggest an
XSLT that will retarget your presentation to each client. Others
suggest using separate presentation pipelines for each client. Others
suggest a transcoder gateway. We will talk about this at the session;
I'll try to follow-up with another message on the topic but I have to go
now; but note that if you are using XSLT as a templating mechanism,
then you have to replace all your XSLT sytlesheets to retarget, so you
really only reuse the "shared aggregating servlets" from (A) above, and
experience shows that these aggregating servlets are not universal: you
need additions here and there to cope with different presentations.
Anyhow, back when I can. Again, great topic :-)
- eduard/o
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
