Re: [Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js
In that case, the Woody flowscript api needs to be refactored. I'll
start doing this. If anyone's using the existing one, plan on seeing
some changes.
Chris
Bruno Dumon wrote:
On Thu, 2003-09-11 at 19:38, Christopher Oliver wrote:
Bruno Dumon wrote:
On Wed, 2003-09-10 at 09:54, Sylvain Wallez wrote:
Christopher Oliver wrote:
BTW that flowscript code was written with the intention of supporting
multi-page Woody forms with automated back/forward navigation as in
JXForms. However, when I looked into implementing this I discovered
that Woody forms cannot be presented in multiple pages because
apparently the entire form is "submitted" with each request. As a
result the fields that are not presented in the first page fail
validation because they have no values. Or am I missing something?
No, you got it right : Woody always validates the whole form.
Yep, though it is possible to make a container widget that only
delegates request processing and validation to a subset of its widgets,
ie something like:
depending on the value of some request parameter, the wd:multipage
widget would only let a certain group of widgets process the request.
Another approach to collecting data over multiple pages would simply be
to create multiple (different) forms, which is of course already
possible today.
What's the best solution probably depends on the use case, I didn't felt
the need yet for the first one.
Unfortunately that makes the current integration of Woody with
Flowscript close to useless.
if you use the woody() function as entrance point, yes.
How would you propose to handle multi-page
forms?
Something like this:
function myfunc()
{
var form1 = new Form(formDefinition1);
var form2 = new Form(formDefinition2);
var form3 = new Form(formDefinition3);
form1.show(...);
form2.show(...);
form3.show(...);
}
and call the myfunc function from the sitemap.
Haven't tried this though (I'm using apples), but I think it should
work.
Re: [Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js
On Thu, 2003-09-11 at 19:38, Christopher Oliver wrote:
> Bruno Dumon wrote:
>
> >On Wed, 2003-09-10 at 09:54, Sylvain Wallez wrote:
> >
> >
> >>Christopher Oliver wrote:
> >>
> >>
> >>
> >>>BTW that flowscript code was written with the intention of supporting
> >>>multi-page Woody forms with automated back/forward navigation as in
> >>>JXForms. However, when I looked into implementing this I discovered
> >>>that Woody forms cannot be presented in multiple pages because
> >>>apparently the entire form is "submitted" with each request. As a
> >>>result the fields that are not presented in the first page fail
> >>>validation because they have no values. Or am I missing something?
> >>>
> >>>
> >>No, you got it right : Woody always validates the whole form.
> >>
> >>
> >
> >Yep, though it is possible to make a container widget that only
> >delegates request processing and validation to a subset of its widgets,
> >ie something like:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >depending on the value of some request parameter, the wd:multipage
> >widget would only let a certain group of widgets process the request.
> >
> >Another approach to collecting data over multiple pages would simply be
> >to create multiple (different) forms, which is of course already
> >possible today.
> >
> >What's the best solution probably depends on the use case, I didn't felt
> >the need yet for the first one.
> >
> >
> Unfortunately that makes the current integration of Woody with
> Flowscript close to useless.
if you use the woody() function as entrance point, yes.
> How would you propose to handle multi-page
> forms?
Something like this:
function myfunc()
{
var form1 = new Form(formDefinition1);
var form2 = new Form(formDefinition2);
var form3 = new Form(formDefinition3);
form1.show(...);
form2.show(...);
form3.show(...);
}
and call the myfunc function from the sitemap.
Haven't tried this though (I'm using apples), but I think it should
work.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
[EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js
Bruno Dumon wrote: On Wed, 2003-09-10 at 09:54, Sylvain Wallez wrote: Christopher Oliver wrote: BTW that flowscript code was written with the intention of supporting multi-page Woody forms with automated back/forward navigation as in JXForms. However, when I looked into implementing this I discovered that Woody forms cannot be presented in multiple pages because apparently the entire form is "submitted" with each request. As a result the fields that are not presented in the first page fail validation because they have no values. Or am I missing something? No, you got it right : Woody always validates the whole form. Yep, though it is possible to make a container widget that only delegates request processing and validation to a subset of its widgets, ie something like: depending on the value of some request parameter, the wd:multipage widget would only let a certain group of widgets process the request. Another approach to collecting data over multiple pages would simply be to create multiple (different) forms, which is of course already possible today. What's the best solution probably depends on the use case, I didn't felt the need yet for the first one. Unfortunately that makes the current integration of Woody with Flowscript close to useless. How would you propose to handle multi-page forms? Chris
Re: [Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js
On Wed, 2003-09-10 at 09:54, Sylvain Wallez wrote: > Christopher Oliver wrote: > > > BTW that flowscript code was written with the intention of supporting > > multi-page Woody forms with automated back/forward navigation as in > > JXForms. However, when I looked into implementing this I discovered > > that Woody forms cannot be presented in multiple pages because > > apparently the entire form is "submitted" with each request. As a > > result the fields that are not presented in the first page fail > > validation because they have no values. Or am I missing something? > > > No, you got it right : Woody always validates the whole form. Yep, though it is possible to make a container widget that only delegates request processing and validation to a subset of its widgets, ie something like: depending on the value of some request parameter, the wd:multipage widget would only let a certain group of widgets process the request. Another approach to collecting data over multiple pages would simply be to create multiple (different) forms, which is of course already possible today. What's the best solution probably depends on the use case, I didn't felt the need yet for the first one. > > > In addition, the "validator" function in show() was not intended to > > return a value. I did that originally simply because it wasn't > > possible to programatically add validation errors to the form widgets > > themselves at the time it was written (not sure if that's still the case). > > > It is possible now, as I added access to the real widgets in order to do > this. I thought the more important step was that you added a setValidationError() method on the field widget. But then that was also _only_ the field widget. I'm thinking we should generalize this to all widgets, and probably also make it into addValidationError(), so that each widget can get multiple validation errors. > But problem is that the form is not informed of this "manual" > validation, and therefore there must be a way for the validator function > to express this. I think returning a boolean to indicate this is a good solution. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js
Christopher Oliver wrote:
BTW that flowscript code was written with the intention of supporting
multi-page Woody forms with automated back/forward navigation as in
JXForms. However, when I looked into implementing this I discovered
that Woody forms cannot be presented in multiple pages because
apparently the entire form is "submitted" with each request. As a
result the fields that are not presented in the first page fail
validation because they have no values. Or am I missing something?
No, you got it right : Woody always validates the whole form.
In addition, the "validator" function in show() was not intended to
return a value. I did that originally simply because it wasn't
possible to programatically add validation errors to the form widgets
themselves at the time it was written (not sure if that's still the case).
It is possible now, as I added access to the real widgets in order to do
this. But problem is that the form is not informed of this "manual"
validation, and therefore there must be a way for the validator function
to express this.
Another way could be for the validator to set an "invalidate" property
on the form. Don't know...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
[Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js
BTW that flowscript code was written with the intention of supporting multi-page Woody forms with automated back/forward navigation as in JXForms. However, when I looked into implementing this I discovered that Woody forms cannot be presented in multiple pages because apparently the entire form is "submitted" with each request. As a result the fields that are not presented in the first page fail validation because they have no values. Or am I missing something? In addition, the "validator" function in show() was not intended to return a value. I did that originally simply because it wasn't possible to programatically add validation errors to the form widgets themselves at the time it was written (not sure if that's still the case). Chris Sylvain Wallez wrote: Christopher Oliver wrote: The code you copied was an incorrect workaround for an old bug. Just remove it. Ok, thanks. Sylvain
