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