FormWizard needs confirmation step logic. ticket #21644

203 views
Skip to first unread message

Gordon

unread,
May 26, 2014, 3:32:41 PM5/26/14
to django-d...@googlegroups.com
Hello,

I have posted an implementation/proof of concept to ticket 21644 (https://code.djangoproject.com/ticket/21644).  The implementation is currently written as a mixin because I need to be able to use it now and I don't like maintaining a custom fork of django for my projects.  If changed to update the base classes directly, the diff would be minimal.

I am happy to work on FormWizard improvements because they are particularly useful for some of my projects, but I haven't had much of a response.  Since this is a contrib app bundled with django, I am hesitant to spend too much time on it without some sort of positive and/or constructive feedback from someone who can accept the changes.

On topic... the brief summary for #21644 is that this allows for "confirmation" steps in a formwizard that have access to the data submitted for previous steps.  This is required for something like a checkout confirmation or anything where the user needs to be presented with data entered previously for acceptance to be meaningful.  It was important to my use case that the wizard supports multiple confirmation steps.  I've used a base class that confirmation forms should inherit from to detect when confirmation logic should be used.  This allows for a backwards compatible opt-in approach.

Thanks,
Gordon

Tim Graham

unread,
May 26, 2014, 6:04:31 PM5/26/14
to django-d...@googlegroups.com
My observation is that not many core developers seem interested in contrib.formtools these days. It was added by Adrian in 2006, but as far as I can see from the commit history, it hasn't received much love lately. If would be a good candidate for deprecation from Django itself, in my opinion.

Gordon

unread,
May 26, 2014, 6:51:13 PM5/26/14
to django-d...@googlegroups.com
Fair enough and thanks for the reply.  That is too bad though.  I've seen a good number of 3rd party apps that would benefit from using the NamedUrlWizardView (https://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/#usage-of-namedurlwizardview).

Tim Graham

unread,
May 26, 2014, 7:08:29 PM5/26/14
to django-d...@googlegroups.com
If we did split it out, would you be interested in being a maintainer?

Gordon

unread,
Jun 2, 2014, 2:27:07 PM6/2/14
to django-d...@googlegroups.com
How would that work? Being part of contrib is a big plus for the app in many ways. I am not familiar with another app that was removed from contrib that would show an overview of the process and if it was successful.

Thomas Leo

unread,
Jun 2, 2014, 6:15:09 PM6/2/14
to django-d...@googlegroups.com

The company I'm currently contracting for, makes heavy use of formtools, I'd be disappointed to see it go.

On Monday, May 26, 2014 6:04:31 PM UTC-4, Tim Graham wrote:

Tim Graham

unread,
Jun 2, 2014, 6:42:59 PM6/2/14
to django-d...@googlegroups.com
contrib.databrowse is an example of something that was removed from Django. It seems to have found a home here: https://pypi.python.org/pypi/django-databrowse

Deprecation of contrib.formtools was actually proposed on the mailing list in 2011, see https://groups.google.com/d/topic/django-developers/P_WMxmOCJFY/discussion

At that time Carl and Jannis were -0 due to some recent improvements. I wonder if they feel any differently now.

Jannis: "FYI, formtools is unlikely to go away anytime soon, as we've just
recently added a new class based views wizard [1]. Next step would
be to refactor the form preview tool to be class based, too [2].

1: https://docs.djangoproject.com/en/dev/releases/1.4/#new-form-wizard
2: https://code.djangoproject.com/ticket/16174


Carl: "-0 on formtools at this point for the same reason Jannis
mentioned; it is actually actively maintained and used, and recently got
some major improvements. In the abstract I do think that formtools is a
fine candidate to be an external app rather than live in contrib, I just
think we may as well start with the lower-hanging fruit here."

Jannis Leidel

unread,
Jun 3, 2014, 6:17:55 AM6/3/14
to django-d...@googlegroups.com
Hi all,

I’ve actually changed my mind about this after we successfully pulled out django-localflavor (another niche contrib app) after some initial bumps. It’s now maintained under the Django umbrella org on Github: https://github.com/django/django-localflavor/

I would like to propose to do the same with formtools and release it as django-formtools.

- Move formtools out of contrib ASAP
- Allow more maintainers next to Django core devs
- Release individually from Django on PyPI as django-formtools
- Maintain backward compatibility similar to localflavor (in short: support the currently supported Django versions)

What do you think?

Carl, any change in opinion with regard to that as well?

Best,
Jannis
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6ad1f913-4508-41d9-ab8e-e2076f83839f%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

signature.asc

Marc Tamlyn

unread,
Jun 3, 2014, 6:25:51 AM6/3/14
to django-d...@googlegroups.com
In my opinion, the reasoning for whether something should be a part of contrib is as follows:

- The application is of vital importance to the vast majority of Django sites, and needs to be done "correctly". Examples include auth and staticfiles, sessions.
- The application closely depends on internal, undocumented features of Django or is strongly intertwined with the core features like the ORM. Such applications are often very difficult to maintain their feature support across multiple versions of Django. Examples include gis, postgres, contenttypes.

To me, formtools meets neither of these requirements. It is not a 90%+ use case application like the admin or auth, and I don't believe there is much to it that is not workable outside of Django itself. It is useful, and does not deserve to be abandoned (like comments). Under github.com/django seems ideal to me.

Marc

Josh Smeaton

unread,
Jun 3, 2014, 8:53:07 AM6/3/14
to django-d...@googlegroups.com
If formtools were to be pulled out and released separately, would that theoretically mean that releases could come more frequently than django core (provided there was community interest and maintenance)? I think that would be a decent carrot for community members that rely on its functionality.

Regards,

Jannis Leidel

unread,
Jun 3, 2014, 9:22:51 AM6/3/14
to django-d...@googlegroups.com
On 03.06.2014, at 14:53, Josh Smeaton <josh.s...@gmail.com> wrote:

> If formtools were to be pulled out and released separately, would that theoretically mean that releases could come more frequently than django core (provided there was community interest and maintenance)? I think that would be a decent carrot for community members that rely on its functionality.

Yeah, that’d certainly be a possibility—assuming there is enough interest and maintenance work going on. For localflavor we’ve so far elected to do releases close to Django releases. But that’s mostly a practicality as the main maintainers (Erik and me) are both core devs.

Of course the same core values of maintenance like keeping backward compatibility etc would need to apply to an extracted app. That’s a feature we would need to be carefully look out for if formtools would be extracted.

Jannis
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/386bad7b-14e8-4e3a-ae44-94f3c8975f54%40googlegroups.com.
signature.asc

Gordon

unread,
Jul 3, 2014, 9:32:18 AM7/3/14
to django-d...@googlegroups.com
If we did split it out, would you be interested in being a maintainer?


I was against this at first but the more I've thought about it, I would be interested.  Has anyone else expressed any interest or will I be the only maintainer?

I have another project coming up that will most likely use formwizard.  What type of time frame would it take to get all of this set up if django decides to split formtools from contrib?
Reply all
Reply to author
Forward
0 new messages