← Back to team overview

openerp-expert-production team mailing list archive

Re: Open letter for Client API specification.

 

Eric,

I completely agree with you, however we've just received word from OpenERP
SA that they consider the GTK obsolete and will not upgrade the behaviour
on the GTK client to be identical to the Web client behaviour.

We're still in discussion with OpenERP for this issue so the final word has
not been said, but it's proving to be something they are not easily
accepting as a bug but rather consider it a feature.

Regards,
Niels

Op 19 april 2012 05:37 schreef Eric Caudal <eric.caudal@xxxxxxxxxxxxxx> het
volgende:

>  This will be completely refactored for 7.0: related calculated fields
> will pull from original field and not the other way round.
> Anyway both client should behave identically...
>
>
>   [image: openerp]
>
> *Eric CAUDAL*, CEOeric.caudal@xxxxxxxxxxxxxx
> Cell: + 86 186 2136 1670. Skype: elico.corp*Elico Corp - OpenERP Ready Partner, Shanghai.*http://www.openerp.net.cn
>
>
> On 04/19/2012 11:27 AM, Graeme Gellatly wrote:
>
> Interesting question.
>
>  I think a. is what most modules are expecting, and certainly before the
> web client existed this was the only expectation.
>
>  There is a danger with b of a circular loop.  Field a changes b, b
> changes c, c changes a etc etc.  The second issue with b is ugly expensive
> methods like product_id_change which is called in full or part by half at
> least 3 different SO line fields.  Just adds a lot of overhead, so if the
> case was b, then there would need to be safeguards in place against calling
> the same method multiple times unnecessarily (although I do note that this
> case already occurs in a in the GTK when you create a record)
> - definitely those methods would need rewriting (although noted that in
> fact many already have been in 6.1, possibly for that reason)
>
>  Broadening the issue slightly although still relevant to this discussion
> - what if the field is invisible, readonly, or outside a users security
> rights.  So are we talking user changes, or client changes.  I have no
> preference either way, but if b is to be the expectation then GTK must
> support, and it would be nice for there to be a way of telling what input
> that triggered the call.
>
> On Wed, Apr 18, 2012 at 11:25 PM, Niels Huylebroeck <nh@xxxxxxxxxx> wrote:
>
>> Hi all,
>>
>>  I'd like a moment of your time to consider some issues I've been
>> bumping into lately, the difference between the current clients available
>> for OpenERP.
>> Some of you might not have bumped into serious issues when you are coding
>> for either the web- or GTK client alone but there are actually quite a few
>> differences in the implementation of these clients.
>>
>>  I've just recently addressed one such difference with OpenERP SA and
>> would like to take this opportunity to show why exactly the community needs
>> a fixed API specification.
>>
>>  Here's a link to a video showing exactly how the client behavior
>> differs today in 6.1 series in a (although harmless) but decisively
>> different manner.
>> http://www.youtube.com/watch?v=bEGe_3HdXIc&hd=1
>>
>>  I've also isolated this problem with a small module which is available
>> for download here: (OpenERP 6.1 required)
>> http://ubuntuone.com/5UZxt8VF4XQOYmmjPBnXbH
>>
>>
>>  *The technical issue (in a nutshell) is this:*
>> Do we expect the client to call the on_change event for every field that
>> was changed?
>>  (a) by the user
>> (b) by the return value from another on_change function called
>>
>>  Currently in 6.1 the web-client does both (a) and (b) cases. The GTK
>> client however only does this for the (a) case.
>>
>>
>>  The point I'm trying to make here is that this behavior is currently
>> unspecified and not conclusively specified anywhere and is something we
>> should address as remote interaction with OpenERP will become an ever
>> increasing important part if OpenERP wishes to profile itself as a modern
>> day software component able to be extended and remotely controlled by one
>> uniform API.
>>
>>
>>  Hoping to start a productive discussion,
>> Niels Huylebroeck
>> Lead Architect   --   Agaplan
>> Web : http://www.agaplan.eu
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-expert-production
>> Post to     : openerp-expert-production@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-expert-production
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-production
> Post to     : openerp-expert-production@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-production
> More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-production
> Post to     : openerp-expert-production@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-production
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Niels Huylebroeck
Lead Architect   --   Agaplan
Tel. : +32 (0) 93 95 98 90
Web : http://www.agaplan.eu

References