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

[Nathan Yergler]

Sorry for the delayed reply, we had a major-minor meltdown at work on
Thursday that sort of sucked up all of my ability to think about
software for 48 hours. I took a look at the test in question, and
after pulling things apart for a bit, believe I found the issue. Well,
two issues.

First, the magic keyword argument for overriding the context is
extra_context_data, not extra_context. So checkout_submit() was
passing in an extra_context kwarg and MissionBaseView.get_context_data
was looking for extra_context_data. That's the first problem.

The second was/is that Checkout.get_context_data is clobbering the
svn_checkout_form with a new form instance. Making that conditional
(if 'svn_checkout_form' not in data: data['svn_checkout_form'] =
forms.CheckoutForm()) takes care of that problem. See the attached
diff (dont_clobber.patch) for both changes.

Thinking about the larger problem (using the same handler for get +
post, with some additional data from a post), I think we can clean
things up a little. Is this Checkout example a good one for the
problem? The only thing that seems to be getting passed in as
extra_context_data is a possible error message and form instance. My
first instinct is that this looks a lot like the FormResponseView. Is
that something you've looked at and discarded? I have a more invasive
patch attached, form_views.patch, that I *think* cleans things up and
eliminates the need to fake the request method. The form processing
views in Django can be complex and intimidating, but they're pretty
powerful. I'd love to hear what people think about the latter patch
(and I'm happy to help apply it more widely to the codebase over
time). Even if the problem isn't limited to forms, I suspect a similar
idiom can be applied: a .post() handler that calls .get() with the
result of a special method like self.get_extra_context(). I think
that'd make it easier to follow and debug the code (ie, no wondering
why your method is GET when you "know" you made a POST).

Best,

NRY


On Thu, Mar 15, 2012 at 12:01 PM, Asheesh Laroia <lists at asheesh.org> wrote:
> Excerpts from Jacquie Flemming's message of Wed Mar 14 21:11:28 -0400 2012:
>> done.
>
> So...
>
> we're trying to create a modified version of the class-based TemplateView
> that takes an extra_context_data dictionary, and uses extra_context_data
> to overwrite data that the get_context_data() method creates.
>
> The idea is to let the POST handler for a view return the GET handler's
> response, but to let the POST handler clobber some data in the GET handler
> so that it can e.g. override the form with the user-submitted form with
> validation errors.
>
> Right now, we have to call data.update(extra_context_data) manually. It's
> not the most elegant thing.
>
> Nathan, I think you're the person here with the most class-based views
> experience; I'd love your feedback as this matures. The idea is to let
> people write very straightforward code as they write new training missions.
>
> -- Asheesh.
> _______________________________________________
> Devel mailing list
> Devel at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dont_clobber.patch
Type: text/x-patch
Size: 984 bytes
Desc: not available
URL: <http://lists.openhatch.org/pipermail/devel/attachments/20120318/6d18d9da/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: form_views.patch
Type: text/x-patch
Size: 6799 bytes
Desc: not available
URL: <http://lists.openhatch.org/pipermail/devel/attachments/20120318/6d18d9da/attachment-0001.bin>