Then forget about ajax.*
What I am thinking is to change url dispatcher
to create three as many lists as the http methods is
GET = ()
POST = ()
DELETE = ()
...
ALL = ()
And then while parsing an urls.py it appends fitting matches to those
lists.
When goes request, for example GET, than dispatcher lookup regexp
pattern in GET lists,
if its find, we have a hit, if not go to ALL dict, if it isn't there
throw 404
This Classed based view method is good, but you have to create one
abstract view and then inherit in all your views to do so. Unless you
want to write a lot of boilerplate code per view
--
Matt Harasymczuk
www.matt.harasymczuk.pl
On Mar 21, 8:44 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> 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.
