Re: [Phrame-devel] multiple page forms

[Jason S. <jsw...@ya...>]

--- Bas Cancrinus <ba...@pl...> wrote:
> Jason Sweat wrote:
> 
> >One questions I have been asked from several sources is how to create
> >multi-page forms in combination with Phrame.  I sketched out an example of
> how
> >I do this here http://www.sitepointforums.com/showthread.php?p=998649 if you
> >are interested.
> >  
> >
> Dear Jason,
> 
> This is a nice piece of work! I have thought about the "wizard" problem
> many times, but I never addressed it in a structural way. I'm delighted
> to see that you took the first step. 
Thanks, glad you liked it :)

> Therefore I'd like to express my
> thoughts about wizards:
> 
> I define workflow as a finite tree of process steps (nodes) and a wizard
> as a manager of workflow with the following properties:
> 1) It evaluates the values that an agent submitted in each process step
> to decide what the next step in the tree will be;
> 2) It remembers the path through all previous process steps and the
> corresponding submitted data for those steps;
> 3) It executes a persistent transaction when an agent committed the leaf
> step in the tree.
> 
> The first property is partially satisfied in the current Phrame release:
> an ActionForm validates the quality of submitted data
I actually cheated here in my implementation and had the wizard have a method
that accepted the current ActionForm object and did the validation on it's own.

 
> and the corresponding Action forwards the controller to the next step based
on
> that data. The mappings file is currently missing the syntactic sugar to
> easily move backwards in the process tree: one should define a forward
> to every child for a given parent and one should define a forward to
> every parent for a given child.
Not sure about that.  I defined a "prev" for each step to go backwards in the
process, does that not accomplish what you are thinking about?  Also, my
particular wizard was linear, so I did not have to worry about branching nodes,
other than returning to the current step if form validation failed.

> 
> In my opinion your code could be a good starting point to address the
> second and third property of a wizard. I'm very interested in other
> opinions this subject!
I of course cut out the parts of my source that were specific to my project. 
In my instance, I had an array that tracked the form elements at each step,
including attributes like what kind of a form element is it (input text, text
area, select, etc), label and validation steps (has to be numeric, has to be in
a range, has to be a member of the select list, etc.)

The $this_aaState array also tracked values and errors at each stage.  When my
view displayed the data, it fetched the current form from the wizard, which
integrated the error and value information into the array.  The view would then
render the form, including default values and warnings for improperly filled
out elements.

All of this was very project specific is why I did not include it in the post.

HTH

Regards,

Jason

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree