On Tue, 10 Feb 2004 15:26:00 +0100
Michael Haubenwallner <[EMAIL PROTECTED]> 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
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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -