On Friday, March 11, 2011 3:50:35 PM UTC+1, Thomas Broyer wrote: Maybe you should delay autosave requests to until the previous one has > returned? >
Well.. maybe. Just keep in mind that we do not have a dedicated save button (thats why we do auto save that often) so we are forced to execute every autosave request as soon as possible in order to avoid data loss. But maybe we try it to see how many auto save requests will be queued when simulating a bad network connection. The more items we have in that queue the more data will be lost if the browser gets closed or someone else changes the same data and an optimistic lock exception forces the application to reload the data and clear the auto save queue. > >> How would RequestFactory handle such a situation? What happens if you call >> xxxRequest.persist().using(object).fire() twice without having received a >> result during both calls (what could happen if we integrate RF instead of a >> command pattern)? >> > > Well, first, you can only edit() a proxy once at a time (i.e. in a single > RequestContext). Second, when you fire() a RequestContext, the edit()ed > proxies are locked until the response comes back. > This basically means that if you have to lock the form while you autosave > it. > I'd suggest you file an enhancement request so you could, e.g. flush the > editor to a different object/proxy than was passed to initialize it. That > way, you could display() the proxy (so it's not edit()ed), and then flush > into an edit()ed version. You'd still have to block until the response come > before doing another autosave; and worse, before doing a save(), which means > the user would have to wait for the autosave to finish before it can > explicitly save the form *and go away!* > Hmm why do I have to lock the form while auto save the data? Is it because I have to call edit() again after receiving the RF response in order to be able to call flush().fire() again? And calling edit() would overwrite any changes in the form the user could have made if I do not lock the form in the mean time? If so, wouldn't it be a better enhancement to somehow allow multiple flush().fire() calls (of course not parallel calls) after a single edit() call has been made to initially populate the editors? I've read that the editor framework uses flow synchronization. So on each flush every editor value is just copied into the proxy instance and then the RequestContext is fired. Shouldn't be that difficult for RF/RFED to recognize that the response has been received and then implicitly set the locked flag of the proxy back to false. If we then call flush().fire() again the new editor values will be copied to the proxy and saved again...and so on. Maybe its possible to expose this enhancement as a method. Something like RFED.startAutoSave(int intervallInMillis, RequestContext ctx, RFEDCallback callback) where RFEDCallback contains onSuccess/onFailure/onValidationError (along with RFED.stopAutoSave()). intervallInMillis would be an approximate<http://www.dict.cc/englisch-deutsch/approximate.html> value <http://www.dict.cc/englisch-deutsch/value.html> because of an autosave request that takes longer to complete than intervallInMillis. Internally RFED would call edit() once and then start a timer that does flush().fire() and reschedules itself once fire() completes. Would be a nice RFED feature. > Entity versions are sent to/from the client along with the ID. It's a > serialized and encoded version though, because a version can be any kind of > object (RequestFactory does a toString() on it, and then base64-encode it). > RequestFactory would have to either: find() with the ID and version (in > String form) and let you "parse" the version back into you object type (but > that would lock RF into always transforming the version to a String), or > find() the entity as today and then ask for its version, serialize it and > compare with the version sent by the client (same comparison as is done > before returning objects to the client, to "generate" the appropriate > EntityProxyChange events on the client). > Ah ok, so each proxy instance holds its serialized version in a field somewhere in the generated autobean and just don't expose it so the developer do not have to bother with it? If so then its basically the same what we do and I guess thats the reason why RF locks the proxy until the response is received. That way RF avoids the issue we currently have by design. > >> How do you do optimistic checking in your application and how do you have >> solved this issue? >> > > We don't actually; but we're in a special case that users first have to > explicitly lock an object (actually, create a private working copy) before > they can edit it; so a given user can only be in conflict with "himself"; > and using the application in multiple tabs/windows is an officially > unsupported use case (yes, we're lucky ;-) ). > Yeah really lucky. Having a separate edit/cancel/save button where edit also means "lock that object until save or cancel is called" is always a nice luxury :) But we also thought about locking the object. We could implicitly do it on the first auto save and then unlock it a couple of minutes later if no further auto save request occurs in that time. When its locked everyone else would see a disabled form and the app would check the lock with a timer so it can enable the form once the object is unlocked again. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
