RE: [Woody multi page forms]

[mratliff]

Timothy,

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

Timothy Larson <[EMAIL PROTECTED]> 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