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

[Martin Aspeli]

Hi Philipp,

> > - 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?

> > 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?

> 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.

> > 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.

Martin