On 26 Feb 2007, at 23:48 , Tres Seaver wrote:
I nowhere said anything about deprecation. All meant was to discourage relying on acquisition when developing new tools. I think that deserves a comment (I suggested nothing more). No deprecation warning or anything

OK.  I do think we need to have some resistance to the "Zope2 is evil,
Zope3 is wonderful" fundamentalism which sometimes shows up around here. Frankly, Zope3 *is* a cool library, but it does not address a number of
the scenarios Zope2 does, and maybe never will.

Yes. Zope 3 is can be seen as a set of libraries -- and a number of approaches.

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

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 utility providing ICMFSite (or whatever). Then whichever code that's executed
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 wrapped.
They darn well better be able to get a wrapped context (which means that
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 you do IWhatever(obj) and you got obj thru acquisition, then the IWhatever
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 wrapped
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 lookup.

Note that subscription adapters != subscribers. Subscribers don't return
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 registers a
"subscription adapter".


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

Reply via email to