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

Philipp von Weitershausen philipp at weitershausen.de
Wed Nov 15 14:31:54 UTC 2006


Martin Aspeli wrote:
>> > - 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...
> 
> Then where should they go, and how does a template author get hold of it?

Short answer: the @@plone view.
Long answer: a qualified component (whether that's @@plone or not 
doesn't matter much to me, it's mostly aesthetics, really).

>> > 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.
> 
> Heh, sure. But where?

You mentioned the thread local idea. That might work. I think we should 
also investigate memcached. See Tres's mcdutils package, for example: 
http://agendaless.com/Members/tseaver/software/mcdutils. It's important 
to note that this cache is absolutely request-specific. It must be 
invalidated after every request.

>> 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.
> 
> I was thinking about some kind of threadlocal or otherwise globalish
> dict that had lazy initialisation of all its keys. We could then make
> the BBB globalize() things defer to this dict, to keep everything in
> one place.
> 
>> >> 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.
> 
> There are still things in globals that don't have direct functions in
> @@plone, for better or for worse.

Seems like a job for... Bicycle Repair Man!

>> > 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 :)
> 
> +0.5 - I think we need to discuss the cache options a bit first.

Yeah...


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





More information about the Framework-Team mailing list