Previously Martin Aspeli wrote: > 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?
a definite +1 Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team