You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bruno Dumon <br...@outerthought.org> on 2003/09/11 19:51:16 UTC
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:
> >
> ><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]
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.
>
>
>