cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject RE: CocoonForms compared with JSF
Date Sat, 22 Nov 2003 16:06:04 GMT
On Sat, 2003-11-22 at 14:24, Danny Bols wrote:
> > From: Reinhard Poetz [mailto:reinhard@apache.org]
> > Sent: zaterdag 22 november 2003 13:42
> > To: dev@cocoon.apache.org
> > Subject: CocoonForms compared with JSF
> >
> >
> >
> > Over the last days I had an offlist discussion with Sylvain and I don't
> > want to keep back a very nice summary of Sylvain comparing CocoonForms
> > with JSF. I set up a Wiki page:
> > http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFormsJSF
> >
> > We would be very interested in your opinions because this will become a
> > "FAQ" in the future (This week I hold a presentation on Control Flow and
> > only mentioned CocoonForms in a few sentences but in the break after it
> > the "JSF-question" was one of the first ones I got ;-)
> >
> > And I'm with you Jörg, that we have to show that CocoonForms is *NOT*
> > tied to HTML at all. Maybe a XUL example and a second skin would be
> > great!
> >
> > Awaiting your comments :-)
> 
> Nice summary.
> One thing worth mentioning IMO is the Inversion Of Control. Since woody is
> integrated in flow the script has control over the form processing steps. I
> don't know if JSF has solutions for this.

Indeed a good point to mention, though I think it's more about
separation of concerns. Most other webapp frameworks like struts, JSF or
tapestry cover both the flow and form concerns, while woody only does
forms.

Another thing that makes woody different from JSF, at least I think so,
is that widgets in woody hold strongly typed data, and that validation
happens on this data, not on string values. IIRC JSF only does
conversion as part of the binding.

Then there's also other stuff like the fact that the structure of a form
is described in a form definition (I have no idea how JSF actually
builds its component tree), and that lightweight instances of this form
definition are created (i.e. what's common to all instances is only held
once in memory). Of course, this may make the structure of a Woody form
less flexible (but more formal), though with the addition of Tim's union
widget we can describe everything of regular complexity (concatentation,
repetition and alternation).

And last but not least, Woody fits better into Cocoon. IIRC, JSF
requires compliant implementations to support at least JSP ;-)

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


Mime
View raw message