GWT DefaultRequestTransport: когда и зачем расширять?

Я видел несколько фрагментов кода GWT, в которых разработчик расширил DefaultRequestTransport и придал ему индивидуальную функциональность. Один из таких примеров находится в этом вопросе SO относительно фильтров аутентификации/входа. Но кроме этого примера я видел еще несколько.

Мой вопрос: когда и зачем кому-то нужно расширять этот класс и переопределять его методы? (Другими словами, что делает этот класс, какие услуги выполняют его методы и зачем мне их настраивать?)

В этом примере метод createRequestCallback был переопределен. Согласно Javadocs по этому методу, его цель состоит в том, чтобы:

Создайте RequestCallback, который сопоставляет ответ HTTP с интерфейсом TransportReceiver.

Это все еще своего рода загадочное объяснение для меня. Может ли кто-нибудь дать мне непрофессиональное объяснение того, в каких сценариях было бы полезно расширить этот класс и переопределить 1+ его методов?


java callback subclass gwt requestfactory
person IAmYourFaja    schedule 03.12.2013    source источник

Ответы (2)


arrow_upward
2
arrow_downward

RequestFactory не зависит от конкретного «транспортного» механизма; он имеет дело с JSON-представлениями запросов и ответов, но способ их обмена и передачи выходит за рамки и откладывается до RequestTransport.

DefaultRequestTransport использует RequestBuilder для заданного (но настраиваемого) URL-адреса; поскольку он использует RequestBuilder, его можно использовать только в клиенте GWT (для компиляции в JavaScript). Также есть UrlRequestTransport, который использует java.net.HttpURLConnection и может использоваться на любом клиенте, работающем в JVM (сервер, выполняющий вызов другого сервера, приложение Android, настольное приложение Java и т. д.).

Теоретически (потому что я никогда не пробовал это и никогда не слышал, чтобы кто-то еще пробовал это), вы можете создать RequestTransport, который использует Comet или WebSockets, или любой другой транспорт, который вам нравится. Конечно, серверная часть тоже должна быть адаптирована (SimpleRequestProcessor можно легко повторно использовать за пределами RequestFactoryServlet; это похожее разделение задач).

Вернемся к DefaultRequestTransport: он использует RequestBuilder и предоставляет несколько хуков, которые вы можете переопределить, чтобы настроить его работу. Наиболее распространенным вариантом использования является перехват всех запросов на добавление некоторого заголовка запроса (например, учетных данных) и/или всех ответов для обработки определенных ответов HTTP перед декодированием ответа RequestFactory в формате JSON (например, перехват «неавторизованного» ответа, чтобы попросить пользователя войдите).
DefaultRequestTransport работает как адаптер между API RequestFactory и RequestBuilder, а createRequestCallback наполовину отвечает за адаптацию ответа.

person Thomas Broyer    schedule 03.12.2013

arrow_upward
1
arrow_downward

В показанном примере им необходимо расширить DefaultRequestTransport, чтобы проверить все ответы RF-сервера и перехватить статус 401 (SC_UNAUTHORIZED), что означает, что запрос был отклонен на стороне сервера, поскольку у пользователя нет действительного сеанса, а затем перенаправить пользователя на страница входа в приложение.

Я также использовал DefaultRequestTransport для изменения requestUrl (по умолчанию установлено значение gwtRequest), поэтому я могу устанавливать фильтры на основе шаблона URL: например, аутентифицированные службы RF переходят к /myapp/gwtRequest или неаутентифицированные службы RF переходят к /myapp/anonymousRequest и т. д. .

У меня также есть настроенный RequestTransport, использующий модифицированные версии RequestBuilder и XMLHttpRequest, способные отслеживать события onprogress, что очень полезно для больших запросов.

Вы можете расширить его, чтобы отправлять настраиваемые заголовки, используемые для аутентификации CORS или чего-то еще.

Таким образом, RequestTransport — это способ изменить клиентский транспортный уровень RF.

person Manolo Carrasco Moñino    schedule 03.12.2013