Ah, ok.. I understand a little better now what you are trying to do.
I definitely agree that a solution to this would be a useful addition;
I would only advocate for considering the "request.stem" method
instead. As with your patch, it is completely backwards-compatible
and works with nested incl
Well, Matt and Adrian closed the ticket with some similar argument.
But I respectfuly disagree :-)
In muramas example above, (r'^news/', 'myproject.apps.news.urls',
{'stem':'news'}) this does not solve my problem, because in my case
(assuming that this pattern is in an included urls.py) the stem
I actually wrote a patch yesterday to solve the same problem, but for
different reasons (and using a different method). From my
perspective, the larger problem that access to the URL 'stem' can
solve is to decouple apps from projects, making it much easier to
write relocatable, "drop-in" applicat
Well, I went ahead and created a patch for this. It is in ticket 3402
(http://code.djangoproject.com/ticket/3402)
--
Thanks,
Medhat
On Jan 26, 12:18 pm, "medhat" <[EMAIL PROTECTED]> wrote:
> the url should behttp://www.example.com/categories/x/
>
> --
> Medhat
>
> On Jan 26, 12:12 pm, "medhat"
In the case of the parent->child->grandchild, the grandchild view will
get the stem for everything before the grandchild urls.py (In my case,
I really did not care how many urls.py it went through, my main problem
is that the same view can be called by multiple urls, and I wanted in
each case to
I'd suggest doing it as middleware which appends to the request (sorta
like the user middleware). This way it's available in the view as well
as the template context (if you pass it explicitly or use the request
context processor).
Also, what about urls.py deeper than just parent->child? Maybe st
the url should be http://www.example.com/categories/x/
--
Medhat
On Jan 26, 12:12 pm, "medhat" <[EMAIL PROTECTED]> wrote:
> Here is even a better idea...
>
> in your urls.py when you "from django.conf.urls.defaults import *" this
> will import 'stem' in addition to the usual things. In any url
Here is even a better idea...
in your urls.py when you "from django.conf.urls.defaults import *" this
will import 'stem' in addition to the usual things. In any url pattern,
if you add {'param_name':stem} to the extra options, your view will get
a keyword argumant called 'param_name' and will ha
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 ite
