At 10:22 PM 7/28/00 +0100, Chris Withers wrote:
Steve Alexander wrote:
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?
Technically, there are three - Specialist, Rack, and Customizer. But Specialist is never directly used by a DataSkin as its data manager, because of the Rack. Specialist derives from DataManager, though, so it can have data plug-ins for use by its Racks. So there are only two "true" DataManagers - Rack and Customizer. I don't expect there will be any more in future, because I don't know of any other ways to organize Zope objects besides: 1) a flat namespace (Rack), or 2) a sub-object tree (supported by Customizers).
Specialists may have Racks inside them to actually do the work of storing the data,
Now what's a rack in Plugin terminology?
A plug-in that's also a plug-in container.
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?
Here's how I prefer to say it... An "AddressBook" specialist is where you get, create, or manipulate en-masse, things which you'd like to have in an address book. It may contain one or more racks which store some particular concrete class of things which have addresses, and which you want to have available through your addressbook specialist. The rack does not necessarily store the "flesh and bones", because that might reside in LDAP, SQL, the filesystem, or something else altogether. The rack is a "storage manager" which manages the process of realizing DataSkins of a particular class with common storage characteristics.
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?
DataSkins only.
An Agent is anything that monitors the events produced when things happen to DataSkins.
But they're actually called by the Data Managers?
Yes. DataSkins tell their DataManager they've changed; the DM forwards the appropriate messages to the Agents.
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?
SkinScript can be used to specify DTML expressions to be called as triggers, or to be used to calculate attributes, etc. In place of an AttributeProvider or Trigger, you plug-in a SkinScript Method to a DataManager, then write the SkinScript code to describe all the attributes and triggers, etc. you want.
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?
You go to its Data Plug-ins tab, and select from the "Add" dropdown the kind of trigger or provider you want. Then you fill in its settings to do what you want it to do.
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?
Yep.