Every time I have to install third-party modules in Odoo, I start praying for 12 hours in advance.

It is not uncommon, in fact, that the installation of some modules leads to the breaking of pre-existing views and, in the presence of already customized views, the risk becomes even greater.

The more view inheritance is nested, the more likely it is that a programmer in the world will die.

I'll list a series of simple rules to follow to avoid releasing code that could kill some installations and that doesn't make us bring on our conscience the lives of our colleagues distributed around the world.

Replace

Replace is like a bazooka. It destroys everything. That means if someone after us tries to find what we replaced, they'll never find it. It is not difficult to understand thatreplace should be used sparingly and that, if possible, it should not be used at all. It is rare that the only solution to our problem is to replace a node. It is much more elegant to hide it with due care and with much more elegance.

Add attributes

Let's imagine that we have a div, with its own class, to which we want to add a new one. What often happens is that we use the "replace" to replace the node with the same node to which we add our class. This is wrong for two reasons: the original node is no longer recognizable from the previousxpath and two modules that apply the same modification tend to obscure each other.

The best thing to do is to use the addition of value through the use of attributes.

Wrong:

<xpathexpr="//div[@id='node_id']"position="replace"><divid="node_id"class="row d-none"/></xpath>

Right:

<xpathexpr="//div[@id='node_id']"position="attributes"><attributename="class"separator=" "add="d-none"/></xpath>

You can use it to extend if condition in view, too.

Example:

<xpathexpr="//button[@id='o_payment_form_pay']"position="attributes"><attributename="t-if"separator=" "add="and accept_terms_conditions"/></xpath>

Hasclass

As we have seen previously, a node can be extended by adding a new class. This highlights another problem. Very often we refer to nodes by indicating their class.

Example:

<xpathexpr="//div[@class='myclass']"position="...">    ...</xpath>

If a module, before ours, adds a new class to the node we are looking for, we may never find it again. In this case, the solution is given by thehasclass function that allows us to control the nodes that have the class we are looking for among all those available.

Example:

<xpathexpr="//div[hasclass('myclass')]"position="...">    ...</xpath>

ID and Name abuse (Do it!)

When usingxpath, you always try to hook into a node that is uniquely recognizable throughout the entire XML structure. This is not always so easy because some nodes are very anonymous (they have too generic class, they are the same as other nodes in other places, they are repeated in the structure).

In this case, it is a good practice to use theid orname attribute on nodes that we believe can be hooked so as to facilitate the work of developers who will extend our views.

Do not obscure

When the starting structure is very complex and there are many changes to be made, there may be the temptation to obscure a view by creating a new one with the same XML ID. It is useless to explain how dangerous and harmful this practice is. The XML ID is the parameter used to inherit views and forms that come after yours would expect a structure that is actually completely disrupted.

If there are so many changes to make, you're probably not using the correct view and the best way is to create a new one and convince the software to use yours instead of the original one.

Variables, not hardcore

Whenever you need a value to perform operations (compare values, numbers of cycles for a loop, etc.) it would be convenient to use variables so that the behavior in the operations can be more easily modified.

Wrong:

<ul><tt-foreach="['a', 'b', 'c']"t-as="val"><li><spant-esc="val"/></li></t></ul>

Right:

<tt-set="vals_to_loop"t-value="['a', 'b', 'c']"/>
<ul>
<tt-foreach="vals_to_loop"t-as="val">
<li><spant-esc="val"/></li>
</t>
</ul>

Final considerations

Unfortunately, this list is only part of the good practice to keep in mind. No code is perfect, and in many cases, even Odoo's core code is not free from these problems.

I only hope that these rules can serve as a springboard for writing better code.

Support