cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Re: CocoonForms compared with JSF
Date Mon, 24 Nov 2003 11:08:38 GMT
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).
> 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                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message