Leonardo Rochael Almeida wrote:
> Acquisition is very powerful, and very "magic" at the same time.
> Adapters is Zope3 way of implementing "Acquisition" in a less
> "surprising" way.
The main drawback of acquisition, which is a drawback in general of
Zope 2, is that namespaces get conflated.
Zope 2 is handling namespaces in a really unpythonic way. When you call
a method the actual method can be coming from a huge range of places:
* method defined by the class the object is an instance of.
* method defined on a superclass of this class. In Zope 2, there are
many many mixins which may be defining this method.
* method defined directly on the instance in the ZODB (a Python script,
for instance), if your instance is Folderish.
* method acquired from object somewhere in acquisition context. These
objects can have methods from their class, mixins, and directly defined
if they're Folderish, of course. :)
* if you're using CMF skins, method can be coming from any skin folder
* if you're using DTML, it can be coming from any object in your
namespace stack. :)
Page Templates fix the last part. Using the Silva view system (for instance)
fixes the namespace conflation done by CMF skins.
On the filesystem product level, you can use adapters to avoid increasing
the mixin problem in your own code. We've started doing this in a simplistic
fashion with Silva now, and plan to extend this use much more in the
future, porting methods defined on base classes onto adapters instead.
Adapters in Zope 2 are immature at present, but this will change after
they've gotten properly backported from Zope 3 and such a backport is
released. This is what is going to happen within the coming months, as I'm i
in a project which has this as a requirement.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -