Document Actions

#96: Extensible index object wrapper

Contents

by Christian 'Tiran' Heimes — last modified June 11, 2006 - 00:22

We have been adding stuff like getObjSize and getObjPositionInParent to ATCT because we want it to be cataloged efficiently. These things don't feel like they really belong there though. How about extending our IndexableObjectWrapper class (see CatalogTool.py) to add those attributes for cataloging only? That's how allowedRolesAndUsers works.

Proposed by: Stefan Holek
Seconded by: Christian 'Tiran' Heimes
Proposal type: Architecture
Repository branch: plip96-extensibleindexobjectwrapper
State: completed

Definitions

registry -- a place to register something
wrapper -- a design pattern to add behavior to an object by wrapping it transparently
global -- non persistent and zope wide var
local -- persistent and placeful var

Motivation

There is no need to add api methods to content types or slow ttw scripts with an extensible index object wrapper.

Also see summary

Proposal

Replace the current IndexableObjectWrapper with an ExtensibleIndexObjectWrapper + a register that contains a mapping between attribute name and a callable.

The ExtensibleIndexObjectWrapper return the indexed object's attribute when the attribute name isn't listed in the registry. If the name is in the registry then the registered callable is called with the object as argument and the value is returned.

IMO there is no need to have a local (per site) registry at the moment so we should follow the sacret rules of KISS and YAGNI and stick to a simple global dict like registry.

Maybe use a registry of adapters

Posted by Frank Bennett at July 13, 2006 - 03:36

I have a product that needs attributes added to another, separately maintained product in order to work correctly, and I've been looking for a good general solution like this. I was glad to find this PLIP on file.

I wonder whether it might be more natural to implement this as a registry of Five/Z3 adapters. Adapters are called in exactly this way, as a bare function with the object as argument, but a single adapter can apply a bundle of related methods to an object.

Another idea that could be pulled in from Z3 is the use of interfaces to invoke the registered adapter selectively on objects undergoing (re)indexing. This would make me very happy because it would completely cover my own use case (!). But it would also be generally handy to be able to discriminate between content types in this way.

If there is any way I can help out with this, let me know!

Foot in mouth

Posted by Frank Bennett at July 13, 2006 - 05:18

Ah. Seems "completed" means, er, already in Plone. So much for that, then.

Plone CMS: Open Source Content Management

Sections

Personal tools