Convention for the method name of new API onchanges

[oca]

Convention for the method name of new API onchanges

[rvalyi]

will do the trick. At first I thought changing these onchange name for standardizing was really invasive. But then I thought at least we don't need to have them in the XML of the views anymore so that wouldn't require lot's of database update right? Only restart, correct? If so seems acceptable.

But still this looks like a basic limitation of the ORM is making us deal with hundreds of side effects in all the modules... I tend to think the ORM would better be fixed at all cost then, for me even if it was only in OCB as I don't really care anymore what SA does or not on its own suicide branch...

[moylop260]

@pedrobaeza
Thanks for information.

Do you have a issue in odoo/odoo for this case?

We can justify this guideline with the answer of issue.

[pedrobaeza]

I don't put any issue to Odoo because it cannot be considered like that, but a feature. I ping Raphael Collet for having his opinion in this issue instead of splitting the debate across multiple issues.

[rco-odoo]

The convention you propose looks perfectly fine to me.

The other proposal (normalize on onchange_<field_name> and make the ORM collect them all) looks bug prone and breaks Python conventions. It makes the ORM reinterpret method overriding. What if you actually want to override an existing onchange method?

@pedrobaeza 's convention could be summarized as:

• to add an onchange method on field, define a method onchange_field_module decorated with @onchange; the naming convention avoids accidental name clashes
• to modify an existing onchange method, override it like any Python method

[pedrobaeza]

Thanks for the answer, Raphael. Yeah, it makes totally sense to respect Python overriding convention. I'll make the PR with the convention.