Steve Alexander wrote:
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.
Okay, makes sense...
There are various types of DataManager in ZPatterns, and the important ones take plug-ins so that you can greatly modify their behaviour.
I thought there were only two right now?
Specialists may have Racks inside them to actually do the work of storing the data,
Now what's a rack in Plugin terminology?
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 DataSkins".
By DataSkins here, particularly in the secodn phrasing, wouldn't it be better to say the AddressBook specialist stores the flesh and bones of the Address DataSkins?
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.
Are 'Objects' here DataSkins, non-DataSkins or either?
An Agent is anything that monitors the events produced when things happen to DataSkins.
But they're actually called by the Data Managers?
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.
Sounds cool, where does SkinScript fit in here?
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.
I think I like this...
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.
Now how would these triggers actually get added to the datamanager in the above example? I like this very much as it's something I've often wondered about but which CatalogAware never seemed to address...
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 DataSkins.
Ah, okay, I see now. So, for example, a SheetProvider would prove a property sheet for each DataSkin served by the DataManager in which it was located?
What is ZMI?
Zope Management Interface (specifically Mark II ;-) It's a proposal on dev.zope.org... cheers, Chris