History for DataSkinsOverview

??changed:
-
Data Skins - The Core Framework of ZPatterns

 What is a Data Skin?

  A Data Skin is a Zope object which transparently delegates certain aspects of its behavior to a set of Data Plug-Ins which it accesses by way of a Data Manager.  In ZPatterns releases to date, this behavior can include attribute and propertysheet management, but future releases are expected to support sub-object content management and local roles computation as well.  Also, as of release 0.4.1snap1, you can even extend the framework and create your own delegation interfaces and plugins for them.


 So what are Data Skins for?

  Data Skins let you defer a wide variety of implementation decisions by seperating "problem domain" design decisions from "data management" design decisions.  They let you create classes whose data management is delegated to objects or methods which are created at application integration time rather than while developing the problem domain classes.  See the DropZoneExample to get an idea of why this is important/helpful.

  <IMG SRC="!DataSkins.gif">

  *Note: diagrams are in Coad notation, not UML.  For example, the above should be read as*:

   * *A !DataSkin is associated with one and only one !DataManager (which may be associated with other DataSkins)*.

   * *A !DataManager contains 0 or more Data Plug-ins*.

   * *"Attribute Provider", "Sheet Provider", "Content Provider", and "Local Roles Provider" are kinds of Data Plug-ins*.


 What is a Data Manager?

  A data manager helps data skins by:

   * Providing them access to their Data Plug-ins, including propagating transaction events and DataManagementEvents to the Data Plug-ins

   * Informing them of transaction-related events

   * Keeping track of their canonical or "normalized" forms for acquisition management

   * Telling them how to access their "slot" - a !PersistentMapping object used to store "extra stuff" like property sheets.

  Most of this is "under the hood" detail that is irrelevant to most users of ZPatterns.  For all intents and purposes, the principal purpose of a Data Manager is simply to give a Data Skin its Data Plug-ins.


 What kinds of Data Managers are there?

  The current ZPatterns system offers the following Data Manager subclasses:

   * [Racks]

   * [Customizers]


 How do Data Skins get hooked up to a Data Manager?

  Two possible ways.  First, if a data skin is stored in a Rack, the Rack calls a '_setRack' method on the data skin, which tells the skin that the Rack is its data manager.  Or, if a data skin is retrieved from any other Zope object, its '__of__' method will try to find a Customizer or "Folder With Customization Support" in the acquisition path, then ask it for a data manager to bind with.  Once this is done, the skin remains bound to that manager until the next such occurrence.


 How do Data Skins access their Data Plug-ins?

  Once a skin is bound to a Data Manager, it can ask the Data Manager for a set of plugins which meet its desired criteria.  It can ask for either a list of all plugins which are registered as providing a certain *kind* of data (e.g. all sheet providers, all attribute providers, etc.) or all plugins which have registered as providing a specific service and instance of that service (e.g. "set attribute" service for attribute "foo").  The Data Skin can then ask the individual plug-ins for service, and fall back to a default implementation of the desired service if no suitable plug-ins are available.