A Divendres, 23 de desembre de 2011 14:09:40, Cédric Krier va escriure: > Hi, > > With the latest developments, I started to write a lot of glue modules > like: > > - purchase_shipment_cost_percentage > - sale_shipment_cost_weight > > and I start to need one more purchase_shipment_cost_anglo_saxon because > the accounting move when the unit price include shipment cost must be > splitted.
And probably the product_kit module will require something like this too. > All this glue modules don't add new functionality but fix existing one > because 2 (or more) modules are activated on the same database. > > I think it means there is something wrong with this design. > > So, I would like to know what is your feeling about having some code in > some modules that tests if an other module is activated or not? It will > be a little bit like duck-typing. > > By the way, we already have some code with such design like the template > in the module product or the grouping of shipment in sale and purchase. > > The main issue, I see in this way, is that some feature should need to > wait a new release to be added. For example, the purchase_shipment_cost > can not be developed for 2.2 as it will require a modification of > account_stock_anglo_saxon. > A second is about testing, it will be harder to test such part of the > code because by default the extra-module will not be installed. Some other thoughts to add to the discussion: I think we need that compatibility/dependency to be in the module definition. So if the user installs the modules "purchase_shipment_cost" and "stock_account_ango_saxon", then "purchase_shipment_cost_anglo_saxon" should be automatically marked for installation as if it was a dependency. That information should probably come from the purchase_shipment_cost_anglo_saxon module, or it may come from any of the other two. In case of the approach of modifying the existing module, maybe the __tryton__ file should also inform that the module takes into account a given set of otherwise incompatible modules. I think we need a way to know which modules require some others or check for their existance. As you said, if a module requires another one to be modified it may not be possible to develop it for a previous version which I think it is very bad so it sounds as the wrong solution from this point of view. Ferdinand Gassauer once suggested to be able for a module to include patches that would be applied to existing modules. I don't like that idea very much but maybe it inspires somebody for a more flexible solution. -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- [email protected] mailing list
