I wonder why the current request path is not available as a global template variable (e.g. as tg.path = cherrypy.request.path). I think that would be very handy for displaying navigation, breadcrumbs, menus etc. in the template. And instead setting a flag in the controller it is often easier to check the path directly.
Shall I submit this as a patch or am I missing something?
On Apr 16, 2007, at 10:23 PM, Christoph Zwerschke wrote:
> I wonder why the current request path is not available as a global > template variable (e.g. as tg.path = cherrypy.request.path). I think > that would be very handy for displaying navigation, breadcrumbs, menus > etc. in the template. And instead setting a flag in the controller > it is > often easier to check the path directly.
> Shall I submit this as a patch or am I missing something?
You can add whatever variables your app needs to the template namespae by appending a function to view.variable_providers
def my_vars(d): d['path'] = cherrypy.request.path
from turbogears import view view.varibale_providers.append(my_vars)
Alberto Valverde wrote: > You can add whatever variables your app needs to the template > namespae by appending a function to view.variable_providers
I know, but my thought was that the path is so universally important that it should be really among the "standard" vars.
I don't think all users are aware that 1) the path is available via charrypy.request.path and 2) you can supplement the standard vars. They may think they have to pass the page manually or add special decorators: http://www.mail-archive.com/turbogears@googlegroups.com/msg25527.html
So I think it makes sense to have the request path (and the template path) available in the template by default already.
Christoph Zwerschke <c...@online.de> writes: > I wonder why the current request path is not available as a global > template variable (e.g. as tg.path = cherrypy.request.path). I think > that would be very handy for displaying navigation, breadcrumbs, menus > etc. in the template. And instead setting a flag in the controller it is > often easier to check the path directly.
> Shall I submit this as a patch or am I missing something?
Alberto Valverde <albe...@toscat.net> writes: > On Apr 16, 2007, at 10:23 PM, Christoph Zwerschke wrote:
>> I wonder why the current request path is not available as a global >> template variable (e.g. as tg.path = cherrypy.request.path). I think >> that would be very handy for displaying navigation, breadcrumbs, menus >> etc. in the template. And instead setting a flag in the controller >> it is >> often easier to check the path directly.
>> Shall I submit this as a patch or am I missing something?
> You can add whatever variables your app needs to the template > namespae by appending a function to view.variable_providers
>> On Apr 16, 2007, at 10:23 PM, Christoph Zwerschke wrote:
>>> I wonder why the current request path is not available as a global >>> template variable (e.g. as tg.path = cherrypy.request.path). I think >>> that would be very handy for displaying navigation, breadcrumbs, >>> menus >>> etc. in the template. And instead setting a flag in the controller >>> it is >>> often easier to check the path directly.
>>> Shall I submit this as a patch or am I missing something?
>> You can add whatever variables your app needs to the template >> namespae by appending a function to view.variable_providers
Alberto Valverde <albe...@toscat.net> writes: > Sounds reasonable, mind anyone opening a "patched" ticket at the > Trac? :)
I've been thinking... What about making tg.request (cherrypy.request) available? There we'd have all information from the request and we could modify it there... Of course, a complement of turbogears.request would also be nice.
AND, since we're going towards WSGI, we can make that an entry_point or a configuration parameter... By default this would be cherrypy.request, but it could be any request object.
On 17 abr, 00:31, Jorge Godoy <jgo...@gmail.com> wrote:
> Alberto Valverde <albe...@toscat.net> writes: > > Sounds reasonable, mind anyone opening a "patched" ticket at the > > Trac? :)
> I've been thinking... What about making tg.request (cherrypy.request) > available? There we'd have all information from the request and we > could modify it there... Of course, a complement of turbogears.request > would also be nice.
> AND, since we're going towards WSGI, we can make that an entry_point or > a configuration parameter... By default this would be cherrypy.request, > but it could be any request object.
> What do you think?
Fine with me too, however, making it configurable via an entry point seems an overkill to me and overlaps with what extensions provide.
Keep in mind extensions are also loaded via entrypoints and these have the ability of adding new variables to the template namesace.
So, to sum up, I'm +1 on putting request on tg.request but -1 on creating a new entry-point to configure which object is bound here.
I also thought about adding cherrypy.request to the standard vars instead of request.path only, since it bundles a lot of stuff that may be useful in the template. Maybe that's even a better alternative.
On 4/17/07, Christoph Zwerschke <c...@online.de> wrote:
> I also thought about adding cherrypy.request to the standard vars > instead of request.path only, since it bundles a lot of stuff that may > be useful in the template. Maybe that's even a better alternative.
