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

[Chris Withers]

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