openerp-expert-framework team mailing list archive

[Xavier Morel <xmo@xxxxxxxxxxx>]

> It could be much harder than it originally sounds.
> Consider that most names don't just have one part, but dotted notation:
> self.pool.get('account.invoice')
> Then, we should create an intermediate 'account' object that would resolve the
> 'invoice' one. When it comes to the structuring of that dotted notation (does 
> 'invoice' belong to the 'account' module? ), things may get even more messy..

More than messy, it would be quite disgusting and — I think — pretty unpythonic (with magical objects appearing out of nowhere all over the place).

A better (in my opinion) way would be to see the possibility of migrating to using addons & classes as "real" python objects: instead of self.pool.get('account.invoice'), ``from account import invoice`` and get your invoice instances from there.

This would require quite a bit of change in the way things are instantiated and (especially) the way objects are named (see the account_account_template class in the account module in the account addon, which would lead to ``from account.account import account_account_template``, and I know there are much worse cases in the codebase…) but I believe it would make the code clearer, actually express dependencies between modules (letting everybody use standard python static-checking tools such as pychecker or IDEs correctly — on that front Jetbrains has just released the first EAP for PyCharm) and might even make easier (or at least possible) the introduction of ``unittest`` in the long run.

It would also make namespacing clearer e.g. just import "account" if you need many classes from there, and you can refer to them as account.whatever instead of having to self.pool.get each and every one of them.

--
Xavier Morel
Developper
OpenERP - Tiny SPRL
Chaussee de Namur, 40
B-1367 Gerompont
Tel: +32.81.81.37.00
Web: http://www.tiny.be
Web: http://www.openerp.com
Planet: http://www.openerp.com/planet/