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
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
