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

查看:15
本文介绍了RequestFactoryEditorDriver 在刷新后获取已编辑的数据的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

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.

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

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.

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

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

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

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.

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

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.

有更好的解决方案吗?

推荐答案

我找到了更好的解决方案.我在调用 RequestFactoryEditorDriver edit() 之前使代理可编辑,并将可编辑代理保存为我的视图代理.

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

另外,(我以为我以前试过这个,但它没有用,但我一定是做错了什么)我可以投射从同花顺返回的上下文.它与我使用 edit() 调用发送给驱动程序的上下文相同,因此它是安全的.

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

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

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.

所以现在我在视图中已经有了来自驱动程序的数据并且不必依赖于从服务器发回它.但我确实注册了 EntityProxyChange 事件,因此我可以检测并重新获取服务器是否存在冲突.

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆