>>>>> "pje" == Phillip J Eby <[EMAIL PROTECTED]> 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
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> This isn't exactly code, but...
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> You should get a screen that says "OK".
pje> Then go to:
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> Or go to:
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> 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?
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -