刷新后，RequestFactoryEditorDriver获取编辑的数据 [英] RequestFactoryEditorDriver getting edited data after flush

问题描述

让我从我有一个解决方案开始，但我不认为它是优雅的。所以，我正在寻找更干净的方式来做到这一点。

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

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

我发现的解决方案是改变我的域对象，保存的实体。然后像这样创建弹出式编辑器。
$ b $ pre $ editor.getSaveButtonClickHandler（）。addClickHandler（createSaveHandler（driver，editor））;
//初始化驱动程序并编辑给定的文本。
driver.initialize（rf，editor）;
PlayerProfileCtx ctx = rf.playerProfile（）; （新的接收器< PlayerProfileProxy>（）{
@Override
public void
.to（new Receiver< PlayerProfileProxy> onSuccess（PlayerProfileProxy配置文件）{
editor.hide（）;
playerProfile = profile;
viewDriver.display（playerProfile）;
}
}）;
driver.edit（playerProfile，ctx）;
editor.centerAndShow（）;


然后在保存处理程序中，我只是激发（）我从flush（）获得的上下文。虽然这种方法有效，但看起来并不正确。 [看起来我应该在显示视图中订阅entitychanged事件并从那里更新实体和视图。 - 再次从头开始，与以前相同的原因]此外，这种方法可以保存完整的实体，而不仅仅是改变的位，这将增加带宽使用。

什么我认为应该发生，当你刷新实体时，它应该乐观地更新实体的射频管理版本并激发实体代理更改的事件。只有在保存中出现问题时才能恢复实体。实际的保存应该只发送更改的位。以这种方式，不需要重新提取整个实体并通过电线两次发送完整的数据。

有没有更好的解决方案？

解决方案

解。在调用RequestFactoryEditorDriver edit（）并将可编辑代理保存为我的视图代理之前，我使代理可编辑。

  PlayerProfileCtx ctx = rf .playerProfile（）; 
 playerProfile = ctx.edit（playerProfile）; 
 driver.edit（playerProfile，ctx）; 
  

另外，（我以为我曾经尝试过这种方式，但它不起作用，但我必须拥有然后做了错误的事情）我可以投射从冲洗回来的上下文。这是我用 edit（）调用发送给驱动程序的上下文，因此它是安全的。

  PlayerProfileCtx ctx =（PlayerProfileCtx）driver.flush（）; 
  

这样做解决了rf使用fire（）发送整个对象的问题，而不仅仅是diff。我不知道为什么。这可能是RF编辑器驱动程序中的一个错误。

现在我已经从视图中获得了驱动程序的数据，并且不必依靠发送它从服务器。但我确实注册了EntityProxyChange事件，所以如果服务器发生冲突，我可以检测并重新获取。

Let me start with I have a solution, but I don't really think it is elegant. So, I am looking for a cleaner way to do this.

I have an EntityProxy displayed in a view panel. The view panel is a RequestFactoryEditorDriver only using display mode. The user clicks on a data element and opens a popup editor to edit a data element of the EntityProxy with a few more bits of data than is displayed in the view panel. When the user saves the element I need the view panel to update the display.

I ran into a problem because the RequestFactoryEditorDriver of the popup editor flow doesn't let you get to the edited data. The driver uses the same passed in context that you use to send data the server, Yet the context returned out of flush only allows a Receiver<Void> even if you cast it to the type of context you stored in the editor driver in the edit() call. [It doesn't appear to send and EntityProxyChanged event either, so I couldn't listen for that and update the display view. - scratch this - I see now this event is not for this use case]

The solution I found was to change my domain object persist to return the newly saved entity. Then create the popup editor like this

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();

Then in the save handler I just fire() the context I get from the flush(). While this approach works, it doesn't seem right. [It would seem I should subscribe to the entitychanged event in the display view and update the entity and the view from there. - once again scratch, same reason as before ] Also this approach saves the complete entity, not just the changed bits, which will increase bandwidth usage.

What I would think should happen, is when you flush the entity it should 'optimistically' update the rf managed version of the entity and fire the entity proxy changed event. Only reverting the entity if something went wrong in the save. The actual save should only send the changed bits. In this way there isn't a need to refetch the whole entity and send that complete data over the wire twice.

Is there a better solution?

解决方案

I found a better solution. I make the proxy editable before calling the RequestFactoryEditorDriver edit() and save the editable proxy as my view proxy.

PlayerProfileCtx ctx = rf.playerProfile();
playerProfile = ctx.edit(playerProfile);
driver.edit(playerProfile, ctx);

Also, (and I thought I had tried this before and it didn't work but I must have done something wrong then) I can cast the context that comes back from the flush. It is the same context I sent to the driver with the edit() call so it is safe.

PlayerProfileCtx ctx  = (PlayerProfileCtx) driver.flush();

Doing this fixed the problem with rf sending the whole object with fire() and not just the diffs. I'm not sure why though. That might be a bug in the RF Editor Driver.

So now I have the data from the driver already in the view and don't have to depend on sending it back from the server. But I did register for EntityProxyChange events so I could detect and refetch if there was a conflict on the server.

这篇关于刷新后，RequestFactoryEditorDriver获取编辑的数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！