On Mon, Mar 21, 2011 at 9:09 AM, haras.pl <m...@harasymczuk.pl> wrote:
> It would be nice to have possibility to distinguish a HTTP method in
> urls.py. IMHO it would be clearer and more extensible in future for
> example:
> ajax ('POST', r'/user/(?P<username>\d+)$', 'views.view2'),
> ajax ('GET', r'/user/(?P<username>\d+)$', 'views.view2'),
> ajax ('DELETE', r'/user/(?P<username>\d+)$', 'views.view2'),
...
> I think this is a good way of getting rid of nested ifs in each view:
>
> if request.is_ajax:
> #do stuff
> else:
> if request.method == "POST":
> #do something
> else:
> #do else
>
> Hence my true code is almost two indents inside those boilerplate if
> structure. Which is always the same... it takes a lot of python beauty
> and readibility from code.
While I can see where this request comes from, I agree with the triage
review that the ticket has received -- that this isn't necessary. This
is for three reasons:
* As noted on the ticket What you are describing can already be done
with class-based generic views, and a class-based resource structure
is a much better way of gathering concerns than three lines in a URL
config file
* Even if you don't want to use class-based resources, you could
easily generate a wrapper function to direct to subviews as required
based on request methods:
def dispatched_view(get_view=None, post_view=None):
def _view(request, *args, **kwargs):
if request.method == "POST":
return post_view(request, *args, *kwargs)
return get_view(request, *args, **kwargs)
return _view
and then, in your urls.py:
url(r'/user/(?P<username>\d+)$', dispatched_view(GET=get_view, POST=post_view))
Your definition of ajax_view could be a lot more complex than that,
including handling for the is_ajax flag, other HTTP verbs, and so on.
* Lastly, even if the previous two approaches didn't exist, the
proposal you have made requires a pretty egregious duplication of
regular expressions. This is both a performance hit (since you need to
match the same regular expression pattern multiple times), as well as
a potential source of error (since you are repeating yourself).
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.
