>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.
