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

[Rocky Burt]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20061203/f1bebe65/attachment.asc>