openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

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