[OH-Dev] Problem solved for now -- Re: Trying to Use Form Validation in Class Based Generic Views
lists at asheesh.org
Tue Mar 27 15:16:07 UTC 2012
Nathan -- great to hear you'll spend some time on missions-writing
documentation this weekend! That has been a long-standing goal of the
Now seems like a good time to polish up this draft sitting in my email!
Excerpts from Nathan Yergler's message of Sun Mar 18 22:10:04 -0400 2012:
> Concur. Getting the class inheritance right can be tough for people
> who really want to leverage Django's class based views, so I think
> having a base OpenHatch view makes a lot of sense.
> > e.g.
> > * I would move success_url to be a string (the urls.py short name) in
> > the Form subclass.
> The view name or the resolved URL? When I initially wrote my patch I
> had something like:
> class View:
> success_url = reverse('view-name')
Django 1.4 has lazy reversal now, apparently. Django 1.4 was recently
released, and I can probably upgrade OpenHatch to use+bundle Django 1.4
> which didn't work since reversing a URL requires importing modules,
> and importing the view module required reversing the URL (ka-boom). If
> you want to make it the view name, I suggest naming the property
> something like "success_view", and overriding get_success_url in your
> parent view. That avoids assigning semantics to success_url that
> differ from Django's and simplifies the child classes.
I like this re: success_view.
> > * class Checkout should have:
> > mission_step_name = 'svn_checkout'
> > and then the default form_valid() machinery should set the mission step
> > as completed.
> Makes sense.
> > * Perhaps all the missions forms should implicitly take the username as
> > a forms_kwarg? But then you couldn't use these mixins with non-Missions
> > forms, which would be odd.
> I could go either way with this one... if all the existing mission
> forms (or > 80%) use a username right now, then I say do it. If you
> want to further reduce the burden for contributors just give them a
> form super class that has a different __init__. If you really want to
> be magical you could write get_form_kwargs such that it sees if you're
> dealing with a subclass of UserMissionForm and adds the username kwarg
> if you are.
> How many of the mission forms do you think have username-dependencies
> right now?
Just svn has it, although future ones are likely to have it.
> > * Then we could write a super-simple write-your-own-training-missions
> > HOWTO.
> Cool. I'd be happy to help with that from a class-based-view perspective.
That'd be totally rocking, and should live in docs/.
> > This is the kind of thing that I intended for handling in these tickets:
> > * http://openhatch.org/bugs/issue645
> > * http://openhatch.org/bugs/issue666
> > (surely others also)
> > As I understand things, Jacquie plans to make some further code commits to
> > do some of this move. I think we should keep conversing and sketching the
> > code out here on OH-Dev -- Jacquie would probably appreciate the concreteness
> > we're bringing to the conversation, as compared to my vagueness on those
> > bugs!
> > So Nathan (and all) -- do you think the above sorts of things I'd want
> > to change are possible?
> And I've attached an updated patch with most of the code changes. It
> also contains one other change, renaming template references from
> "svn_checkout_form" to "form". That puts you in sync with what the
> Django form views expect, and allows us to eliminate one more custom
Sorry it took me until now -- still want review+push on this patch?
More information about the Devel