I totally agree that returning an object is the way to go. I know a lot of
other folks are busy getting the next release out, but after that, I am happy
to submit a proposed patch. I think it should be straightforward to preserve
the current api while still adding new functionality.
On Apr
You can take this idea further by not providing the name but the
resolver object. This gives you much more flexibility. It might be
helpful to have it in the result of the reverse dict.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to t
> From: Ulrich Petri
>
> Am 16.04.2009 um 21:12 schrieb Steve Howell:
> > http://www.djangosnippets.org/snippets/1444/
> >
> > In writing this code, it occurs to me that other
> advanced users might
> > want more control over URL resolution, and it seems to
> me that a
> > valuable piece of inf
Am 16.04.2009 um 21:12 schrieb Steve Howell:
> http://www.djangosnippets.org/snippets/1444/
>
> In writing this code, it occurs to me that other advanced users might
> want more control over URL resolution, and it seems to me that a
> valuable piece of information would be the "name" of the URL, i
I recently wrote some code to overcome the below limitation with the
URL include mechanism:
''' Note that extra options will always be passed to every line in the
included URLconf, regardless of whether the line's view actually
accepts those options as valid. For this reason, this technique is
on
