[Zope-dev] More comments on ZPatterns

[Steve Spicklemire]

>>>>> "pje" == Phillip J Eby <pje@telecommunity.com> writes:

    >> a (default) rack of TableInfo objects.
    >> 
    >> Now... some of the Tableinfo properties, and some of the View
    >> properties are *really* in MySQL. I figured out, from the mail
    >> list and the source code, that I can create a Generic attribute
    >> provider in the rack that can get attributes from an SQL
    >> database for my DataSkin descendents using the 'source
    >> expression' and 'target expression' business.

    pje> Congratulations, you found the top secret documentation.  :)

That's what I love about working with ZPatterns. You get to play all
sorts of "Roles" as a developer... part "James Bond", part "Hercule
Poirot", part "Bumbling Imbecile". ;-) I've heard that it's "Roles
before Objects" but I had no idea it would be like this!

Here's one I've been feeling kinda stupid about:
    
    >Now, "SkyDiver ... *used as*" means we should:
    >
    > 1. subclass (not a good choice)
    > 2. implement interface
    >    2.1. by copying and pasting methods code (or whole methoids)
    >    2.2. by proxiyng (SkyDiver has a references to actual Customer 
    >         and ResourceUser)
    >    2.3. by transmitting messages to SkyDiverSpecialist which will pass 
    >         unhandled messages to CustomerSpecialist and
    >         ResourceUserSpecialist (this is a variant of 2.2. case)
    >
    >The 2.3. case means we should use objects without types (identity
    >markers).
    
    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:

    pje> 
    pje> This isn't exactly code, but...
    pje> 
    pje> Set up a LoginManager with a GenericUserSource, and set up the GUS to have
    pje> users.  Make sure that the GUS has a "Persistent Sheet Provider" on the
    pje> "Sheet Providers" tab.  Then go to:
    pje> 
    pje> /acl_users/someuser/propertysheets/manage_addPropertySheet?id=sheetname&ns=
    pje> 
    pje> You should get a screen that says "OK".
    pje> 
    pje> Then go to:
    pje> 
    pje> /acl_users/someuser/propertysheets/sheetname/manage
    pje> 
    pje> And you should see a propertysheet editor for your new sheet.
    pje> (Unfortunately, it  won't let you edit anything unless your user class is
    pje> based on PropertyManager, due to an oversight in ZPatterns 0.3.0; the
    pje> VirtualSheets class needs "def propertyLabel(self,id): return id" to work
    pje> with the default Zope UI for a non-ZClass property sheet.)
    pje> 
    pje> Or go to:
    pje> 
    pje> /acl_users/someuser/propertysheets/manage
    pje> 
    pje> And you should see your new propertysheet listed on the sheets management
    pje> interface (which is somewhat broken, but that's because the basic one in
    pje> Zope is, it's not ZPatterns' fault. ;) )
    pje> 
    pje> Anyway, this is all very primitive but should get better in later versions.
    pje>  0.4.0 fixes the 0.3.0 and either it or 0.5.0 will replace the broken
    pje> propertysheets/manage screen with one that will let you add/edit/delete
    pje> sheets properly.

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?

thanks,
-steve