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