On Mon, 2006-06-26 at 10:30 +0100, Simon Willison wrote:
> I've been playing around with making the URL resolver accept a
> callable in addition to accepting 'module.blah' strings, and I think
> it's a big improvement.
>
> The change itself is very simple - when a URL is resolved, callable
> (callback) is used to decide if the callback is already a callable
> object; if it is, it is called directly rather than being resolved in
> to a module/method first. It ends up being a two line patch.
>
> This then makes urls.py a whole lot more flexible. Here's an example:
>
> def redirect(url):
> def fn(request):
> return HttpResponseRedirect(url)
> return fn
>
> urlpatterns = patterns('',
> (r'^$', redirect('/HomePage/')),
> (r'^(\w+)/$', 'djwiki.views.wikipage'),
> ...
> )
>
> That redirect function can either exist in urls.py itself, or can be
> dropped straight in to djange.conf.urls.defaults (since all urls.py
> files start with 'from django.conf.urls.defaults import *').
>
> Allowing callables in urlconfs opens up a whole bunch of other
> opportunities as well. Setting up generic views could be made much
> less fiddly:
>
> from django.views.generic import ListDetail
> from models import Things
>
> thingviews = ListDetail(Things.objects.all())
>
> urlpatterns = patterns('',
> (r'^$', thingviews.object_list),
> (r'^(\d+)/$', thingviews.object_detail)
> ...
> )
>
> In fact, a whole bunch of stuff that currently has to be done with
> global settings or duplicated arguments could be handled in the URL
> configuration Python file instead.
I'm a little wary of encouraging people to put too much logic in the
URLConf files, but at the same time, I can see that it might make some
things easier and arbitrary restrictions are probably bad.
I guess I'm +0 on this at the moment, but I suspect that is because it
doesn't grab me in the "wow! nice!" way that some changes do. So pretend
I have no opinion. My real contribution to the thread is the next
paragraph.
>
> Another advantage that this offers is a more elegant alternative to
> the common prefix problem. Right now, if you are using a bunch of
> views from a certain module the recommendation is to do the following:
>
> urlpatterns = patterns('path.to.some.moduleviews',
> (r'^$', 'index'),
> (r'^(\d+)/$', 'detail')
> ...
> )
>
> This only works if EVERY view comes from the same module - if you
> want to mix and match views from different modules you're back to
> specifying the full path for each one (or futzing around with include
> ()).
Another thing we need to document better here, because this claim is not
quite correct (didn't you help write this?). The patterns() function
returns a normal Python list. So you can just append successive calls to
patterns() to each other:
urlpatterns = patterns('website.weblog.views',
# Latest entries.
(r'^$', 'display.section'),
...
)
urlpatterns += patterns('',
(r'^feeds/(?P<url>.*?)$',
'django.contrib.syndication.views.feed',
{'feed_dict': feeds.feed_mapping}),
)
So (Jedi-like wave of hand), these are not the... er.. there is no
prefix problem.
Best wishes,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
