You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by ivelin <iv...@apache.org> on 2003/04/03 05:21:15 UTC

Re: XMLForm & JSF

In response to the multiple messages in the recent days about using commons
validator,
I am currently studying hard JavaServer Faces EA3.
I will be looking to incorporate the JFC model into XMLForm without the JSP
taglib part.
Any comments in this direction are welcome.


-=Ivelin=-
----- Original Message -----
From: "Sylvain Wallez" <sy...@anyware-tech.com>
To: <co...@xml.apache.org>
Sent: Wednesday, April 02, 2003 6:15 AM
Subject: Re: [ANN] New version of XMLForm released


> Stefano Mazzocchi wrote:
>
> <snip/>
>
> > During the last year of consultancies, I found out that several people
> > identified XMLForm as the possible way to turn cocoon into better
> > webapp-capable system.
>
>
> And having a good form-handling package in Cocoon is absolutely
> necessary to have it adopted to build web applications. I can't remember
> how many people asked me about Struts vs Cocoon. I know they are not
> comparable, but these people were actually asking for a good forms
> handling package.
>
> And web applications are key for Cocoon's future, since even
> publication-oriented sites now want CMS functions that are basically web
> applications.
>
> <snip/>
>
> > and include all that 'somewhat-business-logic' that is sooooo common
> > between webapps that should be factored out and provided directly by
> > cocoon (as struts, somewhat, does).
>
>
> And we should as far as possible build on some common mechanisms such as
> commons-validator that will both factorize development effort, promote
> cross-project pollinization and help people migrate from JSP/Struts
> environments to Cocoon.
>
> > But I'm more than happy to see XMLForm being factored out because:
> >
> >  1) this removes the wrong marketing perception that XMLForm is *the*
> > solution for data-logic control.
> >
> >  2) allows people to experiment different approaches (XForm-based or
> > not) with the same level of confidence.
>
>
> FormValidationAction did not prevent XMLForm nor Precept to appear, but
> these are good arguments to ensure further innovation and development in
> this area. And, BTW, Precept is already a block.
>
> So +1 for a block, but I'm still wanting the current XMLForm code base
> to stay in Cocoon's CVS.
>
> Sylvain
>
> --
> Sylvain Wallez                                  Anyware Technologies
> http://www.apache.org/~sylvain           http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
>