At 11:58 PM 8/9/00 +0100, Steve Alexander wrote:
1: ZClass instances can have PropertySheets added to them, independently of any sheets declared in the ZClass class definition.
I've been working with Zope for a while, but this had never occurred to me. I guess this is just another one of those hangovers from writing in Java for so long.
It's not a very well-known feature of Zope. AFAIK, it was implemented to support WebDAV, which requires the capability to add arbitrary propertysets to an object, which must NOT interfere with one another or the object's base properties.
2: If, in a dataskin-derived ZClass class definition, I define a "common instance" propertysheet, values in that propertysheet for instances get stored in the ZODB just like any other ZClass instances' propertysheets.
Not exactly. What happens is that __getattr__ never gets called for those attributes, so you can't have a provider give a value for them. __setattr__ and __delattr__ *do* get called, so if you modify those values on an instance, the providers will get called. However, since they never get called for attribute retrieval, you will never see the effects of the change. In short, "common instance" property sheets are *broken* with respect to DataSkins and should be avoided in favor of DataSkin propertysheets which are built so as not to have this problem.
However, if I define a "dataskin" propertysheet for my ZClass, I can provide the content of these sheets to my ZClass instances using AttributeProviders.
Yes.
However, because of the way Attributes work, I cannot supply data for a dataskin-propertysheet as a separate independent sheet object. The sheet comes from the ZClass, the data comes from an Attribute Provider.
Yep. To supply an independent sheet object, you need a sheet provider. And ZPatterns "out of the box" only includes a Persistent Sheet Provider, primarily to support WebDAV's requirement for adding arbitrary property sets.
3: If I want to use a SheetProvider, and thus use some of the important features of ZPatterns, I need to use object.propertysheets.manage_addPropertySheet() on each ZClass instance that should have a sheet from a SheetProvider. One way of doing this is with a Trigger.
Yes. Another way is that if you write your own SheetProvider, you can define its _objectAdding() and _objectDeleting() methods to automatically create the sheet. Or, if existence of the sheet is predicated upon something else, you can simply answer the getSheet/getSheets() method calls by checking to see if that sheet exists, and if so, returning it. This is useful when, for example, you need to provide an object with a propertysheet that presents and/or updates data from a legacy database or other external system.
4:
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.
..because the SQL sheet provider can provide sheets to ZClass-dataskin instances, even though the original ZClass was not defined to have this propertysheet. But I'd also have to add sheets to each applicablt instance, as in learning point 3 above.
Right, unless you write your sheet provider to just provide the sheet anyway. Sheet providers get asked what sheets are available for an object, and can simply provide some whether they've been "added" or not. The "manage_addPropertySheet" step is optional if you're creating custom sheet providers which can either add the sheet automatically, or have the sheet just always exist.