openerp-expert-framework team mailing list archive

[Vo Minh Thu <vmt@xxxxxxxxxxx>]

On Thu, Sep 8, 2011 at 7:36 PM, Leonardo Santagada
<santagada@xxxxxxxxxxxx> wrote:
>
> 2011/9/5 Ovnicraft <ovnicraft@xxxxxxxxx>:
> > Hello i read about this maybe yo can consider a better python
> > lib https://github.com/lasarux/ooop
> > IMHO better than pypi registered.
>
> This one seems to have the best api of the bunch I saw posted here. I
> still think it has one problem, why the .get and .new? I think .new
> should be mapped to __call__ and maybe .get too. So instead of:
>
> o.ResPartner.new() and o.ResPartner.new(name='Guido', active=True)
>
> you get:
>
> o.ResPartner() and o.ResPartner(name='Guido', active=True)
>
>
> also it would be cool is any of this libs could be used inside an
> openerp module, so no more pool.get (which can we can easily map
> __get_attr__ to pool.get(captalization_to_points(attr))) and the ugly
> browse/search and the cr,uid everywere (whi a custom metaclass that
> decorate all methods with an OOP instance).

Hi,

Indeed one of our goal with designing a (high-level) client library is
to provide a consistent API server- and client-side. This is very
rough but Antony is thinking to head along the lines of this (also
very rough) experiment:

client-side: http://bazaar.launchpad.net/~openerp/openerp-client-rpc-com-lib/rows/view/head:/sample.py
server-side: http://bazaar.launchpad.net/~openerp-dev/openobject-server/trunk-rows-vmt/view/head:/rows

As I said this is very rough and we don't work much on this right now
but as designing an API should be quite fun for a lot of you, and as
we will use that new API for the years to come, getting an eye on it
early on should prove interesting.

Normally, we plan to get back to the community with a more
thought-out, and more carefully explained proposal after the 6.1 is
release (i.e. we hope to make a new API available in 6.2).

Cheers,
(On behalf of the R&D team)
Thu