"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