On Sun, 2006-03-12 at 13:01 +0000, Martin Aspeli wrote: > 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).
Wait, is it the @@plone_tools view lookup that's being cached on the request or is it the portal_membership tool lookup that the view is doing that is being cached on the request. It's not clear to me. > 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. These sound pretty good to me. > 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). Right, this looks like a healthy compromise. > 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. Sounds good. > - Add the viewlet managers to main_template Sounds good. > - 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. Hmm... now this really sounds good. > - 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. Sure, makes sense. The funny thing is that if we start using @@plone_tools for all tool lookups and with CMF2.1's changes of the tools to be standard utilities so we start using getUtility in non-zpt code the subplone-style functionality becomes sooooo much easier. Dare I say that if subplone-style functionality is then given to us for free (essentially) we should expose this functionality directly as a standard core plone feature? Whoops, maybe I'm getting ahead of myself... :) - Rocky ps. +1 on everything -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team