Proposal: refactoring URL resolution

5 views
Skip to first unread message

Ken Arnold

unread,
Sep 15, 2008, 5:10:41 PM9/15/08
to Django developers
I previously brought up a URL resolution refactoring (http://
groups.google.com/group/django-developers/browse_thread/thread/
e16bcd24f9e27062/a84b8e58fe2e7786), and was wisely told to hold off on
it. I thought this might be a good time to bring it up again.

I'm just going to suggest the simplest thing that might possibly work;
please comment.

URL resolver interface:
- resolve(path) returns (view_function, args, kwargs), just like
existing interface
- reverse(name, *a, **kw) returns URL path

That's not new. Here's the difference: a URL configuration /is/ a
resolver. We just abstract the special case about importing a module.
For example, an AdminSite is a resolver. It can just inherit from
RegexURLResolver (or whatever). Instead of the ad-hoc resolver in
'root', it has a 'resolve' method that maybe checks a few special
cases and then calls super.resolve. To use this in a site's urls.py:

patterns('',
(r'^admin/$', admin.site),
)

Backwards compatibility in the general case is easy: conf/urls/
defaults.py includes a 'resolve' (which lazily constructs a
RegexURLResolver) and 'reverse' method. We're already importing * from
that file anyway.

Incidentally, this allows 'include' to be noting special; if it's a
string, just import it; it's already a resolver.

One little wart I've thought of is the 404 and 500 handler. Maybe we
add a resolve_special method (e.g., resolve_special('404') that acts
on the root resolver.

Another wart: the initial '/' (look at core.handlers.base for resolver
to see what the issue is). How about we just strip it off before
trying to resolve?

I hope this is enough detail to see what I'm talking about. Actual
code modification is small, so I have no qualms doing it myself; I
just wanted to run the concept by in general first. (This is similar
but not identical to my prior proposal / code.)

-Ken

Malcolm Tredinnick

unread,
Sep 16, 2008, 8:14:20 PM9/16/08
to django-d...@googlegroups.com

On Mon, 2008-09-15 at 14:10 -0700, Ken Arnold wrote:
> I previously brought up a URL resolution refactoring (http://
> groups.google.com/group/django-developers/browse_thread/thread/
> e16bcd24f9e27062/a84b8e58fe2e7786), and was wisely told to hold off on
> it. I thought this might be a good time to bring it up again.
>
> I'm just going to suggest the simplest thing that might possibly work;
> please comment.
>
> URL resolver interface:
> - resolve(path) returns (view_function, args, kwargs), just like
> existing interface
> - reverse(name, *a, **kw) returns URL path
>
> That's not new. Here's the difference: a URL configuration /is/ a
> resolver. We just abstract the special case about importing a module.
> For example, an AdminSite is a resolver. It can just inherit from
> RegexURLResolver (or whatever). Instead of the ad-hoc resolver in
> 'root', it has a 'resolve' method that maybe checks a few special
> cases and then calls super.resolve.

You don't mention what problem are you trying to solve with this change?
Sure, we could do this and certainly make it fully backwards compatible,
but why is it needed?

You can already put any object you like that has a resolve() method into
urlpatterns(). That object can see every single pattern that passes
through if it is matched for the pattern ''. We have to *some* kind of
root object and it happens to be RegexURLResolver.

Right now, in various pieces of client code, I've written classes that
variously (a) implements Joe Gregorio's URL patterns, (b) adds support
for "name=" prefixes on included URL patterns and (c) looks up the URL
correspondence via an external script to determine where to dispatch to.

All three of these were written to meet various client needs and work
quite happily as part of urlpatterns(). I can't think of a case where
I've needed something above that. You clearly have something in mind, so
time to spill the beans (please).

Regards,
Malcolm

Joost Cassee

unread,
Sep 21, 2008, 11:30:57 AM9/21/08
to Django developers
On 17 sep, 02:14, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:
> On Mon, 2008-09-15 at 14:10 -0700, Ken Arnold wrote:
> > I previously brought up a URL resolution refactoring (http://
> > groups.google.com/group/django-developers/browse_thread/thread/
> > e16bcd24f9e27062/a84b8e58fe2e7786), and was wisely told to hold off on
> > it. I thought this might be a good time to bring it up again.
> [...]
> You can already put any object you like that has a resolve() method into
> urlpatterns(). That object can see every single pattern that passes
> through if it is matched for the pattern ''. We have to *some* kind of
> root object and it happens to be RegexURLResolver.

On that vein, would it be possible to add a hook to customize the root
object class? The usecase would be my localeurl application [1], that
currently needs to monkey-patch the reverse function (which I consider
to be a bug).

Regards,

Joost

[1] http://code.google.com/p/django-localeurl/
Reply all
Reply to author
Forward
0 new messages