On Dec 19, 2007 10:53 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> On Dec 19, 2007, at 8:37 AM, Ian Bicking wrote:
> > pylons.c is just a little odd -- if we could change the render
> > function
> > to just take substitution variables as keyword arguments then I
> > personally would just stop using pylons.c, and probably be happier for
> > it. Right now I guess I have to do variables=dict(...), which isn't
> > horrible but doesn't look pretty for such a common construct.
>
> Quite a few people actually want this, also because it forces their
> templates to fail. Of course, many people absolutely require the
> current methodology since they setup 'c' options in the BaseController
> for use in all templates, which is a great and intended use of the
> global ability to set 'c' options.
Oh, I actually do use this to set default values. Setting the page
title and breadcrumbs from the controller seems like the only feasable
way, since you can't set page attributes in Mako that the site
template can see, and doing it with <%def> and ${self.title()} is both
a kludge and doesn't always work. So I set default values in the base
controller to avoid errors if the action doesn't need a special value.
> Whether thats a 'good' usage or not
> is somewhat more debateable, since in systems where you can't do this,
> its hardly too crippling to have a function you call that sets up some
> basic options, which also makes it clearer how those extra options
> land in the template....
It's one more line in *every* action.
I will prob'ly just start passing explicit variables to render() though.
> > Besides being hard to understand, they are a pain to debug. That's
> > actually my concern with them. Oh, and they have weird performance
> > characteristics that have frequently caught people.
>
> I don't see any way to remove them.... but we could go back to just
> thread-locals, and tell people not to use Pylons apps in front of
> Pylons apps (does anyone actually do this???). We are incurring a lot
> of complexity with SOP's for a 0.01% use-case here...
We should somehow support a Pylons app as a "bundle" that can be used
inside another app.
It's not done yet because there are also routing and session scenarios
that still need to be tested.
But if that's is the only reason for SOPs, I wouldn't mind making
bundled apps get that info another way.
Perhaps *they* can call a special function to get request-local info,
while top-level apps can continue using pylons.*.
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
