On Saturday, March 12, 2011 9:58:11 AM UTC+1, Thomas Broyer wrote: > > > 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). >
Ok a cloned proxy would be a solution. But I still need a queue or something in case the real non-cloned proxy isn't saved yet but the next auto save occures. So in general RF forces me to wait for the response. But its ok.. as I have to wait anyways because of the entity version (either by waiting for the response or by increasing auto save intervals). And you are right, in case of constraint violations one should lock the form and the entity during save. But in our aggressive auto save strategy we would like to not lock the form and display any constraint violations in a non intrusive way. In most cases the user will correct these violations anyways because most violations will occur because of "unlucky" auto saves (e.g. data not completely and thus maybe incorrect edited be the user). > 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. > Uhh..so if I work on my private copy for 2 weeks and then unlock it to update the public copy, a second user can destroy my work by unlocking his copy a day later and thus overwriting my 2 weeks of work? :) Having working copies is a nice idea but merging them back into one public copy seems tricky. But of course it depends on the application. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
