Snippet List
Wraps many Form subclases in order to get a form wizard to treat them as one.
Many Forms will use one step.
**Example:**
`class LanguageVerifiedHumanForm(MultipleForms):
base_forms = [
('language_form', LanguageForm), ('verified_human_form', VerifiedHumanForm)
]`
`class NewGuideWizard(SessionWizardView):
form_list = [
('guide_form', GuideForm),
('multi_form', LanguageVerifiedHumanForm),
]`
- multiple
- forms
- wizard
- multi
- form-wizard
Okay - so I came across a really annoying problem earlier, where I wasn't able to *easily* load a formwizard as a segment into an existing view, and wrap it using my existing site template layouts. This was *REALLY* annoying. Especially since I wanted to keep as much of a 'overall' templating and application logic in the views.py (and just leave the forms.py to handle the form and its own templating for the form pages)
I spent about 2 hours trying to make this as conventional as possible, and finally came up with a solution. The result is something which looks as similar to the usual functionality. This also meant that there is seperation between form styling and overall site styling, so your forms can be used between multiple sites, and if your overall site template uses extends, then the context support keeps this nicely in order.
This also allows you to initialise the formwizard in a nicer way.. Of course, in each file, you'll need to import the necessary bits (like importing the testform from the view etc)
- requestcontext
- views
- context
- form
- urls.py
- wizard
- formwizard
- views.py
This is an extended version of django wizard with the ability to go back
and execute any step directly.
To define next step to execute use the form field with the name
"wizard_next_step".
Don't forget to specify in your form the wizard_max_step field, so the
knows the step number with the highest number, where the user was.
An other improvement is the variable "wizard_data". It's a QueryDict with
data from all wizard forms. It can be used to retrieve values from the
field values of the forms from other steps. It could be helpfully for
the latest step, where the user should see an overview of his input.
A rewrite of the django.contrib.formtools.FormWizard class to be session-based instead of saving state in hidden form variables.
It started out as a simple port of the standard FormWizard class, and much of the original behavior was unchanged because I wanted to limit the scope of the "rewrite". Along the way I think I made it a bit more OO, and a bit more flexible, but there are still warts.
I threw this code up here before I was completely happy with it just to take part in the discussion around [this ticket][http://code.djangoproject.com/ticket/9200 "Django Ticket #9200]. There's certainly a few things that the patch on that ticket does that I'd like to incorporate into my Wizard, whenever time allows.
- forms
- session
- wizard
- formtools
This a wizard tool similar to the one in django.contrib.formtools, but it uses a session. I hope to eventually get this into shape and contribute it to the formtools package, but for right now, here it is.
The wizard steps are broken into 2 categories:
Show Form and Submit Form
Each category has it's own hooks for manipulating the process, for instance you can short-circuit a process_submit_form() and go straight to done() via a return from preprocess_submit_form(). Sorry for the lack of documentation on this.
Here's an example urls.py entry :
`(r'^estimate/(?P<page0>\d+)/$', EstimateWizard([EstimateCustomer, EstimateJob, EstimateRoom]))`
where EstimateCustomer, Job, and Room are Form classes and EstimateWizard extends SessionFormWizard
6 snippets posted so far.