Chris Withers wrote: 
> 'DataSkins' doesn't mean a lot to me as a name :S
> What components would go into this product?

An object that has DataSkin as a base class allows a DataManager to look
after its data storage requirements. The DataManager stores all the
propertysheets and attributes, and works out what to do and who to
notify when things change.

There are various types of DataManager in ZPatterns, and the important
ones take plug-ins so that you can greatly modify their behaviour.

Specialists and Customizers (aka Folders w/ customizer support) are the
main DataManagers you build an application out of.

Specialists may have Racks inside them to actually do the work of
storing the data, so you can think about your application's architecture
at many different levels of abstraction. You can say "The AddressBook
specialist manages Address DataSkins" but you can also say "The
Addresses rack in the AddessBook specialist stores the Address

When Objects get created or deleted or changed, a DataManager will tell
any Agents it knows about that this has happened, in case they are
interested. An Agent is anything that monitors the events produced when
things happen to DataSkins.

A Trigger is a kind of Agent that does something concrete, like calling
a method, in response to a change in a DataSkin. You can use a Trigger
to update a ZCatalog when a DataSkin gets added or deleted or changes.
This is good because catalog-awareness gets to move out of the domain
objects (business objects, or whatever) and into the parts of your
system that are concerned with the management of those objects.

You can even use two Triggers to update two different Catalogs when a
DataSkin changes -- for example, the AddressBook catalog, and also a
SiteIndex catalog for searching all the data in your system. Perhaps the
SiteIndex holds just minimal indexes and meta-data, whereas the
AddressBook catalog holds meta-data and indexes more specialised to an
address book.

Two other important aspects of the DataSkins part of ZPatterns are
SheetProviders and AttributeProviders. These plug into Racks (and
anything else that takes "Data Plugins") and do the work of getting
propertysheets and calculating or importing attributes. These attributes
and propertysheets generally end up as the data belonging to the

> Yup, sounds like a great idea. Hopefulyl Pluggins could get into the
> Zope core ASAP. I reckon they might be quite useful to ZMI mark II :-)

What is ZMI?

Steve Alexander
Software Engineer
Cat-Box limited

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to