Re: [Proposal] Portal Framework

[Eduardo Pelegri-Llopart <Ed...@eng.sun.com>]

You may want to check out the "JSP & XML" white paper that we have at

 http://java.sun.com/products/jsp/html/JSPXML.html

it covers this design space.  One of the points expanded in that paper
is that it is probably not an either/or.  In some cases it is best to
do "common pipeline + transformation at the end", while in others it
is best to do "separate short pipelines".  

Below are some of the issues that I think impact the decision.


  * The separation inthe interaction model between the two clients.
For example, a VoxXML client interacts quite differently than an
HTML or DHTML client.  On the other hand an HTML client is quite
close to an DHTML client.  In the first it may be best to have
separate JSP pages (or even applications!), in the second, you may
want to a single JSP page with content detail mediated through
tag libraries.

To me, the key thing is to provide appropriate abstraction.  Then
you can more easily change the organization.

  * Another factor in choosing is how "stable" is the content.
For example, in a publication system all pages conform to a given
DTD, e.g. docbook.  That makes it very easy to transform them
uniformly; not surprisitingly that is the context that gave us
XSLT.  Also that is, IMHO, the best match for a system like cocoon.
But in dynamic content, there is a fair amount of instability and
change in the content that one wants to deliver.  In some cases,
there is almost no consistency, and that means that you may
need a slightly different XSTL per JSP page.  (OK, so that is
probably extreme, but you get my point, I hope).

  * Yet another factor is exactly what transformation one wants to
do.  If one desires to express something that is mostly a template,
a templating system like JSP seems a better match than a recursive
language like XSLT

  * A final issue is ability of the solution to adjust to changing
requirements.  One of my concerns with XSLT is that it is trying
to be a programming language without being one, and that, at some
point one will want an actual programming language, and if you
want to do that, why don't you just use Java from the beginning.

One area I would like to explore better is using things like XPATH
within JSP to do transformations.  To me this seems a combination
of the best strengths of each component: the templating parts of
JSP, the generic selection mechanism of XPATH, the portable extensible
mechanism of tag libraries.  What is left out from XSLT is the
recursive tree language mapping invocation, and I think it would
be interesting to see where that leaves us.  Let me know if you
want to convince your advisor to try it, or if you want to try it on
your own; I'd be willing to help with ideas :-).

All that said, I get back to the original: in some cases one solution
works better than another; it is not an "either/or".


Hope this helps some

	- eduard/o


"Schachter, Michael" wrote:
> 
> >I haven't done any XSLT and maybe it is a magic bullet.
> >Personally, I would prefer the following model:
> 
> >   - A request comes in.
> >   - The action associated with the request calls a bean that
> >     does the device detection part.
> >     (if using servlet 2.3, this could easily be done via
> >      a filter)
> >   - Business logic is processed
> >   - Forward to the appropriate JSP, according to the detection
> >     done previously:
> >         e.g.  CustomerList_wml.jsp
> >               CustomerList_html.jsp
> >               CustomerList_xml.jsp
> 
> That's definately a viable alternative.  The only issue I have with that is
> that you're duplicating presentation logic within the JSP's that you create.
> Instead of doing pure XML->Whatever transformation, you're doing the same
> kind of logic using taglibs in each page.   It probably isn't that big of a
> deal, since you're doing something similar with XSLT anyway...
> 
> >What I like about using JSP is that a designer focuses solely on the\
> >syntax of the "presentation language" (along with some JSP tags).
> >No need to worry about more layers (XML/XSLT).
> 
> Well, it's the same basically for XSLT. Instead of using jsp taglibs, the
> presentation designer could possibly be given a specification for an xml
> format to work with, such as:
> 
> <document>
>   <title>The title</title>
>   <body>A bunch of content</body>
> </document>
> 
> And all the designer would have to know is pretty basic XSLT to produce the
> view for each device.  It'll probably be up to the business logic guy to
> develop the JSP that spits out the XML.  Inside of XSLT the presentation
> designer embeds whatever presentation language their using, HTML, WML, pure
> XML, etc.  The only tags the developer has to worry about now are standard
> XSLT tags, as opposed to custom built (either by you or a framework's) tags.
> 
> >But I might be missing something in the XML/XSLT story.
> >Please enlighten me!
> 
> I'll be the first to admit that XSLT can get pretty ugly and doesn't have
> the *greatest* learning curve.  But it has alot of potential, and I'm sure
> that future development tools will support the usage of this language
> better.