[Framework-Team] Re: Can I merge plone.memoize and plone.app.layout?
rocky at serverzen.com
Sun Dec 3 13:25:00 UTC 2006
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.
> - 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.
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... :)
ps. +1 on everything
ServerZen Software -- http://www.serverzen.com
News About The Server (blog) -- http://www.serverzen.net
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Framework-Team