On Mon, 2003-11-24 at 01:18, Erik Bruchez wrote: > >>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.
I think the problem is that we're comparing a product with a spec. So while JSF might not make it impossible, Cocoon concretely offers it. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
