Декодирование полезной нагрузки GWT RequestFactory без запроса из внешнего сообщения - PullRequest
Новая
       42

Декодирование полезной нагрузки GWT RequestFactory без запроса из внешнего сообщения

2 голосов
/ 10 января 2012

Мы используем GWT Atmosphere для отправки строк с сервера на клиент, и это работает довольно хорошо.

Однако мы хотели бы отправить целые объекты с сервера на клиент, сериализованные GWT RequestFactory. Без необходимости запроса со стороны клиента!

Итак, я попытался работать с SimpleRequestProcessor#createOobMessage(domainObject) и отправить эту полезную нагрузку клиенту. Вычисление полезной нагрузки работает.

Затем я декодировал бы это сообщение, используя AutoBeanCodex#decode, и считывал domainObject как правильный EntityProxy из списка вызовов ResponseMessage - однако, когда я это делаю, требуется, чтобы какой-то serverId был установить для продолжения в AbstractRequestFactory#getId (вокруг строки 260: assert serverId != null : "serverId")

Какой-нибудь совет, как я могу декодировать полезную нагрузку Proxy без запроса от клиента?

Обновление

Вариант использования этого вопроса - чатоподобное общение. Клиент не запрашивает сообщения с сервера, а получает уведомление о новых сообщениях. И мы хотели бы включить сообщения и информацию о том, кто отправил сообщение в полезную нагрузку уведомления. Так как в любом случае мы используем RequestFactory в нашем проекте, мы хотим воспользоваться преимуществами настройки всей проводки Proxy и теперь просто передать соответствующий граф объектов на клиент.

1 Ответ

1 голос
/ 10 января 2012

Почему вы пытаетесь сериализовать РЧ-сообщения и отправлять их как сущности? RequestFactory - это гораздо больше, чем просто способ отправки данных по сети - в нем есть как минимум три разных типа сообщений, которые можно отправлять с клиента на сервер: создавать экземпляры, устанавливать вызовы и вызывать методы обслуживания. В зависимости от того, что происходит на сервере, клиенту могут быть возвращены не только данные, но и сообщения о том, какие изменения были внесены, и если эти установщики внесли изменения, которые недопустимы в соответствии с правилами JSR303.

Вы пытаетесь использовать более простой интерфейс для описания, отправки и получения сущностей? Или вы действительно хотите, чтобы RF-соединение проводилось как на клиенте, так и на сервере, чтобы вы могли выполнять пакетные запросы, обращаться к экземплярам EntityProxyId и получать от клиента только отправку различий?

Если вам просто нужны более простые объявления объектов, попробуйте просто использовать AutoBean s и AutoBeadCodex, которые вы уже рассмотрели - вы сможете легко создавать и маршалировать экземпляры как на клиенте, так и на сервере, и вы можете передавать они как струны по транспортам атмосферы.

Если вы действительно хотите RequestFactory, но работаете с чем-то другим, кроме AJAX, есть другие варианты. Вместо того, чтобы отправлять / получать строки через Atmosphere (который, как я считаю, предназначен для обеспечения push-поддержки вызовов RPC), рассмотрите возможность использования этого базового push-уровня для реализации нового транспорта запросов в RequestFactory.

com.google.web.bindery.requestfactory.shared.RequestTransport может быть реализовано (см. com.google.web.bindery.requestfactory.gwt.client.DefaultRequestTransport для версии AJAX по умолчанию), чтобы использовать любой механизм связи, который вы хотели бы - и для построения сервера, посмотрите на com.google.web.bindery.requestfactory.server.RequestFactoryServlet, что на самом деле нужно сделать, чтобы подтолкнуть сообщения через локатор, ServiceLocators и т. д.

Если вы действительно хотите использовать Atmosphere и RF, подумайте о создании RequestTransport, который обернет простой интерфейс Atmosphere для вызова на сервер со строкой - вызовы cometd / websocket уже позаботятся о вас, и вам просто нужно будет перевести строковое сообщение в вызовы (снова посмотрите, как это делает RequestFactoryServlet).

...