#21644: FormWizard needs confirmation step logic
-------------------------------+------------------------------------
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by nickname123):
I have taken a mixin approach in the project I am currently working on
until I solved the problem in a satisfactory manner before creating
patches.
I have several changes I have been working on with formwizards to make
them accommodate my needs. I was planning to finish the wizard before
submitting patches, but since others are interested I figured I should
discuss.
My current approach seems to cover the cases presented I would like to
hear other's thoughts.
Requirements:
- implemented in an opt-out fashion (timo)
- must support multiple confirmation steps (me)
- must allow arbitrary placement of confirmation forms in step order (me)
- must allow the user to present submitted data of previous steps (me)
To accomplish this I define a base confirmation form class. The only
caveat is that no two confirmation steps should use the same confirmation
form class. But this is a minor inconvenience for a large gain in
functionality that could easily be documented and checked at runtime.
This allows for logic like the following:
{{{
if isinstance(form, BaseConfirmationForm):
# pass information to form about previous steps
}}}
I took this approach because adding confirmation support to the wizard is
as simple as defining a step that uses a subclass of the
BaseConfirmationForm for its form.
I am hesitant to post my mixin because the last time I posted mixins
versus a diff I didn't get a positive response. But I have not modified
the wizard class at this point to provide a diff.
The shorthand of my changes are as follows:
The BaseConfirmationForm defines a set_forms method that accepts the forms
of previous steps. I took this approach because I could not find a better
approach for passing previous step data to the form. This way requires
minimal changes to the wizard class but allows the developer unlimited
flexibility with the business logic for a particular confirmation form...
whether it is a simple check box to agree to Terms Of Service, or a
complete confirmation form that requires the user to check it step, or
something in between. My particular wizard needs both.
In wizard.get_form, if the step form is an instance of
BaseConfirmationForm, it is provided with the forms from previous steps.
In wizard.render, if the form is an instance of BaseConfirmationForm, the
forms are checked for validity. If they are invalid,
`render_revalidation_failure` is called on the first step for which form
validation fails.
So far, this seems to work out well. I would appreciate feedback from
someone who can give me a yae or nae for moving forward. My changes rely
on https://code.djangoproject.com/ticket/21667. So I can post my mixins,
but they will seem much more significant than they actually are. There
isn't actually much code change required but I didn't want to force my
project to use a custom fork of django at this point.
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:9>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/069.534d3c1e9b4f3253dd8e9c589e493fd5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
