[Django] #21644: FormWizard needs confirmation step logic
Django
-------------------------------+--------------------
Reporter: nickname123 | Owner: nobody
Type: Uncategorized | Status: new
Component: Generic views | Version: 1.6
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
The FormWizard needs to handle a confirmation step that is capable of
easily outputting a readonly copy of all step data. It is currently very
difficult to support a confirmation step in the FormWizard workflow. The
confirmation step needs access to the "final_form_list" created in the
render_done() method and passed to the done() method. This is important
so the user can see the data he is confirming.
I.e. the confirmation step as presented in the documentation
https://docs.djangoproject.com/en/1.6/ref/contrib/formtools/form-
wizard/#using-a-different-template-for-each-form does not satisfy the
requirements for confirmation since the user cannot actually see his order
that he is supposed to confirm.
This could be worked into the render_done() method, or broken into two
steps. However, currently, one must duplicate a ton of code to render a
confirmation view that outputs a readonly copy of the previous steps.
This could be implemented in a way that allows the developer to "opt out"
of the confirmation if the specific FormWizard in question does not need a
confirmation step.
--
Ticket URL: <https://code.djangoproject.com/ticket/21644>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: nickname123 | Owner: nobody
Type: Bug | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by nickname123):
* needs_better_patch: => 0
* type: Uncategorized => Bug
* needs_tests: => 0
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:1>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by nickname123):
* type: Bug => New feature
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:2>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by nickname123):
I forgot to explain that this cannot currently be performed easily in the
done() method override because render_done() calls self.storage.reset()
after it calls the done() method.
If someone could add this to the ticket description I would be grateful.
Thanks
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:3>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Description changed by aaugustin:
Old description:
> The FormWizard needs to handle a confirmation step that is capable of
> easily outputting a readonly copy of all step data. It is currently very
> difficult to support a confirmation step in the FormWizard workflow. The
> confirmation step needs access to the "final_form_list" created in the
> render_done() method and passed to the done() method. This is important
> so the user can see the data he is confirming.
>
> I.e. the confirmation step as presented in the documentation
> https://docs.djangoproject.com/en/1.6/ref/contrib/formtools/form-
> wizard/#using-a-different-template-for-each-form does not satisfy the
> requirements for confirmation since the user cannot actually see his
> order that he is supposed to confirm.
>
> This could be worked into the render_done() method, or broken into two
> steps. However, currently, one must duplicate a ton of code to render a
> confirmation view that outputs a readonly copy of the previous steps.
>
> This could be implemented in a way that allows the developer to "opt out"
> of the confirmation if the specific FormWizard in question does not need
> a confirmation step.
New description:
The FormWizard needs to handle a confirmation step that is capable of
easily outputting a readonly copy of all step data. It is currently very
difficult to support a confirmation step in the FormWizard workflow. The
confirmation step needs access to the "final_form_list" created in the
render_done() method and passed to the done() method. This is important
so the user can see the data he is confirming.
I.e. the confirmation step as presented in the documentation
https://docs.djangoproject.com/en/1.6/ref/contrib/formtools/form-
wizard/#using-a-different-template-for-each-form does not satisfy the
requirements for confirmation since the user cannot actually see his order
that he is supposed to confirm.
This could be worked into the render_done() method, or broken into two
steps. However, currently, one must duplicate a ton of code to render a
confirmation view that outputs a readonly copy of the previous steps.
This could be implemented in a way that allows the developer to "opt out"
of the confirmation if the specific FormWizard in question does not need a
confirmation step.
EDIT: this cannot currently be performed easily in the done() method
override because render_done() calls self.storage.reset() after it calls
the done() method.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:4>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timo):
* stage: Unreviewed => Accepted
Comment:
I haven't looked at the code, but I'm open to the proposal if this is
indeed overly difficult at the moment. It should be implemented in an
"opt-in" fashion for backwards compatibility, not "opt-out" as proposed.
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:5>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by bnafta@…):
To my understanding, it would be interesting to add, optionally, in the
confirmation step, a checkbox for each field, so that this step would only
be completed if all were marked checkbox. That would be quite useful for
me, because with this, I would force the User to stay longer on the page
and increase the chances of him actually read what you wrote in forms and
make any corrections.
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:6>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Fabio Caritas Barrionuevo da Luz <bnafta@…>):
Real example used in the registration form to apply for job positions in
the government of the city where I live.
Registration is only completed if all checkbox are selected.
This type of strategy was used to force the User to identify and correct
any errors in completion and to avoid further legal problems.
[[Image(https://dl.dropboxusercontent.com/u/66970738/arq_p_foruns/example_.png)]]
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:7>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Fabio Caritas Barrionuevo da Luz <bnafta@…>):
* cc: bnafta@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:8>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 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
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Fabio Caritas Barrionuevo da Luz <bnafta@…>):
nickname123 you have a test project that uses its implementation on
github? If not, you could create it? I would test it
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:10>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by nickname123):
Replying to [comment:10 Fabio Caritas Barrionuevo da Luz <bnafta@…>]:
> nickname123 you have a test project that uses its implementation on
github? If not, you could create it? I would test it
I will have some time in two weeks to put a demo together. I do not have
anything together in a shareable state at this time.
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:11>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by nickname123):
Replying to [comment:10 Fabio Caritas Barrionuevo da Luz <bnafta@…>]:
> nickname123 you have a test project that uses its implementation on
github? If not, you could create it? I would test it
I have pulled apart the relevant code and made a test project. It is very
simple but I think it demonstrates the concept well enough. I can go into
more detail if needed. Keep in mind, the mixin code would be minimal as a
diff, but I had to copy entire methods with the mixin approach. There are
actually very few changes.
https://github.com/thenewguy/django_formwizard_mixins
I did this quickly during lunch. Tested it with django 1.6.4 from pip
briefly. Let me know if you have trouble making it work. I used a new
python 2.7 virtualenv and did pip install django. Then used the
runserver.
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:12>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by nickname123):
Replying to [comment:5 timo]:
> I haven't looked at the code, but I'm open to the proposal if this is
indeed overly difficult at the moment. It should be implemented in an
"opt-in" fashion for backwards compatibility, not "opt-out" as proposed.
Hello Timo. Would you take a look at the test project in my previous
comment and let me know if you are satisfied with the approach? It is
"opt-in" as requested.
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:13>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Component: Generic views | Version: 1.6
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by andialbrecht):
* cc: albrecht.andi@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:14>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by erikr):
* component: Generic views => contrib.formtools
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:15>
Django
Reporter: nickname123 | Owner: nobody
Type: New feature | Status: closed
Component: contrib.formtools | Version: 1.6
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by gchp):
* status: new => closed
* resolution: => fixed
Comment:
formtools has been extracted into its own repository
(https://github.com/django/django-formtools/). Because of this, the issue
tracking for this package has been moved to GitHub issues. I'm going to
close this ticket, but I've created a GitHub issue to replace it where the
conversation can continue: https://github.com/django/django-
formtools/issues/17. Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/21644#comment:16>