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
-~----------~----~----~----~------~----~------~--~---
