On Sun, May 17, 2009 at 3:13 PM, johnf <jfabi...@yolo.com> wrote: > > I have played with this issue in the recent past ( a few months ago). > > > account.account_id = contact.account_id (1 Account, M Contact) > > opportunity.opportunity_id = contact.opportunity_id (1 Opportunity, M > > Contact) > > In the visual Fox Pro world setting up that relation is easy. VFP has 'use > again'. Where I can reuse a table with a different alias. I have > attempted > to do the same with Dabo without success. I don't say it can't be done > (because others have reported success) I just say I was unsuccessful. > > I have defined a class for a bizobj and I called it 'Contact' > > class Contact(dabo.biz.dBizobj): > def afterInit(self): > self.DataSource = 'public.contact' > self.KeyField = 'pkid' > self.addField = 'pkid' > self.addField = 'name' > self.addField = 'fk_account' > self.addField = 'fk_opportunity' > > In the MainForm Class I have tried: > > def CreateBizobjs(self): > self.acct_Contact = Contact(self.connection) > self.acct_Contact.LinkField= 'fk_account' > self.acct_Contact.ParentLinkField = 'pkid' > > self.opp_Contact = Contact(self.connection) > self.oop_Contact.LinkField= 'fk_opportunity' > self.oop_Contact.ParentLinkField = 'pkid' >
Interesting, that is just what I though. It should work, but since it doesn't perhaps the LinkField and ParentLinkField could be supplied as arguments in the constructor (or alternatively Contact could be subclassed for Account and Opportunity, just changing those two properties. I've chencked the source and dBizobj takes the constructor parameters (as it seems to be Dabos' rule). > > The above code does not work for me. But I think it should. I have two > instances of the same table and each instances has different links. I have > tried changing the string of the DataSource (used the addFrom > ='public.contact') for each of the instances. And that does not work. > Perhaps Ed knows. > > Of course you could have designed the tables in a different manner. I'm > sure > that's what Ed will say. There are several ways to get that done. All > depend on your needs. > hehehe, of course the program must also adapt :-) But I have it working just by having two different Bizobj classes for the same table. Note that actually those two interfaces represent different (but compatible) rules. In terms of design and maintenance I put them in the same file so that I have all pertaining to the same table together. In abstract terms I don't see a real problem in terms of design if there are two sets of rules for the same table in different bizobjs, as long as: they are compatible and clearly distinct. In that case if they are in the same class they are still very distinguishable! But I don't want to start a philosophical discussion. I can live with just one per table, or not. Whatever works well enough. Miguel --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- _______________________________________________ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/a19730800905171434g455bf545gc63a5e285f4c9...@mail.gmail.com
