I would like to add that "one letter" variables in templates made some
complications using 'pdb' where 'h' or 'u' have a special meaning.
Frind of mine told me about this few weeks ago regard to Pylons 9.7.
>From this point of view avoiding short, one character values in
namespace is a good idea.
There is another option to create some other namespaces and each of
them give "url" function. But this is only suggestion.
Greetings from Poland!
On Thu, Nov 11, 2010 at 5:36 PM, Chris McDonough <chr...@plope.com> wrote:
> On Thu, 2010-11-11 at 00:30 -0800, Mike Orr wrote:
>> 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``.
>
> It's actually a BFG thing. I chose it to disambiguate generating a URL
> for a model from generating a url for a route about 2 years ago.
>
>> 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'.
>
> I'd like to provide a set of common renderer globals that make sense
> across all paster templates, so the issue is disambiguating it from the
> other mechanism to create urls named "model_url". If one is available
> as a top-level name, it's likely that the other should be too.
>
>> >> 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.
>
> That'd work, but it would defeat my goal of having a common baseline set
> of names for all templates. It seems like a bigger win to compromise
> somehow, because URL dispatch and traversal can be combined, and people
> will need to use both model_url and route_url to generate URLs in that
> circumstance: http://docs.pylonshq.com/pyramid/dev/narr/hybrid.html .
>
>>
>> >> > 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.
>
> OK, good.
>
> - 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.
>
>
--
><> Jan Koprowski
--
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.
