On Wed, Nov 10, 2010 at 5:00 PM, Chris McDonough <chr...@plope.com> wrote:
> I'm trying to normalize all of the paster templates in Pyramid, so they
> 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', '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 <sluggos...@gmail.com>
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-de...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
