[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.
http://worldcookery.com -- Professional Zope documentation and training
More information about the Framework-Team