GWT и сторонний междоменный JavaScript

В настоящее время у меня есть проект GWT, использующий модель "Действия и места", предоставленную Google. Мы интегрируемся со сторонним междоменным решением JavaScript, которое отображает JSP внешнего домена в iframe и использует транспорт window.location для уведомления нашего домена, когда пользователь завершил работу с этим JSP.

Проблема в том, что при использовании транспорта window.location система размещения GWT перехватит редактирование URL-адреса и попытается перейти в несуществующее место.

У нас есть некоторое влияние, чтобы заставить третью сторону измениться, поэтому я вижу три варианта:

  1. Поймайте попытку навигации по месту и проигнорируйте ее, если она содержит определенный список зарезервированных строк, которые использует этот сторонний JS.
  2. Попросите третью сторону изменить свое решение на использование window.name (меньше рефакторинга с их стороны)
  3. Попросите третью сторону изменить свое решение для использования JSONP (с их стороны потребуется больше рефакторинга)

Есть ли способ достичь №1?

EDIT. Итак, я понял, как достичь №1, развернув мою собственную версию GWT PlaceHistoryHandler и изменив метод handleHistoryToken. Настоящий вопрос в том, какое из этих трех решений является наилучшим?


javascript cross-domain gwt gwt-places
person michaelwritescode    schedule 02.03.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я бы проголосовал за изменение междоменной сигнализации, если это возможно. Отображаемый в браузере URL-адрес подразумевает, что страницу можно добавить в закладки для повторной загрузки, и предоставляет способ управления историей страницы. Создание другого механизма, основанного на этом, рискует, что пользователь сделает закладку или перейдет к странице / месту, которые не имеют значения для системы обработки токенов истории и могут даже сигнализировать приложению, что iframe загружен, хотя на самом деле это не так.

Тем не менее, если вы на самом деле не используете историю с местами, вы могли бы так же легко использовать Places + Activities с настраиваемым классом, подобным PlaceHistoryHandler, который хранит стек недавних мест, чтобы позволить вернуться к ним, если ваше приложение позволяет это. Это лишило бы смысла кнопку «Назад» в браузере, но все же могло бы позволить внутреннюю навигацию по местам.

Если это не имеет смысла (приложению не нужен хэш-токен, поэтому оставьте его для междоменного взаимодействия), я бы проголосовал за №2 или №3.

person Colin Alworth    schedule 02.03.2012
comment
Хороший аргумент в пользу бумарности страницы. По какой-то причине я полностью упустил из виду эту направленность использования URL-адреса GWT. - person michaelwritescode; 06.03.2012