Pyramid paster template renderer globals?
Chris McDonough
share a single "BeforeRender" subscriber. The BeforeRender subscriber
in each paster template will add keys to the top-level set of names that
can be used within every renderer (for example, within a Mako or
Chameleon template). For example:
from pyramid.threadlocal import get_current_request
from {{package}} import helpers
def add_renderer_globals(event):
request = event.get('request')
if request is None:
request = get_current_request()
globs = {
'h':helpers,
}
if request is not None:
tmpl_context = request.tmpl_context
globs['c'] = tmpl_context
event.update(globs)
This adds "c" and "h" to the names available to templates at a top level
(these names are familiar to Pylons users).
This subscriber function lives in the paster template itself, and is
eventually wired in via something like:
config.add_subscriber('{{package}}.subscribers.add_renderer_globals',
'pyramid.events.BeforeRender')
I don't actually want the templates to import this subscriber function
from some common location within Pyramid itself, because people will
want/need to add/remove values to those top-level names. However, I
would like *all* paster templates (including those named pyramid_*) to
have such a subscriber, and, if at all possible, to introduce the *same*
globals.
BFG users have no expectation of any particular set of renderer globals
being available. They have historically been "on their own" to provide
renderer globals. Pylons 1 users, on the other hand, have a clear
expectation of a set of globals.
Some of historical Pylons 1 globals don't make sense in the context of
Pyramid, however (such as 'url', because there's no function that
currently behaves exactly like it does). Some historical Pylons globals
are only for backwards compatibility (e.g. "tmpl_context" vs. "c").
Also, some functionality that previously was exposed as a top-level name
now exists as methods/attributes of the request (request.session,
request.route_url, request.registry {registry is a pro-tem substitute
for "g"}).
In the meantime, computational expense is incurred by doing lots of
stuff in the subscriber. The things that are done by the subscriber
should have benefit.
What is the smallest collection of renderer globals that we can add for
all paster templates which would service the expectations of existing
Pylons 1 users?
- C
Mike Orr
'c', 'h', and 'url' are most important. 'url' is very heavily used; e.g.,
${h.link_to("Link title", url("routename", var1="val1")}
expanding that to
${h.link_to("Link title", request.route_url("routename", var1="val1")}
would make templates significantly less readable, especially if the template
has many URLs. And forcing every template to have:
<% url = request.route_url %>
is also excess boilerplate.
(Or does request.route_url require the request as the first argument?
That would be even more verbose as well as silly, because the arg can
be implied via a partial or class.)
How do BFG users handle URL generation?
The other variables are used much less often. 'app_globals'/'g' is
probably first, then 'session', and lastly 'request', 'response', and
'cache'. It's fine with me if these are all attributes under the
request. Most apps don't use 'app_globals' at all, and those that use
it extensively can figure out their own way to access the data, such
as setting 'c' variables. 'session' I have only used with flash in the
site template, although others may use it slightly more often. I have
never found a reason to use 'request' or 'response' in a template. '
cache' I never use, but Pylons 1 has put it under 'app_globals' and I
don't know if Pyramid even has a (Beaker) cache. I wouldn't mind
putting all these under 'request', or telling people to set 'c'
variables in the view handler .__init__ or view method.
As for 'tmpl_context', I can't believe anybody actually the long form.
But does it really cause more overhead to set four top-level variables
rather than one or two?
If the subscriber can be disabled and customized, that would be the
best scenario. Then the Pylons templates can enable it by default, but
people can disable it or exclude variables they're not using.
But the decision on template names need to be made in conjunction with
their names in views. They don't have to be the same but they should
be similar enough that people can remember them. Pylons 1 uses the
same name as outside templates, plus keeps the older one-letter forms.
'url' is the most common one that's used both inside and outside
templates. But 'request.route_url' is fine in views (though I wish it
were less verbose). As for 'h' in views, I've gone away from that and
import the helpers directly. But I suppose there's an argument for
making 'h' available in views under some attribute.
--
Mike Orr <slugg...@gmail.com>
Chris McDonough
> 'c', 'h', and 'url' are most important.
Thanks, that's what I figured. Most folks on IRC agree (at least they
said "c" and "h" are probably non-negotiable).
> 'url' is very heavily used; e.g.,
> ${h.link_to("Link title", url("routename", var1="val1")}
> expanding that to
> ${h.link_to("Link title", request.route_url("routename", var1="val1")}
> would make templates significantly less readable, especially if the template
> has many URLs. And forcing every template to have:
> <% url = request.route_url %>
> is also excess boilerplate.
We don't have "url" in there now. The equivalent of "url" (as of about
2 hours ago when I checked it in) would be:
${request.route_url('routename', var1='val1')}
I'm hoping this is sufficient to supplant "url".
> How do BFG users handle URL generation?
Same basic way as Pylons users, but the framework just doesn't make
"url" a top-level name by default (the framework doesn't make anything
except "request" and a couple of other non-API things top-level by
default, more or less). The user himself can make, say, route_url, a
top-level name if they like, though, by adding it as a renderer global.
> The other variables are used much less often. 'app_globals'/'g' is
> probably first, then 'session', and lastly 'request', 'response', and
> 'cache'. It's fine with me if these are all attributes under the
> request.
OK. The mapping I'd like to be able to make is this:
Pylons global name Pyramid name
----------------------------- --------------
request request
url request.route_url
c request.tmpl_context
(we could alias this as c too)
g request.registry (this may change)
h h
session request.session
cache N/A
response N/A
"h" will be a reference to a helpers.py module in the package itself.
"cache" we do not have. I haven't really had time to figure out if it's
worthwhile make some "cache factory" abstraction like the session
factory abstraction.
We don't have "response" either, because there is no global response in
BFG/Pyramid, but people can add attributes to the request to cause
response headers and so on to be returned.
> Most apps don't use 'app_globals' at all, and those that use
> it extensively can figure out their own way to access the data, such
> as setting 'c' variables. 'session' I have only used with flash in the
> site template, although others may use it slightly more often. I have
> never found a reason to use 'request' or 'response' in a template. '
> cache' I never use, but Pylons 1 has put it under 'app_globals' and I
> don't know if Pyramid even has a (Beaker) cache. I wouldn't mind
> putting all these under 'request', or telling people to set 'c'
> variables in the view handler .__init__ or view method.
>
> As for 'tmpl_context', I can't believe anybody actually the long form.
>
> But does it really cause more overhead to set four top-level variables
> rather than one or two?
Maybe. It depends what it is. Getting at request.session invokes a
decorator, which may need to run a session factory. So making it a
top-level name adds avoidable overhead if folks are just as happy to
access it as request.session and pay the price only when they do that.
Whatever top-level names we add to the thing need to be documented, so
the fewer the better as far as I'm concerned, within reason of meeting
Pylons 1 users' expectations.
> If the subscriber can be disabled and customized, that would be the
> best scenario. Then the Pylons templates can enable it by default, but
> people can disable it or exclude variables they're not using.
OK, it is.
> But the decision on template names need to be made in conjunction with
> their names in views. They don't have to be the same but they should
> be similar enough that people can remember them.
In the mapping I put above nothing except "helpers" will be imported
anyway.
> Pylons 1 uses the
> same name as outside templates, plus keeps the older one-letter forms.
> 'url' is the most common one that's used both inside and outside
> templates. But 'request.route_url' is fine in views (though I wish it
> were less verbose). As for 'h' in views, I've gone away from that and
> import the helpers directly. But I suppose there's an argument for
> making 'h' available in views under some attribute.
I think they'll just import the module.
- C
Mike Orr
> On Wed, 2010-11-10 at 19:26 -0800, Mike Orr wrote:
>> 'c', 'h', and 'url' are most important.
>
> Thanks, that's what I figured. Most folks on IRC agree (at least they
> said "c" and "h" are probably non-negotiable).
>
>> 'url' is very heavily used; e.g.,
>> ${h.link_to("Link title", url("routename", var1="val1")}
>> expanding that to
>> ${h.link_to("Link title", request.route_url("routename", var1="val1")}
>> would make templates significantly less readable, especially if the template
>> has many URLs. And forcing every template to have:
>> <% url = request.route_url %>
>> is also excess boilerplate.
>
> We don't have "url" in there now. The equivalent of "url" (as of about
> 2 hours ago when I checked it in) would be:
>
> ${request.route_url('routename', var1='val1')}
>
> I'm hoping this is sufficient to supplant "url".
I think 'url' is important. Otherwise it's a significant degredation
of readability compared to Pylons 1 templates.
So 'url' would be set in the application template rather than in
Pyramid internals? Then it should be the default, and users can
comment it out if they don't want it. It's easier for advanced users
to disable things than for newbies to add them, and templates should
be elegant (with 'url') out of the box. If you argue that 'url' is
unnecessary, by the same logic you can argue that 'c' is unnecessary
too.
> c request.tmpl_context
> (we could alias this as c too)
Only in templates. In views, people will want to do "c =
self.request.tmpl_context". Because "self.request.c.foo = 'Value'"
doesn't gain you much over "self.request.tmpl_context.foo = 'Value'".
> "cache" we do not have. I haven't really had time to figure out if it's
> worthwhile make some "cache factory" abstraction like the session
> factory abstraction.
I forgot to mention, this is Ben's job anyway. He can put the cache
under registry if that's where it belongs.
> We don't have "response" either, because there is no global response in
> BFG/Pyramid, but people can add attributes to the request to cause
> response headers and so on to be returned.
Have the four or five ``request.response_`` properties proven to be
sufficient for most people's needs?
> Maybe. It depends what it is. Getting at request.session invokes a
> decorator, which may need to run a session factory. So making it a
> top-level name adds avoidable overhead if folks are just as happy to
> access it as request.session and pay the price only when they do that.
> Whatever top-level names we add to the thing need to be documented, so
> the fewer the better as far as I'm concerned, within reason of meeting
> Pylons 1 users' expectations.
Well, 'url' can be a wrapper function or partial if it has to be. An
extra function call per $(url(...)} is worth it in medium-intensity
sites, and high-intensity sites can disable it if they don't want the
overhead.
>> As for 'h' in views, I've gone away from that and
>> import the helpers directly. But I suppose there's an argument for
>> making 'h' available in views under some attribute.
>
> I think they'll just import the module.
Oh yes of course, that's what they'd do. I forgot people do this as
"import myapp.lib.helpers as h".
--
Mike Orr <slugg...@gmail.com>
Mike Orr
> On Wed, 2010-11-10 at 19:26 -0800, Mike Orr wrote:
>> 'c', 'h', and 'url' are most important.
>
> Thanks, that's what I figured. Most folks on IRC agree (at least they
> said "c" and "h" are probably non-negotiable).
'c' is still useful even with the dict-return style, because you can
set things in .__init__ for the site template, or other things you
don't want to clutter every return value with. (Especially things that
are HTML-only, for views that do double-duty as both HTML output and
JSON output).
--
Mike Orr <slugg...@gmail.com>
Chris McDonough
> > We don't have "url" in there now. The equivalent of "url" (as of about
> > 2 hours ago when I checked it in) would be:
> >
> > ${request.route_url('routename', var1='val1')}
> >
> > I'm hoping this is sufficient to supplant "url".
>
> I think 'url' is important. Otherwise it's a significant degredation
> of readability compared to Pylons 1 templates.
I don't mind having a top-level name for a route url creation function,
but naming it just "url" will be confusing for people who use traversal.
There are two separate URL-generation functions: pyramid.url.model_url
(for traversal based apps) and pyramid.url.route_url. Could we put it
in the renderer globals dict as "route_url"?
> So 'url' would be set in the application template rather than in
> Pyramid internals? Then it should be the default, and users can
> comment it out if they don't want it. It's easier for advanced users
> to disable things than for newbies to add them, and templates should
> be elegant (with 'url') out of the box. If you argue that 'url' is
> unnecessary, by the same logic you can argue that 'c' is unnecessary
> too.
Each template will have its own function to generate renderer globals.
I don't mind having a url generation function (or two) as top-level
names in the renderer globals by default.
>
> > c request.tmpl_context
> > (we could alias this as c too)
>
> Only in templates. In views, people will want to do "c =
> self.request.tmpl_context". Because "self.request.c.foo = 'Value'"
> doesn't gain you much over "self.request.tmpl_context.foo = 'Value'".
Yes, this is all about names in template globals. So "c"? Or
"tmpl_context"? Or neither?
> > "cache" we do not have. I haven't really had time to figure out if it's
> > worthwhile make some "cache factory" abstraction like the session
> > factory abstraction.
>
> I forgot to mention, this is Ben's job anyway. He can put the cache
> under registry if that's where it belongs.
>
> > We don't have "response" either, because there is no global response in
> > BFG/Pyramid, but people can add attributes to the request to cause
> > response headers and so on to be returned.
>
> Have the four or five ``request.response_`` properties proven to be
> sufficient for most people's needs?
No one has complained yet.
> > Maybe. It depends what it is. Getting at request.session invokes a
> > decorator, which may need to run a session factory. So making it a
> > top-level name adds avoidable overhead if folks are just as happy to
> > access it as request.session and pay the price only when they do that.
> > Whatever top-level names we add to the thing need to be documented, so
> > the fewer the better as far as I'm concerned, within reason of meeting
> > Pylons 1 users' expectations.
>
> Well, 'url' can be a wrapper function or partial if it has to be. An
> extra function call per $(url(...)} is worth it in medium-intensity
> sites, and high-intensity sites can disable it if they don't want the
> overhead.
It'd just be in the renderer globals dict as:
{'route_url':request.route_url}
- C
Mike Orr
> On Wed, 2010-11-10 at 21:53 -0800, Mike Orr wrote:
>> > We don't have "url" in there now. The equivalent of "url" (as of about
>> > 2 hours ago when I checked it in) would be:
>> >
>> > ${request.route_url('routename', var1='val1')}
>> >
>> > I'm hoping this is sufficient to supplant "url".
>>
>> I think 'url' is important. Otherwise it's a significant degredation
>> of readability compared to Pylons 1 templates.
>
> I don't mind having a top-level name for a route url creation function,
> but naming it just "url" will be confusing for people who use traversal.
> There are two separate URL-generation functions: pyramid.url.model_url
> (for traversal based apps) and pyramid.url.route_url. Could we put it
> in the renderer globals dict as "route_url"?
That's still kind of long, especially when it's inside a h.link_to and
you're trying to keep the entire expression on one line. I never have
liked 'route_url'; Ben chose it because we couldn't think of anything
better that didn't conflict with ``request.url``. I'm not sure if
'route_url' is necessarily better than not having it at all.
Could we name it 'u' and pretend that Pylons always had it? 'url' does
tend to conflict with local variables and I usually use 'u' for the
local variable in that case, so this would just reverse the practice.
And it would look OK next to 'c' and 'h'.
>> So 'url' would be set in the application template rather than in
>> Pyramid internals? Then it should be the default, and users can
>> comment it out if they don't want it. It's easier for advanced users
>> to disable things than for newbies to add them, and templates should
>> be elegant (with 'url') out of the box. If you argue that 'url' is
>> unnecessary, by the same logic you can argue that 'c' is unnecessary
>> too.
>
> Each template will have its own function to generate renderer globals.
> I don't mind having a url generation function (or two) as top-level
> names in the renderer globals by default.
So we can put these in the Pylons (URL dispatch) templates and leave
them out of the BFG (traversal) templates.
>> > c request.tmpl_context
>> > (we could alias this as c too)
>>
>> Only in templates. In views, people will want to do "c =
>> self.request.tmpl_context". Because "self.request.c.foo = 'Value'"
>> doesn't gain you much over "self.request.tmpl_context.foo = 'Value'".
>
> Yes, this is all about names in template globals. So "c"? Or
> "tmpl_context"? Or neither?
'c' in templates. I can't believe anyone would use the longer form in
a template, but if so they can speak up now.
--
Mike Orr <slugg...@gmail.com>
Wichert Akkerman
> Some of historical Pylons 1 globals don't make sense in the context of
> Pyramid, however (such as 'url', because there's no function that
> currently behaves exactly like it does). Some historical Pylons globals
> are only for backwards compatibility (e.g. "tmpl_context" vs. "c").
> Also, some functionality that previously was exposed as a top-level name
> now exists as methods/attributes of the request (request.session,
> request.route_url, request.registry {registry is a pro-tem substitute
> for "g"}).
I feel that g is more similar to BFG's ISettings utility than the
registry. Most of my BFG apps put that utility in the global namespace.
Wichert.
Wichert Akkerman
> Could we name it 'u' and pretend that Pylons always had it? 'url' does
> tend to conflict with local variables and I usually use 'u' for the
> local variable in that case, so this would just reverse the practice.
> And it would look OK next to 'c' and 'h'.
For readability sake I would object to that. One-letter names are
confusing to new people, and very likely to conflict with temporary
variables.
Wichert.
Fernando Correa Neto
I believe once you get used to them it's not big of a deal.
But I agree. If there's more variables like that around, it makes very
difficult not to say impossible to understand what's going on.
-Fernando
Mike Orr
This is one of those cases where purity interferes with practicality.
It's only three one-letter variables to learn, and they're widely used
all over templates so they'll seem like just part of the syntax. And
if you only have a 79-character line and you want to put the entire
expression or tag on one line, it gets difficult when the boilerplate
code extends to nine characters; that's over a tenth of the space just
for one of them.
1 2 3
4 5 6 7
1234567890123456789012345678901234567890123456789012345678901234567890123456789
More details <a href="${u('record',
id=c.incident_id)}"><strong>here</strong></a>.
More details <a href="${route_url('record',
id=c.incident_id)}"><strong>here</strong></a>.
More details ${h.link_to("here", u("record", id=c.incident_id))}.
More details ${h.link_to("here", route_url("record", id=c.incident_id))}.
Click <a href="${u('record', id=c.incident_id)}">yes</a> or <a
href="${u('record', id=c.incident_id)">
no</a> to cast your vote.
Click <a href="${rouute_url('record', id=c.incident_id)}">yes</a> or
<a href="${route_url('record', id=c.other_id)">no</a> to cast your vote.
Click ${h.link_to("yes", u("record", id=c.incident_id))} or
${h.link_to("no", u("record", id=c.incident_id)}
to cast your vote.
Click ${h.link_to("yes", route_url("record", id=c.incident_id))} or
${h.link_to("no", route_url("record", id=c.incident_id)} to cast your vote.
Since HTML is all about hyperlinks, it makes sense to give them
special treatment, especially if you're trying to encourage people to
always use URL generation rather than literal URLs for internal links,
as Pylons does.
--
Mike Orr <slugg...@gmail.com>
Wichert Akkerman
> Since HTML is all about hyperlinks, it makes sense to give them
> special treatment, especially if you're trying to encourage people to
> always use URL generation rather than literal URLs for internal links,
> as Pylons does.
Stick a py:with="u=request.route_url" at the top of you template if you
want brevity?
My standard pattern is to expose a 'tools' object to templates which has
a number of functions such as route_url, model_url, etc. for use in
templates. I've never felt that having to spell <a
href="${tools.route_url('personal+settings')}">..</a> is too long or
awkward.
Wichert.
Wichert Akkerman
Relatedly: there are two completely different ways to generate a URL:
model based and route based. Your suggestion to use 'url' or 'u' would
imply a document preference for one of the two, which I do not feel is
warranted. As Chris said earlier in this thread both are just as useful
and important.
Wichert.
Chris Rossi
Wichert Akkerman
I'm afraid that will cause confusion: people will have certain
expectations when they encounter a Pylons 2 app, and it will be odd if
'url' behaves differently than they expect in 50% of the applications. A
related worry is add-ons that may expect 'url' to behave in a certain
way and as a result only work in 50% of the Pylons 2 projects.
Wichert.
Chris Rossi
Mike Orr
which is what Pylons had before url(). And url() has always had a
problem in being the same as a previously-popular local variable.
It would still be nice to put 'u' as a commented default, so that
users can just uncomment it if they want it.
--
Mike Orr <slugg...@gmail.com>
Mike Orr
So in the morning light (Pacific time zone), I reverse my position.
route_url() is fine.
And if we put the subscriber in the application template, we can draw
attention to it in the docs and give some examples of how to modify
it. In Pylons the corresponding function is in pylons.templating
itself, and overrriding it requires reimplementing the render_mako()
function, which is significantly more obscure/advanced than just
overriding the variable-injection function. So it would be an
improvement over Pylons.
--
Mike Orr <slugg...@gmail.com>
Chris McDonough
> On Wed, Nov 10, 2010 at 11:16 PM, Chris McDonough <chr...@plope.com> wrote:
> > On Wed, 2010-11-10 at 21:53 -0800, Mike Orr wrote:
> >> > We don't have "url" in there now. The equivalent of "url" (as of about
> >> > 2 hours ago when I checked it in) would be:
> >> >
> >> > ${request.route_url('routename', var1='val1')}
> >> >
> >> > I'm hoping this is sufficient to supplant "url".
> >>
> >> I think 'url' is important. Otherwise it's a significant degredation
> >> of readability compared to Pylons 1 templates.
> >
> > I don't mind having a top-level name for a route url creation function,
> > but naming it just "url" will be confusing for people who use traversal.
> > There are two separate URL-generation functions: pyramid.url.model_url
> > (for traversal based apps) and pyramid.url.route_url. Could we put it
> > in the renderer globals dict as "route_url"?
>
> That's still kind of long, especially when it's inside a h.link_to and
> you're trying to keep the entire expression on one line. I never have
> liked 'route_url'; Ben chose it because we couldn't think of anything
> better that didn't conflict with ``request.url``.
It's actually a BFG thing. I chose it to disambiguate generating a URL
for a model from generating a url for a route about 2 years ago.
> I'm not sure if
> 'route_url' is necessarily better than not having it at all.
> Could we name it 'u' and pretend that Pylons always had it? 'url' does
> tend to conflict with local variables and I usually use 'u' for the
> local variable in that case, so this would just reverse the practice.
> And it would look OK next to 'c' and 'h'.
I'd like to provide a set of common renderer globals that make sense
across all paster templates, so the issue is disambiguating it from the
other mechanism to create urls named "model_url". If one is available
as a top-level name, it's likely that the other should be too.
> >> So 'url' would be set in the application template rather than in
> >> Pyramid internals? Then it should be the default, and users can
> >> comment it out if they don't want it. It's easier for advanced users
> >> to disable things than for newbies to add them, and templates should
> >> be elegant (with 'url') out of the box. If you argue that 'url' is
> >> unnecessary, by the same logic you can argue that 'c' is unnecessary
> >> too.
> >
> > Each template will have its own function to generate renderer globals.
> > I don't mind having a url generation function (or two) as top-level
> > names in the renderer globals by default.
>
> So we can put these in the Pylons (URL dispatch) templates and leave
> them out of the BFG (traversal) templates.
That'd work, but it would defeat my goal of having a common baseline set
of names for all templates. It seems like a bigger win to compromise
somehow, because URL dispatch and traversal can be combined, and people
will need to use both model_url and route_url to generate URLs in that
circumstance: http://docs.pylonshq.com/pyramid/dev/narr/hybrid.html .
>
> >> > c request.tmpl_context
> >> > (we could alias this as c too)
> >>
> >> Only in templates. In views, people will want to do "c =
> >> self.request.tmpl_context". Because "self.request.c.foo = 'Value'"
> >> doesn't gain you much over "self.request.tmpl_context.foo = 'Value'".
> >
> > Yes, this is all about names in template globals. So "c"? Or
> > "tmpl_context"? Or neither?
>
> 'c' in templates. I can't believe anyone would use the longer form in
> a template, but if so they can speak up now.
OK, good.
- C
Jan Koprowski
complications using 'pdb' where 'h' or 'u' have a special meaning.
Frind of mine told me about this few weeks ago regard to Pylons 9.7.
From this point of view avoiding short, one character values in
namespace is a good idea.
There is another option to create some other namespaces and each of
them give "url" function. But this is only suggestion.
Greetings from Poland!
> --
> You received this message because you are subscribed to the Google Groups "pylons-devel" group.
> To post to this group, send email to pylons...@googlegroups.com.
> To unsubscribe from this group, send email to pylons-devel...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
>
>
--
><> Jan Koprowski