"Мне нужно использовать сеанс на стороне клиента (сеанс браузера) точно так же, как с файлами JSP: session.setAttribute (" Имя пользователя ", имя пользователя);"
Я хочу исправить ваше заблуждение. Ниже приведен не код на стороне браузера и не сеанс на стороне браузера. Это код на стороне сервера, управляющий информацией о сеансе на стороне сервера.
session.setAttribute("UserName", username);
Вы передадите эту информацию о сеансе на стороне сервера клиенту в вашем JSP, например:
<script>
var username = "<%=username%>";
</script>
Или,
<script>
var username = '<%=session.getAttribute("UserName")%>';
</script>
Будучи опытным программистом JSP, вы бы поняли, что между HTML / Javascript (сгенерированным JSP) и самим JSP нет связи. А из-за ограничений, с которыми вы столкнулись в JSP, вы обратились к GWT.
Сходство между клиентом, сгенерированным JSP, и клиентом, сгенерированным GWT
Иногда (возможно, часто) программисты ошибочно принимают код на стороне сервера за код на стороне клиента, и наоборот. Как и вы.
Оба генерируют элементы JavaScript и HTML, которые отправляются на выполнение клиенту.
Что бы вы не делали с javascript, сгенерированным JSP, аналогичным образом это невозможно сделать с помощью клиентского Java-источника GWT.
Что бы ни делалось с помощью клиентского кода, сгенерированного JSP, также должно выполняться с помощью клиентского кода GWT.
Вы можете встроить информацию о сеансе в заголовок HTTP, параметры POST или GET.
Вам необходим клиент для ведения информации о сеансе, в основном в форме файлов cookie.
При определенных обстоятельствах cookie-файл jsessionid не устанавливается ответом сервера.
Ваш сервлет или его контейнер могут сгенерировать заголовок http set-cookie для JSESSIONID.
Сервлет может контролировать, когда создается заголовок cookie - благодаря request.getSession ().
.
Разница между клиентом, сгенерированным JSP, и клиентом, сгенерированным GWT
Клиент, сгенерированный JSP, обновляется по запросу / ответу. Таким образом, вы можете передавать изменения и данные между клиентом и сервером для каждого запроса / ответа.
Клиент, сгенерированный GWT, является постоянным для клиента и не обновляется. Именно по этой причине вы обращаетесь к GWT.
Эта разница в обновлении очень важна для понимания разницы в кодировании для GWT, чем для JSP.
Весь код Java в JSP является кодом на стороне сервера. В JSP нет кода на стороне клиента, написанного на Java. Даже код Java, используемый для генерации HTML / javascript, является кодом на стороне сервера.
Весь клиентский код Java переведен / скомпилирован в Javascript. Таким образом, код GWT Java на самом деле является кодом на стороне компилятора.
.
Средства связи между клиент-сервером в GWT
Не забудьте использовать клиентский код класса Dictionary для передачи ваших статических настроек в приложение GWT через объекты Javascript, определенные в файле хоста. Вы можете установить объекты javascript в качестве переменных, и они будут доступны для чтения в классе Dictionary после загрузки модуля gwt.
Не забывайте, что вы можете использовать JSP для генерации файла хоста GWT - так что вы можете создавать различные варианты поведения, обеспечиваемые различными значениями словаря, которые вы можете индивидуализировать для каждого вызова вашего приложения.
Однако не следует размещать идентификатор сеанса или информацию для аутентификации в файле хостинга. Потому что, хотя JSP динамически генерируется, он на самом деле статичен на постоянном клиенте GWT.
Вы можете использовать Window.Location.reload (), чтобы без необходимости обновлять свой клиент GWT, на тот случай, если вам все еще нравятся эффекты обновления JSP.
GWT-RPC
RequestBuilder
RequestFactory
REST и REST-RPC
Сценарий включает (для пересечения границ SLD-SOP)
Все клиент-серверное взаимодействие требует, чтобы клиент GWT предоставил обратный вызов из-за асинхронности технологии.
Взгляните на http://google -web-toolkit.googlecode.com / svn / javadoc / 2.4 / com / google / gwt / http / client / RequestBuilder.html (или просмотрите его на личная копия GWT Javadoc).
... где вы сможете определить набор и получить заголовки. Ваша серверная сторона должна согласовать с клиентом, какое имя заголовка используется.
Вам не нужно зависеть от обычного сеанса JEE для "поддержания сеанса". Вы можете создать свою собственную структуру токенов. Или используйте существующий, такой как OAuth или OpenId.
При различных условиях вы не получите cookie сеанса в ответе сервера.
При определенных обстоятельствах вам может потребоваться полностью отказаться от использования обычных сеансов JEE при написании приложения GWT.
Вам следует рассмотреть возможность использования REST или REST-RPC, поскольку я пытаюсь задокументировать это (со скоростью улитки) в: http://h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html.
REST не требует от вас сохранения файла cookie сеанса. На мой взгляд, GWT лучше всего работает с REST-RPC.
Вы можете просмотреть предыдущие посты там, где есть объяснение других форм связи клиент-сервер с GWT.