[Zope-dev] ZPatterns Question

[Phillip J. Eby]

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.