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

[Martin Aspeli]

Hi Philipp,

> 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

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.

 - 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

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

> The implementation of globalize is also insane, as it monkeys variables
> into Python stack frames, an approach that depends on the actual
> variable names of code in Zope.

True, but it was faster than having it all in template. :)

> To be honest, I'm not too content with the @@plone view either, but at
> least it provides a saner approach: a definite Python API that can be
> used from ZPT, explicitly (instead of implicitly expecting global stuff).

Yes.

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

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.

Martin