cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: [Woody multi page forms]
Date Fri, 12 Sep 2003 22:30:15 GMT

I've been thinking about this sort of thing a lot.  It mostly makes my 
head hurt...

Timothy Larson <> wrote on 09/12/2003 06:13:05 AM:

> 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.

Yes, exactly.  Split of view into presentation units (pages) may be based 
        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 
        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. 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,

View raw message