From: Erik Bruchez > >>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, I added your comments at http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFormsJSF - you're always welcome to add our "outside" view. So maybe both worlds can learn from each other! Thanks! -- Reinhard
