openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hello,

I remember I even recently proposed such a patch in trunk, in
project_long_term and it was accepted. I did that because I was confused by
the current inconsistency that lead me to believe write should accept single
ids indeed. I even designed OOOR that way so far.
Now, yes I prefer consistency too, so if you state write should accept only
arrays of ids, let's clean that now.

Still, if we want to accept single ids there, wouldn't that be a bit less
ugly to do the id to [id] conversion right at the method dispatch place
inside webservice.py or something like that? May be hacky but at least would
avpoid to pollute every module with the same non factored copied/pasted
hack. What do you think?

NB: in general this is very bad when lack of consistency is so high that
even the most active users can't determine what the API/conventions are
supposed to be just reading the code (then think how noobs get lost; it also
means than instead of getting cleaner, the code base tend to become uglier
over the time which differentiate two class of software: those that live and
those that die) . Unfortunately, I've often been in such a situation with
OpenERP, for instance trying to determine if class names should be plural
or singular (both exist in the core classes); and yes it's very important,
in frameworks like Rails, because conventions are enforced, a large part of
the bloat can be abstracted away from the developer (unless he wants to),
letting people focus only on the relevant business logic (in this case field
declaration/ ORM API are much simpler). But inconsistencies samples extend
to method names, signatures, view names etc...


Raphaël Valyi
Founder and ERP Consultant
+55 21 3010 9965
http://www.akretion.com

<http://www.akretion.com.br/>



On Mon, Aug 9, 2010 at 4:56 AM, P. Christeas <xrg@xxxxxxxxx> wrote:

> On Monday 09 August 2010, you wrote:
> > I like being able to use a single id as a parameter for
> > write/read/browse..., it is more user (console) friendly, specially with
> > the browse.
> >
> > But it is true that it may cause mistakes, for example I have seen some
> > modules expecting the return for this methods to be a single element
> > (like the analytic account bug of two months ago, where only the first
> > account move to be confirmed got its analytic entries created).
>
> That one is a different problem!
> Currently, in the framework, it is only orm.read() that will return a
> different
> type of result if you call it with int(id) or list(ids) ..
> And browse(), of course, but that had been *designed* to work that way from
> the very start.
>
> If you are talking about other, custom methods, that is a responsibility of
> those who define them. If you need an analytic.calc_something(cr, uid,
> id|ids,
> ..), you should clearly define if you prefer an integer or a list there.
> And,
> please, have the same type of result.
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-framework
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>