JS-client exposedmodel updates get lost

[cdyk]

I think the problem is as follow:

When a GUI widget is invoked, both the widget handler as well as the viewlet might trigger an exposedModelUpdate request. In this case, the viewlet might fire off the updateRequest, and before this request returns with an update, the exposedmodel is updated from the GUI. But then, before the listener on that element get a chance to send a new updateRequest, the viewlet´s request return a response, without that update. And when this response is processed, the user´s action is overwritten. After this, the updateRequest of the user´s action carries on, but without the user´s update. The net result is that the job seems to disagree with the user, changing values back every once in a while when the user is interacting.

I think one solution is to make sure that when the user modifies the exposedmodel, never let a server response change this value until the user´s latest value has been sent to the server. Thus, if the user manages to update that value multiple times before a request is sent, the latest update is used and all previous updates are discarded. This is better than discarding fresher updates.

This could be implemented as follows, in the client JS-code:

• Maintain the set of exposedmodel keys which values has been modified by the user since the last updateRequest was sent. This set will usually contain few elements, unless the user is trashing the GUI. I think some form of hash-map might be appropriate.
• When an exposedmodel value is updated from the GUI, immediately after the update, make sure that the key is in the not-sent-set, before yielding execution control in any way. Then fire off listeners that do updates.
• When sending an updateRequest, only send updates for the values that is in the not-sent-set. When the request has been built, but before it is sent (and execution control is yielded), clear the not-sent-set.
• When processing an exposedModelUpdate from the server, for each key, check if the key is in the not-sent-list. If so, discard that particular part of the update from the server. Another update for that key, with fresh data, will come in the next round.