[Zope-dev] ZPatterns Question

[Phillip J. Eby]

At 06:07 PM 8/8/00 +0100, Steve Alexander wrote:
>"Phillip J. Eby" wrote:
>> 
>> Actually, neither relates.  Property sheets created on ZClasses always have
>> their data stored in attributes of the object itself, so if you want to
>> control those property sheets you would not use a sheet provider at all.
>
>> Sheet providers are only used to provide property sheets whose data is
>> stored external to the object.
>
>I'm confused here. Please excuse me if these questions seem silly.
>
>
>What does "Property sheets created on ZClasses" mean, exactly?

I mean, if you go into the management screens for a ZClass, and add a
property sheet to the *class*, the sheet's definition is stored in the
class, and its contents are stored as attributes on the instances.  Sheet
providers have no effect on such property sheets, as they are defined in
the class.  However, if you use a "DataSkin Property Sheet", the attributes
of the sheet are stored in the instance in a way that is compatible with
attribute providers.  Thus, you can use attribute providers to provide the
content of the sheet.  But you cannot provide the sheet object itself.
This may seem a subtle distinction, but it is an important one for some
applications.  Sheet providers are primarily intended to add sheets outside
the scope of the class of object being used.


>If I use some DataSkin-derived ZClass instances inside a Customizer
>folder, and if I want to store the data in the ZODB, do the
>propertysheets for one of these ZClass instances come from
>PersistentAttributeProviders or PersistentSheetProviders?

If you create the sheets *in* the ZClass itself, then the *data* for the
sheets comes from an AttributeProvider (actually, it's just stored in the
instance, but the storage is controlled by an AttributeProvider).  The
sheet *itself* would come from the class.

If you create the sheet with
object.propertysheets.manage_addPropertySheet(), then the sheet will be
created and managed by a SheetProvider.


>What is the difference between a Common Instance Propertysheet and a
>Dataskin Attribute Propertysheet when added to a Dataskin-derived
>ZClass?

The difference is that a Common Instance property sheet stores default
values in the class under the original attribute name, which makes
__getattr__ unusable on the instances.  A DataSkin property sheet stores
default values in the class under the name "class_default_for_X" where "X"
is the attribute name.  This lets the DataSkin instances give an
AttributeProvider a chance to supply the value of an attribute before
falling back to a class-level default.


>Is the following true, part true, false, or irrelevant?
>
>If I want to add a propertysheet that contains information from an SQL
>database query to a ZClass-dataskin instance, I have to :
>
>* Declare in my Product that the ZClass has that propertysheet (unless I
>do clever stuff with triggers to add the sheet if it isn't there
>already)
>
>* Use a custom SQL SheetProvider? Or an AttributeProvider? Or some
>skinscript that calls various methods in my specialist?

You can do any of the above.  Currently, the easiest way to do it would
probably be to add the sheet to the class, and then use attribute providers
to supply the data.  If you needed to add this atop a class which needed to
be "final" (in the Java sense, i.e. no modifications allowed), then the
best route would be a custom SQL sheet provider.