在没有来自出站消息的请求的情况下解码 GWT RequestFactory 有效负载
我们使用 GWT Atmosphere 将字符串从服务器发送到客户端，效果非常好。
但是，我们希望将整个实体从服务器发送到客户端，并由 GWT RequestFactory 序列化。无需客户提出要求！
因此，我尝试使用 SimpleRequestProcessor#createOobMessage(domainObject) 并将有效负载发送到客户端。计算有效负载有效。
然后，我将使用 AutoBeanCodex#decode 解码该消息，并从 ResponseMessage< 的调用列表中读取 domainObject 作为正确的 EntityProxy /code> - 但是，当我这样做时，需要设置某种 serverId 才能在 AbstractRequestFactory#getId 中继续（大约第 260 行： assert serverId != null : "serverId")
关于如何在客户端不发送请求的情况下解码代理有效负载有什么建议吗？
更新
该问题的用例是类似聊天的通信。客户端不会向服务器请求消息，而是会收到新消息通知。我们希望在通知负载中包含消息和消息发送者的信息。由于我们在项目中无论如何都使用 RequestFactory，因此我们希望利用已设置所有代理连接的优势，现在只需将相关对象图推送到客户端即可。
We're using GWT Atmosphere to send strings from the server to the client and it works quite well.
However, we would like to send whole entities from the server to the client, serialized by the GWT RequestFactory. Without the need for a request by the client!
So I tried working with SimpleRequestProcessor#createOobMessage(domainObject) and sending that payload to the client. Computing the payload works.
I would then decode that message using AutoBeanCodex#decode and read the domainObject as the correct EntityProxy from the invocation list of the ResponseMessage - however when I do so, it requires some sort of serverId being set to proceed in AbstractRequestFactory#getId (around line 260: assert serverId != null : "serverId")
Any advice on how I can decode a Proxy payload without a request being sent by the client?
Update
The use case for this question is chat-like communication. The client doesn't request the messages from the server but instead will be notified of new messages. And we'd like to include the messages and info on who's sent the message in the notification payload. Since we're using RequestFactory in our project anyway, we want to take advantage of having set up all the Proxy wiring and now simply push the relevant object graph to the client.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为什么要尝试序列化 RF 消息并将它们作为实体发送？ RequestFactory 不仅仅是一种通过线路发送数据的方式 - 它至少具有可以从客户端发送到服务器的三种不同类型的消息：创建实例、调用 setter 和调用服务方法。根据服务器上发生的情况，不仅可以将数据返回给客户端，还可以向客户端返回有关进行了哪些更改以及这些 setter 是否进行了在 JSR303 规则下无效的更改的消息。
您是否正在尝试一种更简单的接口方式来描述、发送和接收实体？或者您实际上希望客户端和服务器上都有 RF 接线，以便可以批量请求、引用 EntityProxyId 实例并让客户端仅发送差异？
如果您只想要更简单的对象声明，请尝试仅使用您已经看过的
AutoBean和AutoBeadCodex- 您将能够在客户端和客户端上创建和编组实例服务器很容易，并且您可以将它们作为字符串通过大气传输传递。如果您确实想要 RequestFactory，但运行 AJAX 以外的其他东西，还有其他选择。考虑使用底层推送层在 RequestFactory 中实现新的请求传输，而不是通过 Atmosphere 发送/接收字符串（我认为其目的是为 RPC 调用提供推送支持）。
可以实现
com.google.web.bindery.requestfactory.shared.RequestTransport（请参阅com.google.web.bindery.requestfactory.gwt.client.DefaultRequestTransport了解默认值AJAX 版本）使用您想要的任何通信机制 - 并构建服务器，请查看com.google.web.bindery.requestfactory.server.RequestFactoryServlet了解通过 Locator、ServiceLocators 等推送消息实际必须执行的操作。如果您确实想使用 Atmosphere 和 RF，请考虑构建一个
RequestTransport，它包装了一个简单的 Atmosphere 接口，用于使用字符串调用服务器 - cometd/websocket 调用已经为您处理好了，您只需必须将字符串消息转换为调用（再次查看 RequestFactoryServlet 是如何做到的）。Why are you trying to serialize RF messages and send them just as entities? RequestFactory is much more than justa way to send data over the wire - it has at least three different kinds of messages that can be sent from the client to the server: create instances, call setters, and invoke service methods. Based on what happens on the server, not only can data be returned to the client, but messages about what changes were made and if those setters made changes that are not valid under the JSR303 rules.
Are you trying for a simpler, interface way of describing, sending, and receiving entities? Or do you actually want the RF wiring on both client and server so you can batch requests, refer to EntityProxyId instances and have the client only send diffs?
If you just want simpler object declarations, try just using
AutoBeans and theAutoBeadCodexyou have already looked at - you'll be able to create and marshal instances on both client and server easily, and you can pass them as strings over atmosphere's transports.If you actually want RequestFactory, but running over something other than AJAX, there are other options. Rather than sending/receiving strings through Atmosphere (which I believe is intended to provide push support for RPC calls), consider using that underlying push layer to implment a new request transport in RequestFactory.
com.google.web.bindery.requestfactory.shared.RequestTransportcan be implemented (seecom.google.web.bindery.requestfactory.gwt.client.DefaultRequestTransportfor the default AJAX version) to use any communication mechanism you would like - and to build the server, take a look atcom.google.web.bindery.requestfactory.server.RequestFactoryServletfor what actually must be done to push messages through the Locator, ServiceLocators, etc.If you really want to use Atmosphere and RF, then consider building a
RequestTransportthat wraps a simple Atmosphere interface to call to the server with the string - the cometd/websocket calls will already be taken care of for you, and you'll just have to translate the string message into invocations (again, see how RequestFactoryServlet does it).