Adding request path to the stdvars

[Christoph Zwerschke]

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?

-- Chris

[Alberto Valverde]

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

[Christoph Zwerschke]

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/turbo...@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.

-- Chris

[Jorge Godoy]

Christoph Zwerschke <ci...@online.de> writes:

+1 from me.

--
Jorge Godoy <jgo...@gmail.com>

[Jorge Godoy]

Alberto Valverde <alb...@toscat.net> writes:

Yes, but having it there by default is a big win... ;-)

--
Jorge Godoy <jgo...@gmail.com>

[Alberto Valverde]

Sounds reasonable, mind anyone opening a "patched" ticket at the
Trac? :)

Thanks,
Alberto

[Jorge Godoy]

Alberto Valverde <alb...@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?

--
Jorge Godoy <jgo...@gmail.com>

[Alberto]

On 17 abr, 00:31, Jorge Godoy <jgo...@gmail.com> wrote:

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.

Alberto

[Christoph Zwerschke]

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.

-- Chris

[Jorge Vargas]

+1 just like plain old CP
> -- Chris
>
> >
>