Hello guys
The great news is we are starting to see substantial changes now that the fund raising is over, with OpenERP S.A. now kicking great refactoring into 5.2 (notice that it was hard to predict since that was not announced much earlier, specially when 5.2 was originally targeting December-February; we even double worked upon a part of it, but that's okay as at least change is coming). One of the great news is that the fact old wizard style are not extensible (except hugly monkey patching) is being addressed. I would like to reply here to a Fabien comment upon our blueprint, and I think it's better to share it here, letting eventually you guys comment on it, here is our exchange: Fabien Pinckaers March 05: Just a note to say we are working on this blueprint [ https://blueprints.launchpad.net/openobject-addons/+spec/code-refactor-for-better-extensibility ] within the next two weeks. Also, old-style wizards are a problem too: they can not be extended at all and have to be copied/pasted if their behavior has to change in an addon. They are also harder to write unit tests against. Raphaël Valyi March 05: Fabien, this is a great news. Now, I worked on this last week, and I should say, I should correct a few of things in the above list as a few of the issues here are wrong. But most of them hold true. The good news however, is that I think I fixed half of the real ones in those two merge proposals I sent: https://code.launchpad.net/~akretion-team/openobject-addons/extensible-inventory/+merge/20293 https://code.launchpad.net/~rvalyi/openobject-addons/extensible-mrp/+merge/20294 and that one that has been merged already: https://code.launchpad.net/~akretion-team/openobject-addons/5.2-refactor-methods-splits/+merge/19842 As for the old wizards: I made that blueprint: https://blueprints.launchpad.net/openobject-addons/+spec/refactor-old-wizards-on-osv-memory I agree that it's harder to test them indeed. Still, I recall that OERPScenario is perfect to test them. Now I see OpenERP SA already did a large part of that refactoring ( https://code.launchpad.net/~openerp-commiter/openobject-addons/osv-memory-wizards ) which is cool (except we double worked on a part of it because that was not communicated in advance). Now let me make a point: I think there is no need to refactor all of them in the middle term. Indeed, I think you never need to override 80% of those wizards in real projects. And I think there is nothing wrong either if you are the only bad lucky one earth that need to copy/paste/change 20 lines of old wizard style code. Now, there are a few wizards you often need to customize indeed. I have listed our top list on the wizard blueprint page (that list can be completed). So here is the point: I think this is risky (and also useless for now) to try to refactor them all and merge them BEFORE having a very large test suite. We are yet to report it, but the only wizard we refactored too, when we looked at the code OpenERP S.A refactored in parallel, we think we just found a regression where the invoice on picking wizard would not work when invoicing several invoices. I mean this is tested nowhere and would be a hugly regression, if this were to happen in many wizards, I suggest we rather refactor only the main ones: those larges, with screens and often used, and rather spend time testing that's the refactoring is correct rather than refactoring all the other ones. Then we would finish the job in a next OpenERP version, once we have an extensive test suite. I would appreciate you take a stance upon that. Raphaël Valyi http://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
