[OH-Dev] Problem solved for now -- Re: Trying to Use Form Validation in Class Based Generic Views

[Asheesh Laroia]

Nathan -- great to hear you'll spend some time on missions-writing
documentation this weekend! That has been a long-standing goal of the
project.

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.

Agreed!

> > 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
this week.

> 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.

Yay.

> > * 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?
> 
> Yup.
> 
> 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
> override.

Sorry it took me until now -- still want review+push on this patch?

-- Asheeesh.