JSF vs. XSLT

Question

Hello all,
We want to design a new application. I have been debating whether to use JSF with XSLT or to stick to XSLT alone in the view layer. In this application the front-end makes SOAP calls to the business tier so all the data is already in XML. Why not just do an XSLT transformation over the XML data and serve the client-device specific markup? What would JSF buy me in this case?
I would appreciate your insight.
Thanks,
Mete

Answer 1

Hello Craig and all,
I haven't yet seen the JSF SVG demo app but it sounds
pretty cool :-)
I have some questions to follow up with your
comments.
So what you guys did with the SVG demo was to develop
a RenderKit that emitted generic XML+EcmaScript to the
client. Then on the client-side, SVG was produced. Is
my understanding correct?That is correct.
So in that case I suppose it would be possible to
similarly develop a RenderKit that emitted generic
XML+XSL to the client, for the client to do the XSLT
transformation itself, right?Sure, that's feasible for clients that have XSLT capabilities.
This sounds good, but in
our application we don't want to leave the XSLT
transformation to the client in order to be able to
support handheld devices. I think what we want to do
is more similar to what "keyurva" and them did, that
is to have a RenderKit that internally uses XSLT to
generate client-specific markup.That works. So do lots of other things. Let's try to enumerate some of the options:
* XSLT in the client
* XSLT post-processing in a Filter
* XSLT in the Renderer (RenderKit chooses the right stylesheet)
* Different renderkit for each device type
* Single renderkit that delegates to variant renderers based on device type
What still confuses
me is that I thought that there needs to be one
RenderKit for each different markup language.Not necessarily ... it's totally up to how you want to architect things.
For
instance one RenderKit for HTML, one for WML, one for
VoiceXML and so on. So there would be many RenderKits.
But if we have one RenderKit that internally uses XSLT
to generate client-specific markup, then we only have
one RenderKit for all different markups. This kind of
confuses me, maybe I should go back and read more on
JSF. Craig, Keyurva, can you explain this a little
bit?
All of the choices above are feasible -- it depends on what's the easiest way to meet your particular needs.
One important decision criteria might be how you're creating the output data in the first place. If you are primarily dealing with data already in XML formats, an XSLT-based idea probably make sense. But, if you're synthesizing XML in Java code (using DOM or JDOM or something like that), I'll bet you end up writing less lines of code if you just write device-specifc renderers in the first place.
Another question is when this technique is used within
a standard JSR-168 portlet. The portlet learns what
markup language to emit from the portlet container. So
JSF needs to be able to dynamically get the markup
language preference from the portlet and serve that
markup. How could this be done?Aren't you going to make the output variant choice in a portlet based on the same thing (the user agent header) that you would use in a servlet? If that's what you are up to, then you have access to the request headers via the ExternalContext.getRequestHeaderMap() or ExternalContext.getRequestHeaderValuesMap() methods. It's also accessible via value reference expressions (similar in spirit to the JSTL and JSP ELs) via the "header" and "headerValues" implicit variables at the beginning of an expression.
>
Thanks,
MeteCraig