Workflow in turbogears is very much a "many ways to do it" issue. In
some cases you may wish to choose more than one strategy depending on
the nature of your application and task.
If you're using the default controller system, a basic chained formset
can be done like this:
@expose(..template=..)
def firstpage_form(self):
...
return dict(form=formPart1)
@expose()
@validate(form=formPart1)
@error_handler(firstpage_form)
def firstpage_handler(self, name, address,):
# Can add more complex decision logic here
return secondpage_form(name, address)
@expose(..template=..)
def secondpage_form(self, name, address):
return dict(form=formPart2, value=dict(name=name, address=address))
@expose()
@validate(form=formPart2)
@error_handler(secondpage_form)
def secondpage_handler(self, name, address, phone_number, fax_number):
# make db record, commit etc
...
This is ok for a simple form you want to break into two parts,
possibly to do some checks (ie, a registration form where you wanna
check the username is free before you do something else).
The need to have the second and subsequent forms also contain hidden
fields for all the previous forms quickly becomes unwieldy if your
process is complex however. For a more complex solution, you will want
to create a pickled, signed, encrypted, encoded dict you can pass
along at each stage with the updated data in the same manner as above.
This allows you to store the relevant information from each stage -
including sensitive info - without the dissonance you get from session-
based storage of the same thing in a form that can go backwards and
forwards.
I have one of these dict objects if anyone needs it.
If you're using routes or equivalent for your controller, you have a
couple of alternate options available to you.
The clumsy _form, _handler postfixes of the above can be replaced with
_GET and _POST respectively, making the URLs tidier.
And if you have a singular var you need to keep hold of, you can use
it prior in the URL, ie:
/email/[EMAIL PROTECTED]/setup
Setup can then move to setup2, setup3, whatever, without having to
consciously retain [EMAIL PROTECTED] - it's further up in the path and
therefore the browser will leave it there for relative motion at the
same level or deeper.
With very few exceptions, I do not use sessions at all for the
purposes of maintaining multipage form state. This is personal choice,
I prefer to deal with partial completion in a way that can easily re-
enter at any machine in a cluster. If you code carefully with the
possibility of tabs and the back-button in mind, sessions can be used
in a similar way to the encrypted dict I referred to above to manage
form state.
Richard Clark,
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
