>>I just laughed. It will be a very hard job for any JSF proponent to >>convince multi-channel-intensive users to follow that renderkits road. >>I don't envy them at all ;-) > > > They'll probably defend by saying you can write a renderkit that > produces XML and put an XSL behind that. They won't mention the > re-parsing needed in between though. Or the fact that you'll have to do > it all yourself. > > OTOH, renderkits not only abstract the rendering but also the decoding > of request parameters, so that's a point where they are more flexibile > then Woody, where it is all hardcoded in the widgets (and assumes > HTML-like behaviour).
http://www.theserverside.com/resources/article.jsp?l=BestBothWorlds
The article is almost one year old now, and I agree that the approach I presented, which did consist in reparsing XML output by JSP, is not ideal from a performance point of view (even though it works).
This being said, for those who judge techologies without reading the specs (or who read them too fast), there is nothing in JavaServer Faces that forces you to use JSP or that limits you to outputting a character stream from a renderer. An implementation that claims compliance must support JSP in order to provide a common denominator, but it can support other rendering technologies. You can certainly write a JSF "tag library" for an XML-based template language that outputs SAX. I am hoping to demonstrate this soon.
You will find good things in JSF if you take the time to read the spec with an open mind. Now if only the JCP got to actually deliver something like a 1.0 version...
-Erik
