[Framework-Team] Re: Some preliminary Plone 3.0 profiling results

[Philipp von Weitershausen]

Martin Aspeli wrote:
>> I wish we could come up with a way to to get rid of the globalize stuff
>> sanely. It's an instane overkill to compute this magnitude of values for
>> each template, just because a few templates simply "expect" stuff to be
>> available. Not to mention that it encourages bad coding practices for
>> template authors.
> 
> Well, there are three issues here:
> 
> - for BBB, we need to keep a lot of this around. Breaking every third
> party product that used "portal_url" etc in a template is not an
> option

Right.

> As we move more things to views (and thanks to you and Alec and
> five.customerize that's now a more viable option) the new stuff tends
> not to rely on globals, though, or at least rely on it less.

Good. Still, I had to add the 'globalize' junk to my viewlet-based skin 
just because every second template in Plone still wants this or that 
variable. That's a burden on the macro that it shouldn't have to bare.

> - some things make sense to have globally available - portal_url
> possibly being one of them. Having to re-compute it each time
> (getToolByName(self, 'portal_url').getPortalPath()) is annoying

Right. I never said you should have to do that. However, this doesn't 
mean they have to be global ZPT variables. Global variables that just 
fall from the sky turn the magic up a few notches...

> - some things will never change for a request, and may be expensive
> to re-compute. Tool lookups are just acquisition,

...or getUtility calls in the future...

> so they're not too bad, but since moving portlets and the content
> menu to view(let)s, I've had to call things like
> listFilteredActionsFor() multiple times, even though I know it's been
> computed in other places, since I'm in a different namespace
> entirely.
> 
> I think we need a general solution to this problem - perhaps some view
> that can cache its results in a threadlocal or the request (mmm) or
> something like that.

Please NOT the request. The request is a read-only thing. The fact that 
it's writable in Zope 2 (or that even REQUEST.set exists) is a HUGE wart.

Some form of caching is indeed what we need. We may even want to make 
the actual implementation (thread local, perhaps memcache, ...) 
pluggable... It is also clear that this should be a general Zope (3) 
component as I'm sure others have this use case as well.

>> How do we stop making templates expect global variables? This isn't so
>> much a problem in Plone itself as it is for add-on products...
> 
> By making it easier to do without them. Things like portal_url, the
> 'member' implicit variable (current user) etc are incredibly useful to
> have readily available, and having to remember the IURLTool and
> IMembershipTool APIs all over the place is a pain in the ass.

Right, so get them from the @@plone view.

> I don't think we can get rid of globals for several versions, though,
> too much stuff depends on it. We have said "no new globals", however.

That's good. In my opinion, the use of the globals should also be 
discouraged in favour of the explicit access through the @@plone view, 
perhaps even deprecated... but that's up to you guys :)


-- 
http://worldcookery.com -- Professional Zope documentation and training