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

Martin Aspeli optilude at gmx.net
Sun Dec 3 19:50:42 UTC 2006

Rocky Burt wrote:
> 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.

The latter. So, if three different things look up @@plone_tools, and 
they all do @@plone_tools/portal_membership, getToolByName(self.context, 
'portal_membership') will be called only once.

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

I thought you may not mind :)

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

Not entirely sure I follow...

> ps. +1 on everything

Heh, cool.

More information about the Framework-Team mailing list