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.