[Zope-dev] PROPOSAL: Splitting ZPatterns into two products

[Phillip J. Eby]

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.