On Sun, Oct 23, 2011 at 10:48 AM, Carl Meyer <c...@oddbird.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>> The official Django Docs for forms offers up the following pattern for
>> Form view code:
>>
>>     def contact(request):
>>         if request.method == 'POST': # If the form has been submitted...
>>             form = ContactForm(request.POST) # A form bound to the POST data
>>             if form.is_valid(): # All validation rules pass
>>                 # Process the data in form.cleaned_data
>>                 # ...
>>                 return HttpResponseRedirect('/thanks/') # Redirect after
>>     POST
>>         else:
>>             form = ContactForm() # An unbound form
>>         return render_to_response('contact.html', {
>>             'form': form,
>>         })
>>
>>
>> https://docs.djangoproject.com/en/dev/topics/forms/
>>
>> I was just viewing a talk by pydanny and Miguel Araujo at DjangoCon US
>> 2011 on "Advanced Django Form Usage", and they offered up what they seem
>> to feel was a better pattern for form viewcode:
>>
>>     def some_view(request, template_name="someapp/someform.html")
>>         form = MyForm(request.POST or None)
>>         if form.is_valid():
>>             do_x()
>>             return redirect('Home')
>>         return render(request, template_name {'form': form}).
>>
>>
>> http://speakerdeck.com/u/pydanny/p/advanced-django-forms-usage (Slide 13)
>>
>> Now, apart from being shorter, I don't think I know enough about Django
>> or forms to know which one is actually "better" overall. However, what's
>> the community's consensus on this?
>
> I think this might have been mentioned in an audience question at that
> talk: the shorter code does have an edge-case problem. It is possible
> for request.method to be "POST" and for request.POST to be empty.

Yes, it was raised -- by me :-)

In my opinion, "MyForm(request.POST or None)" is an antipattern -- it
saves you a line of code, and one level of indentation; but it
obscures the distinction between POST and GET requests, is fragile in
the case of empty POST dictionaries, and doesn't work as a shortcut as
soon as you have other POST specific form pre-processing.

Part of good programming practice is ensuring that your code is easy
to read, and being explicit about the fact that you're handling a POST
is just good practice IMHO.

I'd be -1 on adding any reference to this shortcut as a suggested or
alternate rendition of form handling as part of Django's official
documentation. Anyone with enough Python experience will be able to
work out that this shortcut is possible. The only reason I can think
of to include mention of this shortcut in Django's documentation would
be as a cautionary note for what *not* to do.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to