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.
Cool.
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.
Good.
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.
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
