Thanks for your answers, Phillip. Here's what I've learned. I still need to try these out on a test system, to prove to myself that they work the way I think they do. 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. 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. However, if I define a "dataskin" propertysheet for my ZClass, I can provide the content of these sheets to my ZClass instances using AttributeProviders. (Are the above two paragraphs correct? Or can I use AttributeProviders to supply data for common instance propertysheets also, but I can't use default values for such sheets?) 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. 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. 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. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net