Is it a good practice to delegate views based on GET / POST?

75 views
Skip to first unread message

John Yeukhon Wong

unread,
Apr 10, 2012, 11:21:15 PM4/10/12
to django...@googlegroups.com
3/4 down the page
http://www.djangobook.com/en/2.0/chapter08/
urlpatterns = patterns('', # ... (r'^somepage/$', views.method_splitter, {'GET': views.some_page_get, 'POST': views.some_page_post}), # ... )

Is this a good practice at all? If I use the method splitter, my urls will look ugly. Or should I just separate based on the length of certain views? (If it's too long, break it into two, or use the delegator)

andrea mucci

unread,
Apr 10, 2012, 11:25:57 PM4/10/12
to django...@googlegroups.com
hi 

this is something personal choice
i prefer to check GET and POST directly from the view method, but in some case is useful to part the GET and the POST view for readable and clean coding


--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/AzISlKRiq0UJ.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

Kevin

unread,
Apr 11, 2012, 6:05:27 AM4/11/12
to django...@googlegroups.com
Separating GET and POST is normally used for RESTful web programming.  Which is becoming a very common practice is popular competing frameworks, such as Rails.

Personally I would prefer a more "native" way in Django to separate GET/POST views.  I guess this could be done via a decorator or something.

Another reason you may want to separate GET/POST is for security.  For example, only letting some views accept POST requests, and basically shove a big 403 message to users who attempt to POST to a view which otherwise shouldn't accept a POST.  I normally limit this using the web server, so POST requests will not even reach the web application if the component doesn't even accept it.  I always have a mind set that the Internet is never safe, and everybody is a hacker.  It's better to be safe, than sorry that a malicious POST body reached your application.  An easy way to do this on the server is to use a regex mask for views which will accept a POST body, such as having an extension of ".do" or ".action".  If the view doesn't have this special extension, then only allow GET requests to pass through to WSGI.  You can also filter out headers and such on the server to further protect your WSGI application from the outside world.  If you don't have access to the server's configuration, well, then I'm sure the cloud service you deployed to is "safe enough".

John Yeukhon Wong

unread,
Apr 11, 2012, 8:49:34 PM4/11/12
to django...@googlegroups.com
Thanks to both of you. Kevin, how would I do a regex mask for views?

Thanks.

sbrandt

unread,
Apr 13, 2012, 11:47:44 AM4/13/12
to Django users
Sorry, answered directly to author by accident.



Isn't this achieved by using class based views?


from django.views.generic import View
class MyView(View):
def get(request, *args, **kwargs)
...
def post(request, *args, **kwargs)
...

In addition, you can use the built-in mixins. Also, the django-rest-
framework uses this paradigm and it's amazing. So why use such a
strange method like mentioned in the django book?
Reply all
Reply to author
Forward
0 new messages