openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Guys,

please notice that we also have the exact same modularity issue with
on_change methods:

module (A)
'state': on_foo_change(a)

module (B) depends on (A)
'state': on_foo_change(a, b)

module (C) depends on (A)
'state': on_foo_change(a, c)

if module (B) and (C) are both installed but otherwise completely
independent
of each other either (B) or (C) won't find one of their values in the
on_change methods.

This would be solved if it were done like the Tryton forks does: passing
on_change arguments as dictionaries and merging values (and passing the
context as well by the way) instead of using positional arguments.
Workaround here (like for the example by Ferdinand): hardcode a pig module D
that depends both on B and C and pass the right args or define the right
selection in Ferdinand's example.

As for the Ferdinand's example, I remember Stephane Wirtel proposed a
solution on Twitter recently, but it was totally clumsy (even us wouldn't
get it), and it would also define the selections for all the databases of
the same server, meaning wasn't clean either.

Overall I would like we plan long term solutions for those modularity issues
as this let modules non compatible (so the multiply in a non manageable way
instead of working well together) and non straightforward to install. For
the on_change limitation, it the solution would just be to copy the Tryton
solution and plan the API change over the major versions. For the selection,
I don't know about the solution yet (disclaimer: I didn't think about it
either).

Raphaël Valyi
*http://www.akretion.com* <http://www.akretion.com>
[image: logo_only_17 (another copy).png]



On Sun, Jun 27, 2010 at 11:36 PM, Sharoon Thomas <sharoonthomas@xxxxxxxxxxxx
> wrote:

> Hi All,
>
> This is possible as far as i know, but is a dirty and twisted way because
> of the "non-pythonic" nature of python programming in Open ERP.
>
> You could change it this way in the init method of the class which inherits
> the parent object.
>
> super()._columns[<'key' your selection field
> name>].selection.append(<(key,value) tuple>)
>
> In certain cases you might actually need to do this for the super function
> which will actually proxy the super object.
>
> Having said that( for the exisitng modules), in future the design should be
> a bit more generic allowing multiple modules to hook values to the selection
> field.
>
> *If you can tolerate this: This has already been nicely implemented in
> Tryton*
>
>
> Reg. the way the inheritance is done, i think its high time the class
> factory is rewritten.
>
> Thanks,
>
>
> On Mon, Jun 28, 2010 at 12:52 AM, P. Christeas <xrg@xxxxxxxxx> wrote:
>
>> On Saturday 26 June 2010, Ferdinand Gassauer wrote:
>> > the following scenario creates problems
>> >
>> > module (A)
>> > (A): 'state': fields.selection([('draft','Draft'),('done','Done')],
>> > (B): 'state': fields.selection([('draft','Draft'),('running','Running'),
>> >                      ('done','Done')],
>> > (C): 'state': fields.selection([('draft','Draft'),('invalid','Invalid'),
>> >                      ('done','Done')],
>> > IMHO OpenERP should provide a solution to allow inheriting selection
>> >  fields.
>>
>> You are true. the B and C lines will just try to /replace/ the A line, so
>> at
>> the end you will only have one of B or C, depending on the module loading
>> order.
>>
>> In general, a solution would be to use a class variable for the selection
>> list, that would be appended with each extra state that some module wants
>> to
>> add to the selection. Or even use a function, that would dynamically make
>> up
>> the selection.
>> Note that I do NOT know the exact solution at the moment. But it is a
>> general
>> issue that I would like to improve on. You see, the OpenERP orm uses a
>> "simulated inheritance" concept, where classes do dynamically attach to
>> their
>> inherit parent and get their contents (columns, defaults, functions)
>> merged to
>> them. And that is a much different approach than inheritance in OO
>> languages,
>> like the one we were used to in C++.
>>
>> I will need to perform some tests and get back to you..
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-expert-framework
>> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-expert-framework
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> Sharoon Thomas
> Business Analyst & Open Source ERP Consultant
> CEO @ http://openlabs.co.in
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-framework
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>
>