An idea for urls.py and maybe reverse url resolving
medhat
------------------
Ok,
I have been thinking about this for about an hour now... and I would
like to get
some feedback from you.
First, the problem that I was initially trying to solve:
I have multiple models, all of which can be tagged. I also have a Tag
model with a
custom manager that can return tags for an item, a list of items, or
for a model
type; or inversly you can give it some tags, and it will give you back
the items
that are tagged with that tag (optionally you can restrict the returned
items to a
type)
And I have the following urls:
/tags/x/ in the root urls.py (will return all items that
have tag x
irrespective of their type)
/photos/tags/x/ in the photos application's urls.py (will return all
photos that
have tag x)
both of these urls call the same view, but the second one will pass the
type in the
extra options where in the first one it will default to None (from the
default valie
in the view)
In the final html will have a list of other tags that you can click.
For example,
first I will get all the photos that have tag x, then get all the tags
of these
photos, and have a link for each one of these tags on the final page.
My problem is that the link for tag y in the second case should be
/photos/tags/y
and in the first case should be /tags/y
At first this seemed like a good candidate for some Reverse URL
hackery... but then
I thought, when the url matching is done, when does django get rid of
what was
matched when it finds an include?! Imagine if the view is defined as:
def view_function(context,stem, .... ) where stem is the part of the
url that was
matched before jumping into the urls.py that has the called view that
would solve my
problem (and probably a lot of the problems that led to the creation of
urlresolver.reverse.
I am willing to work on a patch that will implement this. But I also
understand that
this will be a huge backwards incompatible change (since "stem" will
need to be
added to each view function) So, I am expecting that people will not be
so warm to
the idea.
Another alternative, which I don't like as much, but will be backwards
compatible is
to add "stem" to the request object (even though I understand this is
not really a
request property)
So, I would like to hear what you guys think.
--
Thanks!
Medhat