On Wed, Nov 10, 2010 at 11:16 PM, Chris McDonough <chr...@plope.com> wrote:
> 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"?
That's still kind of long, especially when it's inside a h.link_to and
you're trying to keep the entire expression on one line. I never have
liked 'route_url'; Ben chose it because we couldn't think of anything
better that didn't conflict with ``request.url``. I'm not sure if
'route_url' is necessarily better than not having it at all.
Could we name it 'u' and pretend that Pylons always had it? 'url' does
tend to conflict with local variables and I usually use 'u' for the
local variable in that case, so this would just reverse the practice.
And it would look OK next to 'c' and 'h'.
>> 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.
So we can put these in the Pylons (URL dispatch) templates and leave
them out of the BFG (traversal) templates.
>> > 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?
'c' in templates. I can't believe anyone would use the longer form in
a template, but if so they can speak up now.
--
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.
