On Wed, Nov 10, 2010 at 9:08 PM, Chris McDonough <chr...@plope.com> wrote:
> 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 <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.
