gwt - RequestFactoryEditorDriver 在刷新后获取已编辑的数据

Question

让我从我有一个解决方案开始，但我并不认为它很优雅。所以，我正在寻找一种更清洁的方法来做到这一点。

我在 View 面板中显示了一个 EntityProxy。 View 面板是一个仅使用显示模式的 RequestFactoryEditorDriver。用户单击一个数据元素并打开一个弹出式编辑器来编辑 EntityProxy 的数据元素，其中的数据位比 View 面板中显示的要多一些。当用户保存元素时，我需要 View 面板来更新显示。

我遇到了一个问题，因为弹出编辑器流程的 RequestFactoryEditorDriver 不允许您访问已编辑的数据。驱动程序使用与您用于向服务器发送数据相同的传入上下文，但刷新后返回的上下文只允许 Receiver<Void>即使您将其转换为您在 edit() 调用中存储在编辑器驱动程序中的上下文类型。 [它似乎也没有发送和 EntityProxyChanged 事件，所以我无法监听并更新显示 View 。 -从头开始 - 我现在看到这个事件不适合这个用例]

我找到的解决方案是更改我的域对象持久化以返回新保存的实体。然后像这样创建弹出编辑器

editor.getSaveButtonClickHandler().addClickHandler(createSaveHandler(driver, editor));
                // initialize the Driver and edit the given text.
                driver.initialize(rf, editor);
                PlayerProfileCtx ctx = rf.playerProfile();
                ctx.persist().using(playerProfile).with(driver.getPaths())                      
                        .to(new Receiver<PlayerProfileProxy>(){
                    @Override
                    public void onSuccess(PlayerProfileProxy profile) {
                        editor.hide();
                        playerProfile = profile;
                        viewDriver.display(playerProfile);
                    }                               
                });
                driver.edit(playerProfile, ctx);
                editor.centerAndShow();

然后在保存处理程序中，我只是 fire() 我从flush() 获得的上下文。虽然这种方法有效，但似乎并不正确。 [看来我应该订阅显示 View 中的 entitychanged 事件并从那里更新实体和 View 。 - 再次划伤，与之前相同的原因] 此外，这种方法保存了完整的实体，而不仅仅是更改的位，这将增加带宽使用。

我认为应该发生的是，当您刷新实体时，它应该“乐观地”更新实体的 rf 托管版本并触发实体代理更改事件。只有在保存中出现问题时才恢复实体。实际保存应该只发送更改的位。通过这种方式，不需要重新获取整个实体并通过线路两次发送完整的数据。

有更好的解决方案吗？

Answer 1

您似乎并没有真正了解 RF 的详细情况；另外，您的术语并不能真正帮助理解(冲洗与火)。

RF 中的代理是您检索它时服务器状态的快照。您可以对应用程序中其他地方的实体执行任何您想要的操作(通过其他代理)，您的代理永远不会更改以反射(reflect)这些修改。

当服务器检测到它已更改时，在客户端(对于服务器已知并已从客户端发送的实体)调度 EntityProxyChange 事件:要么是它的版本(由 getVersion 上的 Locator 返回) ) 已更改，或已被删除(如 isLive 的 Locator 方法所述)。如果您不使用 Locator ，它将使用实体的 getVersion 并且 isLive 将被替换为 find 实体的 ID(由其 getId 方法返回)并检查 null(这也是默认实现) isLive 中的 Locator )。
在您的情况下，如果您没有看到正在调度的 EntityProxyChange，请检查您是否正确更新了实体的版本。

最后，RF 总是将更改的差异发送到服务器(除了 ValueProxy ，在这种情况下差异没有意义)。至于检索数据，默认情况下它不会检索链接的代理，除非您使用 with 明确要求它们；这与您可能发送的有关实体的信息无关。

在您的情况下，要更新 View 面板，您有 3 种可能性:

从服务器检索代理(监听 EntityProxyChange 事件或在弹出窗口中的显式信号之后；您可以使用 find 的 RequestContext 方法，将代理的 stableId 作为参数，并为您需要的属性使用适当的 with)。
当您执行第二个 HTTP 请求时，它的效率有点低，但另一方面，它可以处理来自应用程序其他地方的更改(它们也会触发 EntityProxyChange 事件)

在与用于保存它的 HTTP 请求相同的 HTTP 请求中检索更新的代理:让请求上下文的 save 方法返回保存的实体，或在同一请求上下文中调用 find 方法以将 save 和 find 一起批处理相同的 HTTP 请求。
这就是你所做的。它发送更改的差异并检索 View 面板所需的属性。可以说它具有将弹出窗口和 View 面板紧密耦合的缺点，由您决定是否可以接受权衡。

使用您在 View 面板中编辑并发送到服务器的实体，没有额外的数据通过线路。
虽然这看起来更简单，但您会错过其他用户可能对实体进行的任何更改(只有服务器知道的更改)。

总而言之，我想我会采用当前的解决方案。不过，关于您的代码，我将使用代理和回调启动弹出窗口，并将请求上下文和编辑编辑器驱动程序保留为弹出窗口的实现细节:您只需要在完成后调用 View 面板，传递更新代理作为回调的参数。

关于术语的最后一句话:您刷新编辑器驱动程序以将字段的值复制回对象/代理，并且(独立地，但在您的情况下顺序)您触发请求上下文以发送一批服务方法和代理更改到服务器。刷新编辑器驱动程序不会向服务器发送任何内容，这些是不同的操作。