2014-07-25 17:27 GMT+02:00 Cédric Krier <cedric.kr...@b2ck.com>:
> On 25 Jul 08:56, Guillem Barba Domingo wrote:
> > 2014-07-24 18:34 GMT+02:00 Cédric Krier <cedric.kr...@b2ck.com>:
> >
> > > On 24 Jul 18:22, Guillem Barba Domingo wrote:
> > > > Hi,
> > > >
> > > > it's known that there is in the roadmap to remove "ir.property" from
> > > Tryton.
> > > >
> > > > To be prepared for this change, which we strongly endorse, NaN·tic
> and
> > > > ZikZakMedia have started to implement company dependant values as
> > > > Functional fields which get the value from auxiliar model.
> > > >
> > > > You can find an example of company dependant configuration field
> here [1]
> > > > and company dependant party field (as example of instanciable model)
> here
> > > > [2].
> > > > You can see that getter and setter could be generalized, and if two
> > > modules
> > > > need to add "company related" fields to the same model we will have
> > > > repeated code and, maybe, some issues because of define twice (or
> more
> > > > times) the same model/field.
> > > >
> > > > For these reason, I propose that company module provide some Mixin
> and
> > > > other "infraestructure" to avoid duplicate code. You can find a PoC
> of
> > > > Mixin I propose here [3] and example that use it it here [4].
> > > >
> > > > I also think that models to store "company dependant" fields should
> be
> > > > provided by core modules (I'm talking about
> "product.category.company" in
> > > > [4]).
> > > >
> > > > What do you think?
> > >
> > > I think there is no need of mixin. Indeed using a mixin will just
> > > reproduce the same issue as for Property field.
> > >
> >
> > I don't understand.
> > Without mixin we will have the same code in lot of modules, event
> repeated
> > for the same model
>
> For me, the topic is more about how data will be stored.
> For example, I find it good to have just a one2many on product for those
> fields. And also we saw that for cost_price one could need to extend it
> to be per company and warehouse etc. So if we want to keep it modular we
> have to rethink each fields and I don't think a global solution will be
> good because it will be like what we have now.
I think it's not the same than we have now because it could be extended by
inheritance.
Following your example:
Module product:
class Template:
cost_price = fields.Numeric()
Module company_product:
class TemplateCompany(ModelStorage):
template = fields.Many2One()
company = fields.Many2One()
cost_price = fields.Numeric()
# To be more generic, it doesn't add unique() constraints
class Template:
cost_price = fields.Function(fields.Numeric(), 'generic_getter',
'generic_setter')
Module product_cost_by_warehouse (hypothetical):
class TemplateCompany:
warehouse = fields.Many2One()
class Template:
def __setup__():
cls.cost_price.getter = new_getter
cls.cost_price.setter = new_setter
Another (provably better) option is that "generic getter/setter" get the
domain to apply to find product.template.company instance from a function.
By default it search by record+company but "product_cost_by_warehouse"
extend it to search also by warehouse.
I think 95% of cases fit perfect with generic getter/setter and have a
mixin reduces a lot the code of modules. If we think a little bit the
design we can find a good solution for the rest 5%.
IMHO, of course
--
Guillem Barba
http://www.guillem.alcarrer.net
