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/urlres....
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.
> 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/urlres... > . > 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 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.
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-s...),
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
On Jun 25, 9:41 am, "Gary Wilson Jr." <gary.wil...@gmail.com> wrote:
> 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.