cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Bruchez <e...@bruchez.org>
Subject Re: CocoonForms compared with JSF
Date Mon, 24 Nov 2003 00:18:09 GMT
 >>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



Mime
View raw message