Zope's oo programming model is a powerful method to build web applications. However Zope's current integration with external data stores breaks the oo model by treating external data stores as sources of raw data or primitive proxies (brains). Virtual SmartObjects aim to be a lightweight approach to seamless integration of external data sources with zope in oo manner.
My fledgling uml skills making an overview picture Figure 1-1
Figure 1-1 Virtual SmartObjects UML
The whole virtual smartobjects framework is based off a metadata model which allows for generation of classes, interrogation of attributes, and or mapping.
ModelContainers set a default model for traversal which is used for traversal from the application container or from the smartobject container (smartobject container creation option).
ObjectCaches store unwrapped objects. Cached Objects are invalidated both on time (configurable option) or based on object changes. object caches are per model. caches are also configurable by number of objects.
The traversal assistant attaches to pre traversal methods, upon being called it checks its immediate container for the requested object. if it doesn't find it, it will ask the model container for the object, if the object is in the default model, than no qualification is needed in the url.
example url: mysite.com/notes/1112
note that notes is a normal zodb based folder.
if the traversal stack contains nested object references like
example url: mysite.com/projects/12001/task/11121/projects/123
The traversal assistant performs an attribute check insuring a valid traversal chain through the models and than proceeds to load up the objects from the models. in doing a nested traversal lookup,
SmartObjects are transaction aware. They implement the full transaction interface including subtransactions (for subtrans capable data stores), upon object mutation, the smartobject registers itself for the transaction. upon transaction commit, the smart object invalidates its cache entry, and is saved to the external data store.
Acquistion is used both as implementation aid and to integrate with zope's security model. smartobjects are wrapped by their model before being returned.
Management takes place both at the model level and at the smartobject level. permissions are defined at the model level to integrate with legacy applications that define their own permission model. acquisition is used to construct the management interface for smartobjects.
model level management allows the definition of data source methods, and alteration of the models permissions and cache.
I need to research this more, i'd like to have permissions be model based with run time lookups, but i need to investigate the declarative security model more before i'm sure of the feasability.
For reporting or listing situations going through the list framework. supports both return of raw data, or writing custom methods to a model
Of all the proposed query interfaces, i think xpath is probably the most natural to zope and the easiest to integrate into the framework. xpath fits very nicely with traversal and nested objects.
Kapil Thangavelu ([email protected])