On Friday, March 11, 2011 10:37:10 PM UTC+1, Jens wrote: > > On Friday, March 11, 2011 3:50:35 PM UTC+1, Thomas Broyer wrote: > >> >> 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? >
The question is "what would you do of other changes made by the user in the mean time?" Because the proxies are locked, you cannot flush() the driver. And because you cannot edit() a given proxy twice at the same time, you cannot do a "flush().fire() + edit()". But thinking a bit more about it, there might be a solution: instead of edit()ing the proxy, you'd create a copy of it that you give to the editor driver. Then you periodically flush() the driver, but never fire() its context. After the flush(), you copy the proxy values into the proxy you'll send to the server. The problem is: how to clone the proxy? See http://code.google.com/p/google-web-toolkit/issues/detail?id=5794 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. > The reason RF locks the proxy until the response is received is that it will unlock them in case of constraint violations (so you could correct your proxies and fire the same RequestContext again). 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 :) > It's even better than that ;-) The user has to click a "lock" button to be able to edit the objects (creates a working copy). The form then switches to read/write mode and the "save" button appears. But the save button only saves changes to the working copy; there's a distinct "unlock" button that overwrites the "public copy" with the "working copy" (and another "free" button to "unlock" the "public copy" and simply discards the "working copy"). A user can keep his working copy for days, or even weeks or months. -- 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.
