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 includes; I find it slightly more simple/
unintrusive, as you don't need to add anything to the URLconf in order
to use the stem in a view.
I haven't written docs/tests for the request.stem patch yet, but I can
do so and post it if anyone is interested for the sake of comparison.
On Jan 31, 10:56 am, "medhat" <[EMAIL PROTECTED]> wrote:
> 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 is not
> 'news' it is whatever was matched in the urls.py that included this
> current one.
>
> In the ticket the argument was that in the including urls.py you can
> have something like:
> (r'^(?P<section>news)/', include('myproject.apps.news.urls')),
> and then use section as a kwarg. I see some problems with this:
>
> 1. This will only work for one level of includes (granted I only have
> one urls.py that is a second level, and probably no one will ever need
> more than two levels) Of course you can do something similar for more
> levels but it will be very messy.
> 2. The more you add parameters to the pattern, the more it becomes
> complex and harder to read.
> 3. Doing it this way (?P<section>news) will force me to have a
> 'section' kwarg for every view in the included urls.py while I only
> need it for only one view.
> 4. In the django documentation, it says the following on the URL
> Dispatcher page "Whenever Django encounters include(), it chops off
> whatever part of the URL matched up to that point and sends the
> remaining string to the included URLconf for further processing." And
> that's what sounded weird to me... "it chops off..." why chop off
> something that seems to be useful to pass to the view?
>
> In my case, as I mentioned before, adding /tags at the end of almost
> any url will display a page with the tags of the item that was viewed.
> And on that page when constructing the links for the tags I want it to
> include the stem. So for example /galleries/tags will show only the
> tags in galleries (and all these tags will be links that will show
> gallery items with that tag) and /galleries/2004/tags will do the same
> thing but only for galleries of pictures that were taken in 2004. Same
> thing can be done for /blog/tags etc...
>
> My solution (the one in the patch in ticket 3402 is fully backward
> compatible, will only affect the views that *need* the stem, and is
> not affected by how many levels of includes there are. And imho I
> think it solves the problem in a simple non-obtrusive way.
>
> So, I would like you guys to reconsider the patch in light of this
> more in-depth explanation :-)
>
> --
> Thanks,
> Medhat
>
> On Jan 31, 8:02 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > 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" applications.
>
> > Currently, if an application wants to construct absolute URL's for
> > anything, one needs to either hardcode the 'stem' into the
> > application, and into the project's URLconf. (For most things, of
> > course, it is at least possible to use relative URLs, but it can
> > certainly be less convenient sometimes..) With the solution described
> > above (and in medhat's patch) you still need to know what the
> > particular application wants the stem to be passed as, so in a lot of
> > cases, it seems you might be just as well doing this:
> > (r'^news/', 'myproject.apps.news.urls', {'stem':'news'})
> > instead of:
> > (r'^news/', 'myproject.apps.news.urls', {'stem':stem})
>
> > The solution I went with was to add the stem transparently to the
> > request variable as the URLs are resolved. (I agree it's not exactly
> > a property of the request itself, so this might be suboptimal; it is
> > at least backwards compatible, though..) This would allow application
> > authors an easy way to refer to themselves absolutely, and let folks
> > installing those applications do so at any URL prefix with only a
> > simple include, and without having to figure out what stem variable
> > the app wants to be passed.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
