openerp-expert-framework team mailing list archive

[Gustavo Adrian Marino <gamarino@xxxxxxxxx>]

The new strategy is on every on_change on a field you will send the full
GUI state to server.
I can imagine several use cases where that could be a good amount of
information. Let's say you are editing a stock.picking with 40 items, and
you have a field representing the sum of weights of the whole picking. In
any change on the product item (even non related) you are sending back to
server the whole bunch of picking info, plus items. It seems a big price to
pay in performance terms on medium speed connections.
Additionally, if you take in count the edition of the document (the input
of the full document, all picking fields plus all the fields in the items),
you will be sending the whole document info a lot of times per document. It
seems it is worth to investigate alternatives
I am still concerned with save and cancel buttons. Our current strategy is
not a transactional one neither a none transactional (half pregnant!). From
the point of view of the user, pressing some buttons (perhaps to get
auxiliary read only information) forces a write of the half backed record.
In a sense is "old fashioned".
I suggest another strategy.
Let's update the database on every field change. You will get a
continuously updated record (including the changes other people are doing
simoultaneously). Let's follow the path of Google Docs, and promote our
system as "simoultaneous editing capable".
It implies sending on every field change and focus change a message back to
server. The server should return any changed field and a timestamp. The GUI
should send the registered timestamp and the changed field if applies.
With this approach, the server could knows if any update conflict arises
(on simoultaneous change of fields - in fact since the timestamp) and it
can propagate changes from another users to your screen.
There is no longer the to "save" any record (like Google Docs). No
difference between on_change and actions. Constant delay - independant from
the size of the edited document, just one round trip of a most of the time
a very small message.
If well implemented on GUI (asynchronous response should not delay the
cursor movement on screen, you will see others people changes magicallly
apearing while you are editing, record update on fields focus change - no
poll or statefull server needed), it should revamp our interface and be
differential against other products.
>From the point of view of server modules, it seems it does affect the
proposed API. In fact, you should not have to consider different states,
like while editing the details of a sale.order, no id is still present.
Every time, everything is on db, updated with valid references. You should
not have to think different while you are in an onchange or an action.
Everything is regular and stateless.
I will appreciate your comments
Regards

El 24 de abril de 2012 04:21, Vo Minh Thu <vmt@xxxxxxxxxxx> escribió:

> On Mon, Apr 23, 2012 at 11:02 PM, Gustavo Adrian Marino
> <gamarino@xxxxxxxxx> wrote:
> > Let me share my understanding on the new API
>
> Seems good to me, excpet a key point.
>
> > Even it is not explicit in the description, it seems that the new API is
> > holding on the server the temporary state of the records during an edit
> > session, something it use to be done on the GUI til v6.1. If I am not
> wrong
> > that means the approach will hold the state of the tree of accessed and
> > modified objects, which is the only way to provide the required
> parameters
> > to the new on change methods.
>
> Yes, but not as much as you describe below.
>
> > The approach is intelligent, provided it is not adding artificial roud
> trips
> > to the GUI. What I mean is that on fields_view_get, it should be
> computed if
> > the control should be passed back to the server when a GUI field is
> changed
> > (taking into account if any other field is depending on the value of the
> > field). Once the GUI detect that condition, it should ask the server for
> the
> > new field values.
> > In order to construct an answer, the server should call all affected
> fields
> > (recursivelly if it is necesary, taking into account loops), and send
> back
> > to the GUI all changed values.
>
> Yes.
>
> > If I am not guessing too much, that means the session status is going to
> be
> > cached on server as long the user is editing an object (and all related
> and
> > the corresponding relations).
>
> No. There is no need to keep an edited record on the server. The
> client can send everything: unmodified and modified fields. Right now
> the client sends only the parameters excplicitely mentioned in the
> on_change. Instead in the future it will send everything. The payload
> is thus increased but the number of round-trip is reduced as all
> cascading on_changes will be applied at once.
>
> > This raise some interesting questions:
> >
> > The GUI still have the need to cache all affected values,
> > I see an opportunity to fully implement a transaction like behaviour.
> Today
> > when you click on a button, all the temporary state is dumped to DB. This
> > causes a difficult situation for the user because he has not press the
> save
> > button and the info is already on DB!. It is completely counterintuitive.
> > With the new strategy it is possible to fully delay the DB update
> operation
> > till the user has explicitely press the save button. Is that feature
> > foreseen?
>
> No. We don't want to have a transactional behavior across the network.
>
> > Once the whole thing is maintened on server, is it not possible to
> provide a
> > mobile read and update interface with a reasonable effort?
> > Be carefull not to be tempted to go back in the road a full stateless
> > server. Please do not relay on server process to server process
> > communication to resynch the temporary state (as some messages in the
> expert
> > threads suggest). Today for medium to big implementations a redundant on
> > line server is a requirement for big customers. Please use any strategy
> to
> > keep the servers independent from each other (synch through database or
> > whatever), but do not give up on the target to achieve full
> "statelessness"
> > It seems a good opportunity to fully get rid of the limitation on read
> only
> > fields, that could not be updated programmatically or on default_get,
> and at
> > the same time prevent the user to modify them
>
> We still want to keep the server as stateless as possible.
>
> Cheers,
> Thu
>
> > I hope I am not guessing too much!
> >
> > Best regards
> >
> >
> >
> > El 17 de abril de 2012 08:46, Olivier Dony <odo@xxxxxxxxxxx> escribió:
> >
> >> On 04/16/2012 02:13 PM, Alexandre Fayolle wrote:
> >> > Hello Olivier
> >> >
> >> > Since you answered off-list, I'll do the same, but feel free to
> forward
> >> > my message to the mailing list if you feel it belongs there.
> >>
> >> My bad, my answer was meant for the list, sorry about that!
> >> Hope the quoted answer will be readable enough for anyone interested,
> >> otherwise
> >> I'll forward the original answer.
> >>
> >>
> >> > On lun. 16 avril 2012 13:03:59 CEST, Olivier Dony wrote:
> >> >> On 04/16/2012 11:26 AM, Alexandre Fayolle wrote:
> >> >>> Another point which should be clarified if the
> record_set.method(args)
> >> >>> is implemented is the behaviour wrt exceptions. The behaviour of
> >> >>> method(args) raising an exception for one of the ids of the
> recordset
> >> >>> should be well defined, which seems a bit awkward :
> >> >>
> >> >> It must be very clear for the developer indeed, but there is perhaps
> >> >> not much
> >> >> to invent here, the semantics are already quite established I think.
> >> >
> >> > I'm sorry I'm such a newbie openerp-wise. The slides made absolutely
> no
> >> > mention of exception handling, and this is one of the points which
> >> > deserve a note in the API specification, imo. I'll study more the
> >> > existing behaviour. Also if the explicit looping is still available,
> >> > then of course it is not necessary to add complexity to the vectorized
> >> > API.
> >>
> >> You're right, this is something that was overlooked in the slides
> because
> >> we
> >> did not foresee any major change in it, but it is definitely an
> important
> >> API
> >> concept to mention in the specs.
> >>
> >>
> >> >>> * the API must clearly state whether it will try to call the method
> on
> >> >>> remaining records after a call on a record has failed with an
> >> >>> exception
> >> >>> or not
> >> >>
> >> >> This has always been quite clear (I hope!): everything is happening
> >> >> within a
> >> >> transaction and the transaction is aborted and rolled back
> immediately
> >> >> as a
> >> >> whole. It is vital for an ERP framework to guarantee the proper
> >> >> fail-fast
> >> >> handling of transactions everywhere... even when developers wish it
> was
> >> >> working
> >> >> otherwise ;-)
> >> >
> >> > That's fine when the method is doing pure in-DB transactional stuff,
> >> > but can get awkward when the status is mixed (such as with method both
> >> > affecting DB state and the outside world)
> >>
> >> Certainly, when you're mixing transactions with non-transactional things
> >> (e.g.
> >> emails) you need to decide how you want to maintain transactional
> >> consistency
> >> and data integrity. This is probably more of a case-by-case choice,
> >> though.
> >> Common approaches could be to postpone the external calls to the last
> step
> >> of
> >> the transaction (when the rest is validated and ready to commit), or
> wrap
> >> it in
> >> a transactional layer (like our email queue), etc.
> >>
> >>
> >> >> Practically speaking, if your business code needs to call a method
> on a
> >> >> record_set, it should either:
> >> >> - call it on the whole record_set and let any error propagate
> upstream
> >> >> untouched - presumably something unexpected happened and the original
> >> >> caller
> >> >> needs to be notified
> >> >> - or switch to a `for` + `try/except` approach in order to handle
> >> >> *expected*
> >> >> downstream errors record-per-record (being careful to let
> *unexpected*
> >> >> errors
> >> >> propagate)
> >> >>
> >> >> In both cases the semantics seem simple, clear and consistent, don't
> >> >> they?
> >> >
> >> > Once the exception handling strategy is clearly worded, yes :-)
> >> >
> >> > --
> >> > Alexandre Fayolle
> >> > Chef de Projet
> >> > Tel : + 33 (0)4 79 26 57 92
> >> >
> >> > Camptocamp France SAS
> >> > Savoie Technolac, BP 352
> >> > 73377 Le Bourget du Lac Cedex
> >> > http://www.camptocamp.com
> >> >
> >>
> >>
> >> _______________________________________________
> >> 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
> >
> >
> >
> >
> > --
> >
> > Gustavo Adrian Marino
> >
> > Mobile: +54 911 5498 2515
> >
> > Email: gamarino@xxxxxxxxx
> >
> > Skype: gustavo.adrian.marino
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
> >
>



-- 

Gustavo Adrian Marino

Mobile: +54 911 5498 2515

Email: gamarino@xxxxxxxxx

Skype: gustavo.adrian.marino