I want to implement a simple 2 part FormWizard. Form 1 will by dynamically generated something like this:
class BuyAppleForm(forms.Form):
creditcard = forms.C
I don't know if answering one's own question is an acceptable behaviour on StackOverflow, here is my solution to my own problem.
First, ditch FormWizard.
I have one form.
Two views: buy_apples
and buy_apples_confirm
First view only handles GET. It prints out the unbound form, with an action to go to the URL of the second view.
The second view checks for the presence of a POST parameter named "confirm". If it is not present (as it is not when the view is loaded the first time) it:
When the user clicks to buy the apples, the form is submitted back and the buy_apples_confirm
view is invoked one more time. This time, a POST parameter called "confirm" is present, so we actually process the purchase transaction and the user gets his apples.
I welcome any critiques on this method or better ways of handling the situation. I am new to Django and find that there are many different ways of approaching a problem. I want to learn from the best though.
When I was trying to figure out FormWizard, I searched all over and found responses such as most of these that just say don't use it. FormPreview would work fine since OP is only interested in a one-level form, but the question is still valid in how to use FormWizard.
Even though this question is so old, I think it is valuable to answer here because this question is asked on so many sites and I see no cohesive response to it, nor a clear solution in the docs.
I think in terms of the OPs question, overriding process_step is the way to go. The trick is in creating the form (or view) within this method that will receive the data from the first form.
I added this form_setup to my forms.py as a utility wrapper (think constructor):
def form_setup(**kwargs):
def makeform(data, prefix=None, initial=None):
form = FormLev2(data, prefix, initial)
for k, v in kwargs.items():
if k == 'some_list':
form.fields['some_list'].choices = v
...
return form
return makeform
Then override process_step as follows:
def process_step(self, request, process, step):
if step == 1
if form.is_valid(): #form from step 1
objs = Table.objects.filter(...) #based on last form
self.form_list[1] = form_setup(some_list=[(o.id,o.name) for o in objs]) #(*)
...
That way, you are able to dynamically modify form_list(*), in the sense that you modify the form_list in the FormWizard instance, rather than the form definitions themselves. The wrapper function is essential for this functionality, as it returns a function that will instantiate a new Form object, which is then used within FormWizard to be called with the data for the next form, and allows you to use the data from the previous one.
Edit: for Erik's comment, and to clarify the last part.
Also note that process_step will be called with step [0,n] after step n.
Thank you krys for answering to your own question. Helped me, but I still got some remarks.
FormPreview is not the way to go since it as far as I know does not support dynamic forms. It relies on a fixed form class to generate the from from there. But we are generating dynamically here with a function. Maybe FormPreview will support this one day (or already does and I dont know how).
Krys solution seems to do the same as FormPreview. Only the hash is left out, so user may change data in the hidden fields or do you check it again?. If you check it again, that would not be following DRY because you duplicate the check (okay, could be in a reusable method, so only tiny repetition).
What I was wondering, how do you adjust the widget? Do you duplicate the form with the new widgets or is there a way to change that dynamically?
How about changing the call method to take an extra parameter?
something similar to this: http://d-w.me/blog/2010/3/18/15/
I haven't used it, but for the situation you describe, it seems like you may want to try the FormPreview instead of the FormWizard. From the documentation it sounds like what you're after.