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
    as well. 

  * 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 - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to