Thanks for your answer Panos, Or, else, you could think of your 'fake.address' class just having a > many2one > to a 'res.partner.address' (and perhaps use a few related fields to make > the > res.partner.address data appear directly in fake.address) . What would be > the > difference between that and an "_inherits" implementation? >
It's the same, except that I have to define the fields as fields.related. I have different kind of addresses, with the same "base". That's why _inherits seems to be perfect. But here, I want to store "common" data in res.partner.address and "specific" data into my subclass. Currently, I show the field which containts the many2one relation defined in _inherits (with an on_change), to let the user choose if he wants to create a new res.partner.address, but their might have a better way to do this, that's why I asked. > > > Note: I'm currently using the 'virtual' feature, which makes good use of > the > "_inherits" API and lets my modules have real OO structure/behaviour. So > far, > this is the best exploit for the under-used "_inherits", but also sets a > more > specific set of rules about the "_inherits" usage. > What's this "virtual" feature ? > > > OO = Object Oriented > > -- > Say NO to spam and viruses. Stop using Microsoft Windows! > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-framework > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-framework > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
