On 26 Feb 2007, at 23:48 , Tres Seaver wrote:
I nowhere said anything about deprecation. All meant was to
relying on acquisition when developing new tools. I think that
a comment (I suggested nothing more). No deprecation warning or
OK. I do think we need to have some resistance to the "Zope2 is evil,
Zope3 is wonderful" fundamentalism which sometimes shows up around
Frankly, Zope3 *is* a cool library, but it does not address a
the scenarios Zope2 does, and maybe never will.
Yes. Zope 3 is can be seen as a set of libraries -- and a number of
As far as acquisition (the concept) is concerned, I think the common
perception is that Acquisition (the Zope 2 package) introduces pains,
magic and unpredictability, whereas the way acquisition is
implemented in Zope 3 (discrete places called sites from which you
can acquire things after registering things explicitly) is a cleaner
and more predictable concept.
I see this whole effort (making CMF tools available as utilities,
etc.) a way to move from Acquisition (the Zope 2 package) to a better
form of acquisition (using the Zope 3 Component Architecture). Such a
process needs to be accompanied by clear statements what's encouraged
and what's discouraged. That doesn't mean that the old way is "evil",
but we can certainly give a clear recommandation as to what's better
(not necessarily "wonderful" but better).
They darn well better be able to get a wrapped context (which
To get to the portal root / CMF site, I suggest a pattern that is
sometimes used in Zope3: We register the CMF site object as a
providing ICMFSite (or whatever). Then whichever code that's
below the portal (and that includes CMF tools) can do
getUtility(ICMFSite) to get to the site.
Adapters and subscription adapters should not be acquisition
the event *must* have a wrapped attribute) or they will be less than
That's something else. Adapters and subscription adapters will get
whatever they are looked up with. If that's wrapped, fine. E.g. if
do IWhatever(obj) and you got obj thru acquisition, then the
adapter will see obj with all its acquisition glory. But The adapter
objects themselves shouldn't be wrapped. It would break, say, views
which happen to be adapters.
I'll note that five views are already required to be acquisition
if they use any objects protected by Zope2 security machinery.
Yes, but their wrapping is a detail of the traversal and security
machinery. Hence it happens during traversal, not during component
Note that subscription adapters != subscribers. Subscribers don't
objects upon lookup, they're just executed. Subscription adapters are
more like adapters.
I don't know of such a distinction. Please explain how one
More on subscribers vs. subscription adapters:
* "Subscribers" are the event subscribers we know: simple callables.
They don't return anything (well, they return None :)), hence there's
nothing to wrap or anything.
* "Subscription adapters" are like regular adapters (and they are
implemented exactly like a regular adapter). The difference is in the
lookup. Instead of getting exactly 0 or 1 adapter in the adaption,
you get n adapters (where n=0,1,2,3...) with subscription adapters.
Basically, instead of finding the most specific adapter, subscription
adapters will return *all* applicable adapters. So their lookup is a
bit like the one of subscribers, hence the name.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests