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


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

Reply via email to