[Framework-Team] Can I merge plone.memoize and plone.app.layout?

[Martin Aspeli]

Hi guys,

Following discussions with Whit, Alec and Rocky on the channel last 
night, and from the lists before, I've created and checked in two packages:

  - plone.memoize: contains Whit's memojito memoization decorators (in 
plone.memoize.instance), and a variant of it that memoizes values in the 
request for views (plone.memoize.view).

  - plone.app.layout: contains a view viewlet manager definitions 
(plone.app.layout.viewlets) and a set of views that contain several of 
the values from global_defines, but cleaned up 
(plone.app.layout.globals). These are memoized using the view 
memoization in plone.memoize.

That means, that to get hold of the portal_membership tool in a 
template, say, I could write context/@@plone_tools/portal_membership. 
The first time any template or code (say, in a view class) did that, it 
would do getToolByName to find portal_membership, and on subsequent 
times, it would be memoized tied to the request (so even if you looked 
up @@plone_tools again, you'd get the same memo, so long as it was in 
the same request).

There are three views: @@plone_tools (contains various tools); 
@@portal_state (contains information about the portal as a whole, 
including the current authenticated member, the is_anonymous flag, the 
portal_url etc); and @@context_state (contains information about the 
context, e.g. pretty title, workflow state, actions dict etc.

Obviously that granularity could change, but I found that it made sense 
to have more than one (to avoid the "dumping ground" problem) but not 
too many (to avoid having to remember lots of them).

Now, what I'd like to do tonight (Wiggy?) is:

  - Add these to the bundles
  - Make Products.CMFPlone.browser.plone.cache_decorator an alias for 
plone.memoize.instance.memoize, and derecate
  - Make various things that use @cache_decorator use @memoize directly.


  - Add the viewlet managers to main_template

  - Change @@plone's globalize() to use the new memoized views where 
appropriate; at this point we can start formally deprecating 
global_defines if we wish.

  - Change various places I can think of to use the @@plone_tools, 
@@context_state and @@portal_state views; obviously this would be an 
evolutionary thing, but I'd really rather get it in ASAP so people can 
start using it.

Is this OK?

Martin