“我需要在客户端(浏览器会话)使用与JSP文件完全相同的会话:session.setAttribute(”UserName“,username);”
我想纠正你的错误观念。以下不是浏览器端代码,而不是浏览器端会话。它是服务器端代码,管理服务器端会话信息。
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元素。
无论你用JSP生成的javascript做什么,GWT客户端Java源代码都无法做到。
无论由JSP生成的客户端代码需要做什么,也需要由GWT客户端代码完成。
您可以将会话信息嵌入到HTTP标头,POST或GET参数中。
您需要客户端维护会话信息,主要是以cookie的形式。
在某些情况下,jsessionid cookie不是由服务器的响应设置的。
您的servlet或其容器可以为JSESSIONID生成http set-cookie标头。
由于request.getSession(),servlet可以控制何时创建cookie头。
。
JSP之间的差别生成的客户端和GWT生成的客户端
JSP生成的客户端对每个请求/响应刷新。因此,您可以在客户端和服务器之间为每个请求/响应传输更改和数据。
GWT生成的客户端对客户端来说是持久的,而不是刷新的。正因为如此,你正在转向GWT。
这种刷新差异对理解GWT编码差异比JSP更加重要。
JSP中的所有Java代码都是服务器端代码。在JSP中,没有用Java编写的客户端代码。甚至用于生成HTML/javascript的Java代码都是服务器端代码。
所有客户端Java代码被翻译/编译成Javascript。所以GWT Java代码实际上是“编译器端”代码。
。在GWT客户机 - 服务器之间的通信
手段
不要忘了使用Dictionary类客户端代码来发送你的静态设置GWT应用在救援人员到场托管文件中定义JavaScript对象。您可以将JavaScript对象设置为变量,并且在加载gwt模块后,它们将可以由Dictionary类读取。
不要忘了,您可以使用JSP来生成GWT托管文件 - 以便您可以创建不同的字典读物提供的不同行为,您可以针对每次调用您的应用程序进行个性化处理。
但是,你不应该放置在主机文件中的会话ID或认证信息。因为即使由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。
在某些情况下,你可能需要编写一个应用程序GWT时,完全放弃使用传统的JEE会话。
您应该考虑使用REST或REST-RPC,因为我试图将其记录下来(在蜗牛的速度)中:http://h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html。
REST不需要您维护会话cookie。在我看来,GWT最适合于REST-RPC。
你可以浏览过以前的帖子在那里,那里还有其他形式与GWT客户端 - 服务器COMM的解释。