Adapters in Zope 2
Hi all, I know that adaptors are introduced in zope3 but, anybody knows if this technique can be used in zope2 ? I've been trying to add some extra functionallity to a Folder object without inheriting, but I'm not able to make it work. To maintain the adapted object publishable I've rewrited __getattr__, but then some extra problems appears. Anybody knows if there is a way to use adapters in zope2 ? Or, if not, there is some other way to add functionallity on-the-fly, without inheriting ? Thanks in advance -- Santi Camps http://zetadb.sourceforge.net
On Mon, 09 Feb 2004 21:48:29 +0100 Santi Camps <santi@zetadb.com> wrote:
Hi all,
I know that adaptors are introduced in zope3 but, anybody knows if this technique can be used in zope2 ?
Adapters are a general pattern. Zope 3 has infrastructure (component architecture and ZCML) that automates registering and using them, but the general pattern can certainly be applied to Zope 2 without it. Just create a class which defines the methods you want, and accepts a folder in its constructor. When you want to use the adapter, instantiate the class around the folder.
I've been trying to add some extra functionallity to a Folder object without inheriting, but I'm not able to make it work. To maintain the adapted object publishable I've rewrited __getattr__, but then some extra problems appears.
__getattr__ hooks are notoriously tricky to get right, especially for Zope due to acquisition and especially for folders.
Anybody knows if there is a way to use adapters in zope2 ? Or, if not, there is some other way to add functionallity on-the-fly, without inheriting ?
Zope2 folders are designed for this. They are really just "blank objects" where you can specify your own methods in instance space. Traditionally in Zope2, there are two ways to do this: by adding "method" objects (External Methods, DTML methods, python scripts, ZPT) directly to the folder. Or by adding these objects "above" the folders and aquiring them which is a type of environmental inheritance. In the CMF this is codified in the skins tool which contains global methods which can be applied to basically any object in the site. hth, -Casey
Casey Duncan wrote:
Zope2 folders are designed for this. They are really just "blank objects" where you can specify your own methods in instance space. Traditionally in Zope2, there are two ways to do this: by adding "method" objects (External Methods, DTML methods, python scripts, ZPT) directly to the folder. Or by adding these objects "above" the folders and aquiring them which is a type of environmental inheritance. In the CMF this is codified in the skins tool which contains global methods which can be applied to basically any object in the site.
Great explanation - would you give me a hint on the CMF part ? Which global methods do you speak of ? -- michael
On Tue, 10 Feb 2004 15:26:00 +0100 Michael Haubenwallner <michael@d2m.at> wrote:
Casey Duncan wrote:
Zope2 folders are designed for this. They are really just "blank objects" where you can specify your own methods in instance space. Traditionally in Zope2, there are two ways to do this: by adding "method" objects (External Methods, DTML methods, python scripts, ZPT) directly to the folder. Or by adding these objects "above" the folders and aquiring them which is a type of environmental inheritance. In the CMF this is codified in the skins tool which contains global methods which can be applied to basically any object in the site.
Great explanation - would you give me a hint on the CMF part ? Which global methods do you speak of ?
The CMF has a "Tool" infrastructure. Tools are persistent objects typically at the top of the CMF site. Tools provide methods and configuration for use by all objects in the site via acquisition. For example, the membership tool (portal_membership), provides methods to access member information and member folders. The portal_skins tool is special in that it actually contains framework and application defined method objects (scripts, templates, etc) organized into layers and configured into skins (which are lists of layers to use). The CMF Site object is a special "Skinnable" folder which allows methods available in the current skin (as described in the skins tool) to be acquired through it. This makes all of the method objects in the skin's layers globally available to all objects in the CMF site. This solves several problems, one of which is a tendancy of top-heavy hierarchies in zope where lots of objects are in the root because they need to be global. The skin and layer mechanisms allow different sets of methods to be available depending on the application, products installed, site policy and user preferences. -Casey
Casey Duncan wrote:
Zope2 folders are designed for this. They are really just "blank objects" where you can specify your own methods in instance space. Traditionally in Zope2, there are two ways to do this: by adding "method" objects (External Methods, DTML methods, python scripts, ZPT) directly to the folder. Or by adding these objects "above" the folders and aquiring them which is a type of environmental inheritance. In the CMF this is codified in the skins tool which contains global methods which can be applied to basically any object in the site.
Great explanation - would you give me a hint on the CMF part ? Which global methods do you speak of ?
The CMF has a "Tool" infrastructure. Tools are persistent objects typically at the top of the CMF site. Tools provide methods and configuration for use by all objects in the site via acquisition. For example, the membership tool (portal_membership), provides methods to access member information and member folders.
The portal_skins tool is special in that it actually contains framework and application defined method objects (scripts, templates, etc) organized into layers and configured into skins (which are lists of layers to use). The CMF Site object is a special "Skinnable" folder which allows methods available in the current skin (as described in the skins tool) to be acquired through it. This makes all of the method objects in the skin's layers globally available to all objects in the CMF site.
This solves several problems, one of which is a tendancy of top-heavy hierarchies in zope where lots of objects are in the root because they need to be global. The skin and layer mechanisms allow different sets of methods to be available depending on the application, products installed, site policy and user preferences.
-Casey
Very interesting. That's what I was looking for. I will try to extract this mechanism from CMF. Thanks a lot for your answers -- Santi Camps http://zetadb.sourceforge.net
On Tue, 10 Feb 2004 17:34:39 +0100 Santi Camps <santi@zetadb.com> wrote: [..]
Very interesting. That's what I was looking for. I will try to extract this mechanism from CMF.
See: http://www.plope.com/Members/chrism/standalone_skins 8^) -Casey
Santi Camps wrote:
Casey Duncan wrote:
Zope2 folders are designed for this. They are really just "blank objects" where you can specify your own methods in instance space. Traditionally in Zope2, there are two ways to do this: by adding "method" objects (External Methods, DTML methods, python scripts, ZPT) directly to the folder. Or by adding these objects "above" the folders and aquiring them which is a type of environmental inheritance. In the CMF this is codified in the skins tool which contains global methods which can be applied to basically any object in the site.
Great explanation - would you give me a hint on the CMF part ? Which global methods do you speak of ?
The CMF has a "Tool" infrastructure. Tools are persistent objects typically at the top of the CMF site. Tools provide methods and configuration for use by all objects in the site via acquisition. For example, the membership tool (portal_membership), provides methods to access member information and member folders.
The portal_skins tool is special in that it actually contains framework and application defined method objects (scripts, templates, etc) organized into layers and configured into skins (which are lists of layers to use). The CMF Site object is a special "Skinnable" folder which allows methods available in the current skin (as described in the skins tool) to be acquired through it. This makes all of the method objects in the skin's layers globally available to all objects in the CMF site.
This solves several problems, one of which is a tendancy of top-heavy hierarchies in zope where lots of objects are in the root because they need to be global. The skin and layer mechanisms allow different sets of methods to be available depending on the application, products installed, site policy and user preferences.
-Casey
Very interesting. That's what I was looking for. I will try to extract this mechanism from CMF.
Chris McDonough has already released a "standalone" version of the skins tool: http://plope.com/Members/chrism/standalone_skins Tres -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
Santi Camps wrote:
Very interesting. That's what I was looking for. I will try to extract this mechanism from CMF.
Silva has co-evolved (some of it inspired directly by CMF, some by Zope 3) much of the same infrastructure. Our view system is quite different, and some large changes to it in the coming months. We use a very simple 'service' model (equivalent to 'CMF' tools), and we've just started to use a very simple kind of adapter. Though likely less structured than the CMF it may be worthwhile taking a way to look at the way we do it in Silva. Regards, Martijn
Hi Santi. The Zope2 official way of extending objects at runtime is acquisition. The easiest way to make use of it is to put the methods/scripts you need in the acquisition path (e.g. closer to the root). There are more sofisticated methods, such as SkinnedFolders and "TransparentFolders" that allow you to shape acquisition to avoid cluttering parent folders with methods and/or a more precise control of the selection of objects to be aquired. All of the methods of shapping acquisition rely on creative interpretation/manipulation of the __of__() method of acquisition-aware objects. Acquisition is very powerful, and very "magic" at the same time. Adapters is Zope3 way of implementing "Acquisition" in a less "surprising" way. On Mon, 2004-02-09 at 18:48, Santi Camps wrote:
Hi all,
I know that adaptors are introduced in zope3 but, anybody knows if this technique can be used in zope2 ?
I've been trying to add some extra functionallity to a Folder object without inheriting, but I'm not able to make it work. To maintain the adapted object publishable I've rewrited __getattr__, but then some extra problems appears.
Anybody knows if there is a way to use adapters in zope2 ? Or, if not, there is some other way to add functionallity on-the-fly, without inheriting ?
Thanks in advance -- Ideas don't stay in some minds very long because they don't like solitary confinement.
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. Regards, Martijn
participants (6)
-
Casey Duncan -
Leonardo Rochael Almeida -
Martijn Faassen -
Michael Haubenwallner -
Santi Camps -
Tres Seaver