1. Mailing Lists
  2. Contributors
  3. Re: Best Practice for Module Design

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Avatar

Re: Best Practice for Module Design

by
Camptocamp France SAS, Alexandre Fayolle
- 04/01/2017 07:28:15 
Hello Graeme,

I'd keep the dependency explicitely. This gains:

* clarification about what the code is doing although it does not seem
to be called anywhere in the module

* you will get the unit tests running correctly and test coverage tools
in CI will show that the code is indeed tested.

Best wishes for 2017

Alexandre

On 30/12/2016 01:37, Graeme Gellatly wrote:
> Hi,
> 
> I'm just refactoring some modules at the moment.  One of these is a
> custom version of sale_intercompany_auto.  Essentially it just extends
> the existing behaviour and adds some fields based on the sum of all
> other custom modules.
> 
> Now it has occurred me that perhaps a smarter way is that, in existing
> modules to just to do the inheritance and override there.
> 
> For example
> 
> Module A - add field a to sale order and purchase order
> 
> def _do_something_automatically(self):
>    res = super()
>    res.update(field a)
>    return res
> 
> Module B - add field b to sale order and purchase order
> 
> def _do_something_automatically(self):
>    res = super()
>    res.update(field b)
>    return res
> 
> As these functions are only called by the inter_company_rules module, I
> am thinking I can allow for the possibility that it might be installed,
> but not need to worry if it isn't, and not declare an explicit dependency.
> 
> Thoughts?  Better ways?
> 
> 
> _______________________________________________
> Mailing-List: http://odoo-community.org/groups/contributors-15
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: http://odoo-community.org/groups?unsubscribe
> 


-- 
Alexandre Fayolle
Chef de Projet
Tel : +33 4 58 48 20 30

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac Cedex
http://www.camptocamp.com

Reference