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
(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.
> 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.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -