Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Reinhard Poetz" <reinhard@apache.org>
To: <dev@cocoon.apache.org>
Subject: RE: CocoonForms compared with JSF
Date: Mon, 24 Nov 2003 09:56:58 +0100
Message-ID: <005a01c3b268$ebd42e40$1e01a8c0@WRPO>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <1069517164.2479.298.camel@yum.ot>
Importance: Normal


> -----Original Message-----
> From: Bruno Dumon [mailto:bruno@outerthought.org]=20
> Sent: Saturday, November 22, 2003 5:06 PM
> To: dev@cocoon.apache.org
> Subject: RE: CocoonForms compared with JSF
>=20
>=20
> 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=20
> > > don't want to keep back a very nice summary of Sylvain comparing=20
> > > CocoonForms with JSF. I set up a Wiki page:=20
> > > http://wiki.cocoondev.org/Wiki.jsp?page=3DCocoonFormsJSF
> > >
> > > We would be very interested in your opinions because this will=20
> > > become a "FAQ" in the future (This week I hold a presentation on=20
> > > Control Flow and only mentioned CocoonForms in a few=20
> sentences but=20
> > > in the break after it the "JSF-question" was one of the=20
> first ones I=20
> > > got ;-)
> > >
> > > And I'm with you J=F6rg, that we have to show that CocoonForms is=20
> > > *NOT* tied to HTML at all. Maybe a XUL example and a second skin=20
> > > would be great!
> > >
> > > Awaiting your comments :-)
> >=20
> > Nice summary.
> > One thing worth mentioning IMO is the Inversion Of Control. Since=20
> > woody is integrated in flow the script has control over the form=20
> > processing steps. I don't know if JSF has solutions for this.
>=20
> Indeed a good point to mention, though I think it's more=20
> about separation of concerns. Most other webapp frameworks=20
> like struts, JSF or tapestry cover both the flow and form=20
> concerns, while woody only does forms.

added to the wiki page

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

added to the wiki page

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

not added to the wiki page - if somebody is sure about this feel free to
add it to the wiki page

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

not added because JSF requrires JSP, CocoonForms requires Cocoon ;-)

--
Reinhard