openerp-brazil-team team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

---------- Forwarded message ----------
From: Raphaël Valyi <rvalyi@xxxxxxxxxxxx>
Date: 2011/9/26
Subject: toward a cleaner addons API... merge proposal...
To: Openerp Expert Framework <openerp-expert-framework@xxxxxxxxxxxxxxxxxxx>
Cc: Olivier Dony <odo@xxxxxxxxxxx>, vmt@xxxxxxxxxxx, Antony Lesuisse <
al@xxxxxxxxxxx>, Fabien Pinckaers <fp@xxxxxxxxxxx>, Fabrice Henrion <
fhe@xxxxxxxxxxx>, Raphael Valyi <rvalyi@xxxxxxxxx>, all@xxxxxxxxxxxx


Dear framework experts,

like many others real life OpenERP integrators, at Akretion our average
OpenERP is with around 15 extra addons overriding natural behavior to bring
value added features or localization.
So it's extremely important the normal addons modules can be overrided in a
decent way.
Otherwise, features are not competitive to create, modules are not
compatible between them (it's very serious, in Brazil module creating a
purchase/sale/invoice order line or picking should be overriden with a
localization module at this stage, imagine how hard it is for the new
comers, many non trivial localizations are in the same situation...).
An other consequence is that the overall SQL activity is inefficient, no
matter how perfect the server layer is going to be.

Let's take a concrete example: the sale module and the action_ship_create
method that generate the shipments and the procurements.
Today it's a massive single bloc of code and customization can only happen
once the method has been executed (or before but then there is no reuse and
compatibility at all). That means that we should re-search the created
items, re-browse them. And depending how we change them later, other modules
doing that are probably not compatible.

*Instead, I propose to apply 2 general principles:*
*1) any method creating some important
business object  (specially something localizable) should give a chance to a
potential module overrider to customize it BEFORE hitting the database with
the create method. That creation method should provide all the creation
context (like the order, the product line for a shipment creation) so the
overrider can take that into account.*
*
*
*2) when there is a what I would call a "cardinalitity mismatch", that is
stock move lines belong to less (often 1) picking, account move lines belong
to 1 move... Then there should be a key lookup in a hash to know if the
container object can be reused or need a new instance instead. The
generation of hat key should be overridable in modules.*


*I proposed a little piece of such work that is waiting for a merge, please
comment on here:*
https://code.launchpad.net/~akretion-team/openobject-addons/addons-sale-extensible-action-ship-create/+merge/76609


In the future, that behavior could even be abstracted away in some
declarative and customization fashion. However, let me warn against that. I
suggest to do that in a declarative style only if perfect, else it's much
worse than python code. Take the server actions for instance or the methods
attached to workflow nodes. It's declarative but very little used (python
methods are instead) because it was far from perfect).

And again, *let me advocate for a working solution right now for 6.1*.
Change can be manage over the time. This has never been done with OpenERP,
but things can be deprecated 6 months in advance as other framework do. We
need a solution to increase OpenERP adoption. Taking a concrete example,
today in Brazil, considering that kind of catches less than 5 people are
able to put OpenERP to work. This is not an ideal solution, neither for us,
neither for OpenERP SA..
So I kindly request an evalution of this merge. If modules start using that
modular API instead of hugly mono-bloc overrides, at least in the future
they will have made a step toward a declarative refactoring, so this is not
a loss, this is a win. I insist this refactoring is totally backward
compatible and breaks no API, I was just warning here against the perfect
being the enemy of the good that too often lead to inaction. The world is
not perfect, third parties contributions have limited resources and still we
should converge toward a better solution.


If this merge is accepted, then count on us to provide other such little
life saver refactorings. This is no surprise that we have a divergence on
the relicense, well I propose to let this aside for now as we need a decent
6.1 release for the benefit of everybody. You will later be able to claim
that those merges are under the dual license, at least now the dual license
is known.


Waiting for the merge evaluation.
(BTW we and many Brazilian partners and users are also waiting for a merge
of l10n_br with correct chart of account more than 4 months now).



-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com