You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christopher Oliver <re...@verizon.net> on 2003/09/10 05:36:06 UTC
[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
>
Re: What are you using for form handling?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Barzilai Spinak wrote:
> "On how to hit a moving target" by Barcho
>
> Hi, I'd like to know what people are really using for form handling.
>
> Abstract:
> We were in the middle of a project using XMLForms and it was killed,
> so we started porting to JXForms which was still-born (see below).
> Woody is in a fetal state and a port to Woody is not so trivial as
> XMLForms --> JXForms.
> What should real people with real projects do?
I use Woody on a real project. But this should be considered as a
particular case, as I add new features to Woody as part of this project,
which helps it maturing quickly.
<snip/>
> And then we have Woody which seems to be the loved child at the
> moment. But how usable is it? I haven't looked at it. I may give it a
> chance if someone tells me "XMLForms is dead, long live JXForms is
> dead, long live Woody!!"
I tell you that XMLForm is dead, JXForms is nearly dead (it's basically
the same as XMLForm except that the transformer has been rewritten), and
long live Woody!! Now you can go ahead and look at the samples ;-)
Read more about the reasons for this at
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105881304808076&w=2
> We should have *at least one* forms framework that works.
This is and will be Woody.
It is already more featured than XMLForm/JXForms, except that it
currently doesn't support wizards, and that some changes are likely to
occur in its API. Not radical changes, but changes that require some
minor work in existing code. You should be clearly warned of this before
making a choice, but it's definitely the Cocoon from framework that will
last.
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
What are you using for form handling?
Posted by Barzilai Spinak <ba...@internet.com.uy>.
"On how to hit a moving target" by Barcho
Hi, I'd like to know what people are really using for form handling.
Abstract:
We were in the middle of a project using XMLForms and it was killed, so
we started porting to JXForms which was
still-born (see below). Woody is in a fetal state and a port to Woody is
not so trivial as XMLForms --> JXForms.
What should real people with real projects do?
We had an (apparently) working framework which was XMLForms and a couple
of months ago it was deprecated in favor
of JXForms. All this happened with minor discussion (at least on the dev
list for which I've been reading all messages).
All this would be very fine if JXForms actually worked. Lately there
have been a few messages by me and others
concerning problems with JXforms: (for example)
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23452
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106309010927746&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105794535504709&w=2
It all started with the lack of an equivalent to xf:selectBoolean but
now I've realized that -- at least -- chekcbox handling
is *broken* when all the related checkboxes in a form are unchecked.
Go ahead and try it!! Go to the /cocoon/samples/jxforms/wizard/ and
try to uncheck ALL "hobbies", or ALL "professional roles"
Now go back with the "Prev" button and you'll see them still checked.
This is not a problem with the wizard sample, but rather
a problem in JXForms not handling "expected" but "not submitted"
parameters like XMLForms used to do.
So far I have found a "we-dont-talk-about-that-in-here" attitude with
respect to the whole subject.
And then we have Woody which seems to be theloved child at the moment.
But how usable is it? I haven't looked at it.
I may give it a chance if someone tells me "XMLForms is dead, long live
JXForms is dead, long live Woody!!"
We should have *at least one* forms framework that works.
BarZ
http://www.internet.com.uy Tel. 707.42.52
---------------------------------------------------
TODAS LAS FORMAS DE ACCESO TODOS LOS SERVICIOS
* ADSL/ADSL Plus/ADSL Class - Todas las velocidades
* Accesos por Modem 56K - Tarifa Plana o por minuto
* Desarrollo - Web - Redes - Intra/Extranets - VPNs
* E-mail - Antivirus - Forwards - Alias - Roaming
Re: JXForms and selectBoolean
Posted by Christopher Oliver <re...@verizon.net>.
Barzilai Spinak wrote:
> Christopher Oliver wrote:
> > BarZ,
> >
> > Feel free to submit patches to JXForms, for example for
> "selectBoolean". Nobody is "responsible" for JXForms or other Cocoon
> development per se. It's voluntary.
>
> Well, thanks for your confidence hehe.
> I may do just that when I feel more compfortable with the code. In
> fact I have a few ideas.
> But before doing that I wanted to know for example what the philosphy
> behind the JXForms project is, or if
> someone is already planning to do something about it.
> Sometimes, when I find problems in other people's code/API's, I fear
> that it may be me who "just don't get it".
There's only one way to find out - by showing them your code.
>
> Also, although it's an open source project and anyone can contribute,
> there's generally one or
> two people who do most of the work on a certain part (JXForms in this
> case). They are usually
> the ones who started the subproject, with some idea and vision in
> mind, and generally have the final word
> on whether a new submitted patch is going to be implemented.
Not so, IMO. There should be no code or idea ownership in open source.
Once you've contributed your ideas or code it belongs to the community
and others can change it..
> At least they have CVS permission
> to do it which is not my case!! :-)
You can submit patches to Cocoon via bugzilla even if you're not a
committer.
>
> If I start adding my <xf:BarZRules> tags and you add <xf:OliverRocks>
> tags and so on, pretty soon the
> project becomes a mess.
>
> So are you this special JXForms someone?
No. For JXForms (or any project) to be truly successful, there should be
no such person.
> And what did you think about my questions?
> Am I on the right path or did I just "not get the whole idea"? :-)
Your assessment of the need for selectBoolean sounds right on track to me.
Regards,
Chris
Re: JXForms and selectBoolean
Posted by Christopher Oliver <re...@verizon.net>.
BarZ,
Feel free to submit patches to JXForms, for example for "selectBoolean".
Nobody is "responsible" for JXForms or other Cocoon development per se.
It's voluntary.
Regards,
Chris
Barzilai Spinak wrote:
> Hello Christopher.
> A couple of days ago I posted a question related to JXForms and nobody
> answered.
> By looking into the CVS submissions, I think you may be one of the
> programmers related to that block.
> Am I right? Can you help me with my question?
> Another programmer seems to be cziegeler but I think he's on vacation
> or something.
> Who would be the right person to ask?
>
> Here's a reference to it.
>
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106309010927746&w=2
>
>
> Thanks for your help
>
> BarZ
>
>
> ADSL para estar en internet las 24 horas a máxima velocidad
> y sin ocupar el teléfono.
> -----------------------------------------------------------
> http://www.internet.com.uy Tel. 707.42.52
>
>
JXForms and selectBoolean
Posted by Barzilai Spinak <ba...@internet.com.uy>.
Hello Christopher.
A couple of days ago I posted a question related to JXForms and nobody
answered.
By looking into the CVS submissions, I think you may be one of the
programmers related to that block.
Am I right? Can you help me with my question?
Another programmer seems to be cziegeler but I think he's on vacation
or something.
Who would be the right person to ask?
Here's a reference to it.
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106309010927746&w=2
Thanks for your help
BarZ
ADSL para estar en internet las 24 horas a máxima velocidad
y sin ocupar el teléfono.
-----------------------------------------------------------
http://www.internet.com.uy Tel. 707.42.52
RE: [Woody multi page forms]
Posted by Reinhard Poetz <re...@apache.org>.
> From: Timothy Larson
>
> Glad to see support for multi-page forms is getting attention.
>
> The separation of concerns between the form model and the
> form view leads me to think the model should not need to know
> how the view is split across multiple pages. For example,
> helpdesk-assisted forms may present a view to the user broken
> into different page divisions than than the view presented to
> the helpdesk staff.
>
> If a form is split across several pages for security reasons
> (think progressive release of information), then we need to
> protect against injected request values. This means the form
> view needs to know which widgets should be present on a page
> and only trigger request processing on those widgets.
>
> The problem is that multi-widget validation requires that
> every widget get the chance to perform validation every time
> there is a request. We just need to split widget request
> processing from widget validation processing and the problem
> will be solved.
>
> What do you think? Does this address your concerns,
> Reinhard?
>From a conceptional POV yes, technically spoken, I don't know. Although
learning the Woody internals has high priority on on my todo list I
haven't found the time yet doing it.
But as mentioned in one of my last mails: multi-page Woody forms are a
must for me and your explanations why we need it are very good. Thanks!
What do others think?
Cheers,
Reinhard
RE: [Woody multi page forms]
Posted by Timothy Larson <ti...@yahoo.com>.
--- Timothy Larson <ti...@yahoo.com> wrote:
> We just need to split widget request processing from widget validation
> processing and the problem will be solved.
Mini reply to myself: When I looked at the source code, this is already split.
Sorry for implying otherwise before reading the code. On the bright side,
this part of our work is already done!
--Tim Larson
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
RE: [Woody multi page forms]
Posted by Gunter D'Hondt <gu...@sofico.be>.
Maybe "subforms" should be interested here so that you can define a form
inside another form and then you can validate a specific subform. Ofcoz
keeping in mind that separation of concerns is not handled with this as
the form model has to know about the form view (which are here
subforms).
Gunter D'Hondt
-----Original Message-----
From: dev-return-47710-gudo=sofico.be@cocoon.apache.org
[mailto:dev-return-47710-gudo=sofico.be@cocoon.apache.org] On Behalf Of
Timothy Larson
Sent: vrijdag 12 september 2003 15:13
To: dev@cocoon.apache.org
Subject: RE: [Woody multi page forms]
Glad to see support for multi-page forms is getting attention.
The separation of concerns between the form model and the form view
leads me to think the model should not need to know how the view is
split across multiple pages. For example, helpdesk-assisted forms may
present a view to the user broken into different page divisions than
than the view presented to the helpdesk staff.
If a form is split across several pages for security reasons (think
progressive release of information), then we need to protect against
injected request values. This means the form view needs to know which
widgets should be present on a page and only trigger request processing
on those widgets.
The problem is that multi-widget validation requires that every widget
get the chance to perform validation every time there is a request. We
just need to split widget request processing from widget validation
processing and the problem will be solved.
What do you think? Does this address your concerns, Reinhard? --Tim
Larson
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
RE: [Woody multi page forms]
Posted by mr...@collegenet.com.
Timothy,
I've been thinking about this sort of thing a lot. It mostly makes my
head hurt...
Timothy Larson <ti...@yahoo.com> wrote on 09/12/2003 06:13:05 AM:
> Glad to see support for multi-page forms is getting attention.
Ditto.
>
> The separation of concerns between the form model and the form view
> leads me to think the model should not need to know how the view is
> split across multiple pages. For example, helpdesk-assisted forms
> may present a view to the user broken into different page divisions
> than than the view presented to the helpdesk staff.
Yes, exactly. Split of view into presentation units (pages) may be based
upon:
1) different devices (can't send as many widgets to a phone as to
a web browser)
2) different types of users on the same device (your help desk
example)
3) different state information for the same type of users on the
same device (e.g., you answer "yes" on page three, so page four gets
skipped entirely and the "next" page becomes page five. Or maybe only
part of page four gets skipped, i.e. "adaptive" or "dynamic" display)
>
> If a form is split across several pages for security reasons (think
> progressive release of information), then we need to protect against
> injected request values.
Yes, maybe something like the Schematron "phases" used in XMLForm?
This means the form view needs to know which
> widgets should be present on a page and only trigger request processing
> on those widgets.
Is it the view which needs to know which widgets should be in a
presentation unit (page) or is it the controller? Lets say you have a
model which contains 20 widgets. My thinking is that the (html)
controller gets a request from the (html) view for the next presentation
unit (other devices would have their own seperate controllers). The
controller evaluates the user type, state information, and whatever else
it needs and "asks" the model for a particular set of widgets (maybe 1-10,
maybe 1-5, maybe 1,2,4,6, and 8). So the controller "figures out" what the
"content model" of the next view should be. Controller (or is it the
model?) then merges the user data with the widgets and otherwise
"prepares" the content model which it passes to the view-generator
(pipeline). Of course, the controller will need to somehow "remember"
which widgets it passed to the view so that it can validate and populate
model correctly when the page is posted.
Hmmm....how the heck is it supposed to do that in a stateless environment?
In Schematron you could define "phases", which were essentially groups of
widgets, and then validate only that "phase". This was quiite handy,
because on multi-page form you often need to revalidate all widget on all
pages before final submission (see XMLForm example). But phases are
"static" and I am envisioning something more "dynamic".
>
> The problem is that multi-widget validation requires that every widget
> get the chance to perform validation every time there is a request.
> We just need to split widget request processing from widget validation
> processing and the problem will be solved.
Yes, with the caveat that validation of a widget in one presentation unit
often requires accessing the value of wigets in other presentation units.
Like if user says their mother is dead on page 1, then claiming their
mother as next of kin on page five is invalid.
>
> What do you think?
[OT: My usage requirements are a bit extreme. I'd need multi-page forms
with stong type/rule/logic based validation which can deliver different
presentation units to different devices/user/states and which support a
strong templating system (like Sylvain's latest stuff). Oh, and if I
could have automatically generated client-side scripting on at least HTML
devices that would be lovely....]
Hope some of this made sense,
Cheers,
--Michael
RE: [Woody multi page forms]
Posted by Timothy Larson <ti...@yahoo.com>.
Glad to see support for multi-page forms is getting attention.
The separation of concerns between the form model and the form view
leads me to think the model should not need to know how the view is
split across multiple pages. For example, helpdesk-assisted forms
may present a view to the user broken into different page divisions
than than the view presented to the helpdesk staff.
If a form is split across several pages for security reasons (think
progressive release of information), then we need to protect against
injected request values. This means the form view needs to know which
widgets should be present on a page and only trigger request processing
on those widgets.
The problem is that multi-widget validation requires that every widget
get the chance to perform validation every time there is a request.
We just need to split widget request processing from widget validation
processing and the problem will be solved.
What do you think? Does this address your concerns, Reinhard?
--Tim Larson
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
RE: [Woody multi page forms]
Posted by Reinhard Poetz <re...@apache.org>.
> From: Christopher Oliver
> 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.
>
<snip>
> > From: Bruno Dumon
> >
> >
> >> 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.
I don't like it that we have to create a new form instance for each new
page. There must be a better solution IMO. For example I'd like to bind
a bean to my form using the binding API and I'd like to collect my data
over more than one page the function would look like this (from memory):
function myFunc() {
var myBean = getMyBean();
var form1 = new Form(formDefinition1);
form.load( myBean );
form.send( "myPage.html" );
form.finish();
var form2 = new Form(formDefinition2);
form.load( myBean );
form.send( "myPage.html" );
form.finish();
...
}
Maybe you have better ideas how to solve this but I don't like the
function above because I always have to write to my bean. What happens
if the user decides to cancel the operation on the last form? Second,
the whole function is to verbose and third I always have to instantiate
a new form?
Any better solutions? What do you think?
Cheers,
Reinhard
Re: [Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js
Posted by Christopher Oliver <re...@verizon.net>.
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:
>>>
>>><wd:multipage id="something">
>>> <wd:page id="1">
>>> <wd:field .... />
>>> <wd:field .... />
>>> </wd:page>
>>> <wd:page id="2">
>>> <wd:field .... />
>>> <wd:field .... />
>>> </wd:page>
>>></wd:multipage>
>>>
>>>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
Posted by Bruno Dumon <br...@outerthought.org>.
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:
> >
> ><wd:multipage id="something">
> > <wd:page id="1">
> > <wd:field .... />
> > <wd:field .... />
> > </wd:page>
> > <wd:page id="2">
> > <wd:field .... />
> > <wd:field .... />
> > </wd:page>
> ></wd:multipage>
> >
> >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
bruno@outerthought.org bruno@apache.org
Re: [Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js
Posted by Christopher Oliver <re...@verizon.net>.
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:
>
><wd:multipage id="something">
> <wd:page id="1">
> <wd:field .... />
> <wd:field .... />
> </wd:page>
> <wd:page id="2">
> <wd:field .... />
> <wd:field .... />
> </wd:page>
></wd:multipage>
>
>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
Posted by Bruno Dumon <br...@outerthought.org>.
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:
<wd:multipage id="something">
<wd:page id="1">
<wd:field .... />
<wd:field .... />
</wd:page>
<wd:page id="2">
<wd:field .... />
<wd:field .... />
</wd:page>
</wd:multipage>
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
bruno@outerthought.org bruno@apache.org
Re: [Woody multi page forms] was Re: cvs commit:cocoon-2.1/src/blocks/woody/java/org/apache/cocoon/woody/flow/javascriptwoody.js
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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