[Zope-dev] More comments on ZPatterns

[Phillip J. Eby]

At 12:38 PM 7/9/00 -0500, Steve Spicklemire wrote:
>    
>    pje> None of the above.  SkyDiver should inherit from a Party base
class.  For
>    pje> Customer and ResourceUser behavior, one adds propertysheets whose
class is
>    pje> provided by the respective frameworks.  This is extension through
>    pje> *composition*, rather than inheritance.  It is similar to the COM
approach,
>    pje> where you can ask an object to give you a pointer to an
interface.  In this
>    pje> approach, you ask for a propertysheet that provides the interface.
>    
>"One adds propertysheets" is much easier said than done... IMHO. The only way
>I've seen to add propertysheets to objects is to call manage_addPropertySheet
>on individual instances... as described in this earlier email:

That's the only way that's implemented "out of the box".  But there's no
reason you can't implement a SheetProvider that automatically creates the
sheet when the object is added, or why you can't use a GenericTrigger to
add the sheet using one of the out-of-the-box SheetProviders.  When I get
SkinScript objects done, this'll be easier because you'll be able to just
spec out a propertysheet in SkinScript and have the dirty work done for you.

>I just want to make sure I understand... is the intention that property
management
>needs to be done on each instance separately? So if I add a new property
to one
>of my property sheets, I need to somehow update the propertysheets of each
of the
>instances? Also.... if I need to create propertysheets for each
instance... where
>should that be done? I suppose it makes sense to put that in the
Specialist that
>handles the object that gets the properties?...no?

The intention is that you use SheetProviders for anything global.  Adding
propertysheets on an instance-by-instance basis is something that's
intended for an interface point between two frameworks.  Say for example
you have a project scheduling framework that needs to store a due date
associated with a document -- the scheduling system can query for a
scheduling propertysheet, and if it doesn't exist, add it.  However, since
you control what SheetProvider implements that propertysheet, you can (for
example) use the same SQL database for all scheduling fields across your
site.  If you don't need special handling, however, you can leave the
default "Persistent" SheetProvider in place and the scheduling properties
would get stored persistently.