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
necessary;.
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
useless.
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".
registry.registerSubscriptionAdapter()
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 - [email protected]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
