> 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 have the value of the
> part of the url that matched *before* going into that urls.py file.

> example:

> --- urls.py ---

> from django.conf.urls.defaults import *

> urlpatterns = patterns('',
>     (r'^categories/', include('apps.tags.urls')),
> )

> --- apps/tags/urls.py ---

> from django.conf.urls.defaults import *

> urlpatterns = patterns('apps.tags.views',
>     (r'^(?P<tag>[^/]*)/$','tag_list',{'stem':stem}),
> )

> ---------------

> In that case the urlhttp://www.example.com/tags/x/will call
> apps.tags.views.tag_list and pass it the request object and two keyword
> parameters: tag = 'x' and stem = /categories/

> I already have a patch that does this. I don't have unit tests or
> documentation yet. But if this looks like a patch that would be
> accepted, I can definitely work on the tests and documentation.

> --
> Thanks,
> Medhat

> --
> Medhat

> On Jan 26, 12:12 pm, "medhat" <medhat.ass...@gmail.com> 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 pattern,
> > if you add {'param_name':stem} to the extra options, your view will get
> > a keyword argumant called 'param_name' and will have the value of the
> > part of the url that matched *before* going into that urls.py file.

> > example:

> > --- urls.py ---

> > from django.conf.urls.defaults import *

> > urlpatterns = patterns('',
> >     (r'^categories/', include('apps.tags.urls')),
> > )

> > --- apps/tags/urls.py ---

> > from django.conf.urls.defaults import *

> > urlpatterns = patterns('apps.tags.views',
> >     (r'^(?P<tag>[^/]*)/$','tag_list',{'stem':stem}),
> > )

> > ---------------

> > In that case the urlhttp://www.example.com/tags/x/willcall
> > apps.tags.views.tag_list and pass it the request object and two keyword
> > parameters: tag = 'x' and stem = /categories/

> > I already have a patch that does this. I don't have unit tests or
> > documentation yet. But if this looks like a patch that would be
> > accepted, I can definitely work on the tests and documentation.

> > --
> > Thanks,
> > Medhat

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

> 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, "mura...@gmail.com" <mura...@gmail.com> 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.

> 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 have the value of the
> part of the url that matched *before* going into that urls.py file.

> example:

> --- urls.py ---

> from django.conf.urls.defaults import *

> urlpatterns = patterns('',
>     (r'^categories/', include('apps.tags.urls')),
> )

> --- apps/tags/urls.py ---

> from django.conf.urls.defaults import *

> urlpatterns = patterns('apps.tags.views',
>     (r'^(?P<tag>[^/]*)/$','tag_list',{'stem':stem}),
> )

> ---------------

> In that case the urlhttp://www.example.com/tags/x/will call
> apps.tags.views.tag_list and pass it the request object and two keyword
> parameters: tag = 'x' and stem = /categories/

> I already have a patch that does this. I don't have unit tests or
> documentation yet. But if this looks like a patch that would be
> accepted, I can definitely work on the tests and documentation.

> --
> Thanks,
> Medhat

> Also, what about urls.py deeper than just parent->child? Maybe stem
> should be a list of matches, one for each URLResolver?

> On Jan 27, 7:12 am, "medhat" <medhat.ass...@gmail.com> 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 pattern,
> > if you add {'param_name':stem} to the extra options, your view will get
> > a keyword argumant called 'param_name' and will have the value of the
> > part of the url that matched *before* going into that urls.py file.

> > example:

> > --- urls.py ---

> > from django.conf.urls.defaults import *

> > urlpatterns = patterns('',
> >     (r'^categories/', include('apps.tags.urls')),
> > )

> > --- apps/tags/urls.py ---

> > from django.conf.urls.defaults import *

> > urlpatterns = patterns('apps.tags.views',
> >     (r'^(?P<tag>[^/]*)/$','tag_list',{'stem':stem}),
> > )

> > ---------------

> > In that case the urlhttp://www.example.com/tags/x/willcall
> > apps.tags.views.tag_list and pass it the request object and two keyword
> > parameters: tag = 'x' and stem = /categories/

> > I already have a patch that does this. I don't have unit tests or
> > documentation yet. But if this looks like a patch that would be
> > accepted, I can definitely work on the tests and documentation.

> > --
> > Thanks,
> > Medhat