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

[Nathan Yergler]

For some reason I thought the patch was already applied. Happy to look
at it again and push it. What's the preferred way to do that? Github
pull request? Gitorious merge request? Something else?

NRY

On Tue, Mar 27, 2012 at 8:16 AM, Asheesh Laroia <lists at asheesh.org> wrote:
> 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.
> _______________________________________________
> Devel mailing list
> Devel at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/devel