Re: [gwt-contrib] RequestFactory entity proxies can't be cloned
BobV
<matt.mo...@gmail.com> wrote:
> I'm attempting to switch to using RequestFactory instead of GWT-RPC and
> manually creating DTOs. It's been going pretty well, except I've hit one
> use-case that is just a brick wall.
>
> I have a panel that is an Editor<DocumentProxy> which uses a
> RequestFactoryEditorDriver to handle the editing. One of the properties of
> DocumentProxy is another proxy, which I want to edit in a dialog box that
> shows when a button is clicked in the panel. The dialog is another Editor.
>
> The problem is that anytime something changes in this dialog, I want to
> flush the editor, send the current values to the server for validation, and
> report any errors right away. This works fine, but the dialog box has a
> cancel button, which should revert any changes made in the dialog box.
>
> I was able to do this before by storing the original value when it's set,
> and editing a clone while in the dialog box. But entity proxies can't be
> usefully cloned in any way that I currently see, so I'm at a loss as to how
> to get this behavior.
It only makes sense to clone an (immutable) EntityProxy that's not
associated with a RequestContext. Cloning one associated with a
pending request would lead to contention about which proxy has the
canonical new values to send to the server.
The future-proof way:
The DocumentEditor can call the DetailEditor with the stableId() of
the entity to edit. The DetailEditor fires its own find() request to
retrieve a new EntityProxy to edit. If the DetailEditor commits a
change back to the server (causing the version number of the entity to
change), the DocumentEditor can use the EditorDelegate.subscribe() to
receive the notification that the DetailEditor made something change
on the server. In the future, RequestFactory will gain a way to cache
data locally, so the cost of the redundant call can be eliminated.
The slower, but no-request way:
Use the ProxySerializer available from the RequestFactory to clone
via client-local serialization. If the object that's being cloned has
a non-trivial reference graph, this could be somewhat slow.
The coloring-outside-the-lines way which will probably break in the future:
Use AutoBeanUtils.getAutoBean(someEntityProxy) to retrieve the
AutoBean controller for the FooProxy and call clone() on it. You'll
need to copy the
com.google.gwt.requestfactory.shared.impl.Constants.STABLE_ID tag from
the source bean to the cloned bean and call freeze() on the cloned
bean to prevent assertion failures. I don't recommend this approach
since it relies on the RequestFactory plumbing not changing in the
future.
--
Bob Vawter
Google Web Toolkit Team