URL Resolvers: a little refactoring goes a long way

[Ken Arnold]

newforms-admin has a special-cased URL dispatcher in site.py. (see
#6470)

Various REST-ish frameworks have a '.*' url mapping and a similar
hacky dispatcher.

Django has a nice URL dispatcher in core/urlresolvers.py, which could
drop in and replace those ad-hoc dispatchers. Only it takes the name
of a module where you'll find urlpatterns, instead of urlpatterns
itself. Removing that one assumption to a subclass makes
RegexURLResolver immediately more useful.

I've pulled the common functionality into a BaseRegexURLResolver,
which takes (regex, url_patterns, default_kwargs) in __init__. If
url_patterns is callable, it calls it before first use and takes the
result.

RegexURLResolver then inherits from BaseRegexURLResolver, but
overrides url_patterns to lazily import the module.

I've tried using the newly factored base class in my version of a
RESTful Resource class, and so far I like the results. The naming of a
few things could use some more thought, though. A tangible upshot is
that nested resources become much easier to configure; some recent
email on this list discussed that.

Patch? I got a little carried away improving the documentation and
trying to fix #4824, so the diff looks much scarier than the change.
The result lives temporarily at
http://code.google.com/p/django-webapp/source/browse/trunk/dwa/urlresolvers.py.
I haven't run the test suite on it, but I've tried two of my apps on
it and they work. (The attempt at fixing #4824 actually caught a minor
bug in my app code...)

I wanted to get any feedback on this change before submitting a
ticket, but if people think it's a good idea, I can clean up the patch
and make a ticket.

-Ken

[David Larlet]

Ken,

It looks interesting but are there any examples of your urlresolver
usage?

David

Le 24 juin 08 à 21:35, Ken Arnold a écrit :

[Gary Wilson Jr.]

Ken Arnold wrote:
> I wanted to get any feedback on this change before submitting a
> ticket, but if people think it's a good idea, I can clean up the patch
> and make a ticket.

Anything that gets REST projects and nfa off the ad-hoc dispatchers
sounds like a good idea to me. Along with a ticket and patch, it would
be nice to see what nfa's dispatching looks like with the changes. If
you feel like it, please put those changes in the patch as well or
attach a separate patch.

Thanks,
Gary

[Ken Arnold]

Okay, I've submitted #7537 with three patches. I manually split out
sub-changes from a previous version, so some things may be broken, but
hopefully in simple ways.

The first patch at least could go in almost as-is (one little design-
decision FIXME) and would be immediately helpful. The second is icing
on the cake, but the actual code change is very minor.

The third patch is -- let me say it again -- example only. I don't
understand that core nfa logic, so it's actually broken. But one
feature about it to note is how I've resolved (for another project)
the issue of decorating instance methods. For example, in the nfa
sites.py, if the never_cache decorator actually tried to do something
with `request`, it would break because the first parameter it sees is
`self` (the AdminSite instance), not `request`. But using instance
methods as views is a powerful pattern (see my post
http://lethain.com/entry/2008/jun/22/json-object-oriented-views-and-starting-a-real-app/),
so I figured out a way to work around that problem: the
instance_decorator descriptor that I pasted at the top of that patch.

-Ken

[SmileyChris]

I know that a URL resolver refactor is on Malcolm's neverending todo
list. When he starts getting back into it, feel free to remind him of
it. :)