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