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/01 06:28:40 UTC
[ANN] New version of XMLForm released
The new standalone version brings up to date the UI & Form control syntax to
match the latest XForms Candidate Release.
Should we bring the Cocoon version up to date as well?
The propsed plan is to replace the current module with an Action/Transformer
adapter pair that references the standalone library.
Please vote.
-=Ivelin=-
Re: [ANN] New version of XMLForm released
Posted by Torsten Curdt <tc...@dff.st>.
ivelin wrote:
> The new standalone version brings up to date the UI & Form control syntax to
> match the latest XForms Candidate Release.
>
> Should we bring the Cocoon version up to date as well?
> The propsed plan is to replace the current module with an Action/Transformer
> adapter pair that references the standalone library.
I think it's a good idea to create a new "xmlform" block first.
Since xmlform has never been ported back to the stable branch
changing the syntax *should* not be a problem. But in order
not to frustrate the users that already use it - what about
providing an ant script to convert from one syntax to another??
To put it frankly: I am still not very keen on having it as
standalone library.
my 2 cents
--
Torsten
Re: [ANN] New version of XMLForm released
Posted by Christopher Oliver <re...@verizon.net>.
ivelin wrote:
>I am proposing to move XMLForm to a block, following the recent suggestions
>by Torsten and Vadim.
>Very similar to
>http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/chaperon/
>The lib directory will include the jar file with all the files shared
>between the standalone and the cocoon module.
>The java directory will include the Action and Transformer adapters.
>Samples will remain mostly unchanged, except for the namespace and tag names
>upgrade.
>
>As a related note, any cocoon commiter can have immediate write access to
>the XMLForm CVS @ SF.net. Just ask.
>
>
>-=Ivelin=-
>
+1 for updating XMLForm to the latest XForms candidate recommendation.
Re: [ANN] New version of XMLForm released
Posted by Torsten Curdt <tc...@dff.st>.
ivelin wrote:
> I am proposing to move XMLForm to a block, following the recent suggestions
> by Torsten and Vadim.
> Very similar to
> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/chaperon/
> The lib directory will include the jar file with all the files shared
> between the standalone and the cocoon module.
> The java directory will include the Action and Transformer adapters.
> Samples will remain mostly unchanged, except for the namespace and tag names
> upgrade.
>
> As a related note, any cocoon commiter can have immediate write access to
> the XMLForm CVS @ SF.net. Just ask.
I am still (at least!) -0 on the fork because of the user's
perception... But of course +1 for the block.
--
Torsten
Re: [ANN] New version of XMLForm released
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Stefano Mazzocchi wrote, On 02/04/2003 12.47:
> ...
>
>> 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.
>>
>> Comments?
>
>
> I held back my comments till now because there was some negative energy
> going round, especially because of the way it was "proposed", but IMO
> factoring XMLForm out of Cocoon as a library to process XForms makes
> perfect techniological sense, both for Cocoon (as you nicely put it) and
> for XMLForm, as it would be usable like the Struts Validator is for
> example.
>
> I think though that this can grow into an Apache (sub)project. What
> would you suggest in this case?
I would suggest to wait and see what happens.
Stefano.
Re: [ANN] New version of XMLForm released
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>
> Stefano Mazzocchi wrote, On 02/04/2003 12.47:
> ...
>
>> 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.
>>
>> Comments?
>
>
> I held back my comments till now because there was some negative
> energy going round, especially because of the way it was "proposed",
> but IMO factoring XMLForm out of Cocoon as a library to process XForms
> makes perfect techniological sense, both for Cocoon (as you nicely put
> it) and for XMLForm, as it would be usable like the Struts Validator
> is for example.
Does it so much make sense ? The main difference of XForms with other
"traditonal" forms is the client-side markup and this is where Cocoon
shines by allowing XForms markup to be translated to regular HTML until
browsers natively support it. A server-side implementation will mostly
concentrate on form validation, which is common to every webapp
framework, be it XForms-based or not.
So IMO an Cocoon-independent solution will be mainly a form validation
package, or it will have to reinvent some of the Cocoon mechanisms.
> I think though that this can grow into an Apache (sub)project. What
> would you suggest in this case?
Mmmh... Don't be too fast : let's wait and see how it evolves and what
community will be around it...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [ANN] New version of XMLForm released
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 02/04/2003 12.47:
...
> 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.
>
> Comments?
I held back my comments till now because there was some negative energy
going round, especially because of the way it was "proposed", but IMO
factoring XMLForm out of Cocoon as a library to process XForms makes
perfect techniological sense, both for Cocoon (as you nicely put it) and
for XMLForm, as it would be usable like the Struts Validator is for example.
I think though that this can grow into an Apache (sub)project. What
would you suggest in this case?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: XMLForm & JSF
Posted by ivelin <iv...@apache.org>.
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 }
>
Re: [ANN] New version of XMLForm released
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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 }
Re: [ANN] New version of XMLForm released
Posted by Stefano Mazzocchi <st...@apache.org>.
ivelin wrote:
> I am proposing to move XMLForm to a block, following the recent suggestions
> by Torsten and Vadim.
> Very similar to
> http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/chaperon/
> The lib directory will include the jar file with all the files shared
> between the standalone and the cocoon module.
> The java directory will include the Action and Transformer adapters.
> Samples will remain mostly unchanged, except for the namespace and tag names
> upgrade.
If you are volunteering to do the job, you get my +1 (I'm a lazy butt,
you know :)
> As a related note, any cocoon commiter can have immediate write access to
> the XMLForm CVS @ SF.net. Just ask.
More seriously, the above vote is really a +1 and for a few reasons:
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.
That kept coming out was: "XMLForm vs. Flow: which one should I invest on?"
But it's like comparing apples and oranges. In fact, Chris has shown
pretty evidently with his work on the petstore that the flow is an
underlying system (more comparable to actions, for that matter) and
several views and controllers can be plugged on top.
XSP,JXPath,Jexl,Velocity,XSLT are all potential "views", template
engines for the data passed by the underlying controllers.
Note that the sitemap is not MVC, but something more: control is further
separated into smaller concerns:
- URI-space control (sitemap)
- flow-logic control (flow/actions)
- data-logic control (???)
- business-logic control (your objects)
the "data-logic control" answers questions like
- how do I represent a form in memory?
- how do I validate it?
- how do I persistently store it?
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 one of the providers for such mechanisms can be the XMLForm block.
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.
Comments?
Stefano.
Re: [ANN] New version of XMLForm released
Posted by ivelin <iv...@apache.org>.
I am proposing to move XMLForm to a block, following the recent suggestions
by Torsten and Vadim.
Very similar to
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/chaperon/
The lib directory will include the jar file with all the files shared
between the standalone and the cocoon module.
The java directory will include the Action and Transformer adapters.
Samples will remain mostly unchanged, except for the namespace and tag names
upgrade.
As a related note, any cocoon commiter can have immediate write access to
the XMLForm CVS @ SF.net. Just ask.
-=Ivelin=-
----- Original Message -----
From: "Stefano Mazzocchi" <st...@apache.org>
To: <co...@xml.apache.org>
Sent: Tuesday, April 01, 2003 3:36 AM
Subject: Re: [ANN] New version of XMLForm released
> ivelin wrote:
> > The new standalone version brings up to date the UI & Form control
syntax to
> > match the latest XForms Candidate Release.
> >
> > Should we bring the Cocoon version up to date as well?
> > The propsed plan is to replace the current module with an
Action/Transformer
> > adapter pair that references the standalone library.
> >
> > Please vote.
>
> Please make a detailed proposal before asking for a vote so that we know
> what we are voting upon.
>
> Stefano.
>
Re: [ANN] New version of XMLForm released
Posted by Stefano Mazzocchi <st...@apache.org>.
ivelin wrote:
> The new standalone version brings up to date the UI & Form control syntax to
> match the latest XForms Candidate Release.
>
> Should we bring the Cocoon version up to date as well?
> The propsed plan is to replace the current module with an Action/Transformer
> adapter pair that references the standalone library.
>
> Please vote.
Please make a detailed proposal before asking for a vote so that we know
what we are voting upon.
Stefano.
Re: [ANN] New version of XMLForm released
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
ivelin wrote:
>The new standalone version brings up to date the UI & Form control syntax to
>match the latest XForms Candidate Release.
>
>Should we bring the Cocoon version up to date as well?
>The propsed plan is to replace the current module with an Action/Transformer
>adapter pair that references the standalone library.
>
>Please vote.
>
Cocoon's XMLForm, even if driven by you, is a community effort. What you
propose here is to remove these source files in favor of a forked
version developped by a closed community (a one-person community, to be
precise).
This means XMLForm will be out of control of the Cocoon community, so :
-1
However, if you want to provide integration of your fork with the Cocoon
code base, you can create a new block dedicated to this, that should not
interfere with Cocoon's XMLForm.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [ANN] New version of XMLForm released
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mardi, 1 avr 2003, à 06:28 Europe/Zurich, ivelin a écrit :
> ...The propsed plan is to replace the current module with an
> Action/Transformer
> adapter pair that references the standalone library.
Could you clarify, so that everyone's on the same wavelength: does
"standalone library" mean
a) code hosted on http://cocoonhive.org/,
or
b) code that stays in the cocoon CVS but can be used in standalone
fashion (using a "build xmlform-standalone" target for example)?
As I said before, b) would IMHO be better for both the XMLForm and
Cocoon communities and projects.
-Bertrand