On 24/12/11 07:45 +0530, Sharoon Thomas wrote: > On Dec 24, 2011, at 3:09 AM, Cédric Krier wrote: > > > I think I have found a solution. > > > > First, we can have module extending Models define on other modules but > > without depending on it. Like puting the code of > > sale_shipment_cost_weight in carrier_weight but without making > > carrier_weight depending on sale. > > Which means no separate glue module :) > > > Second, we just need to ensure the carrier_weight will be loaded after > > sale_shipment_cost if it is installed. For this, let's introduce an > > other keyword "extra_depends" that will behave like "depends" but it > > will not be read when installing the module. > > This will not prevent tryton module loader from loading classes which > were meant to be inherited (but will be loaded as new). For example if > you inherit `sale.sale` and change the behaviour of a method, and if > sale module is not in `depends` tryton will create `sale.sale` as a new > model ?
That's not a problem if you use Model and not ModelSQL. Also that's why the other_depends is important to have the right order if the module is there. > > > > I think this design will allow to put glue code inside the module > > without crappy hack and it will be explicit via the extra_depends. > > I dont know if this is really a dependency management problem ? (if I > understood the problem right. Please correct me if I am wrong) > > I dont think these glue modules introduce new fields in DB and they only > overwrite existing methods or introduce new methods to change the > functionality. > > Why not provide an efficient helper function which checks if a module is > installed ? > > ``` > from trytond.tools import is_module_installed > > class Something(ModelSQL): > def create(self, values): > if is_module_installed(['sale', 'something_else']): > # do something > #anyway do this which is common > I think duck-typing is better here and more pythonic. > Though this might make methods bulky, I think it makes it more findable (and > hence readable) rather than having a lot of glue modules distributing > functionality > across the place. Normally we should try to limit the glue code and such code should be placed in a logical place. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgpFwiCtnxWLK.pgp
Description: PGP signature
