「JSP ファイルとまったく同じように、クライアント側 (ブラウザのセッション) でセッションを使用する必要があります: session.setAttribute("UserName", username);」
あなたの誤解を正したいと思います。以下はブラウザ側のコードではなく、ブラウザ側のセッションでもありません。これはサーバー側のコードであり、サーバー側のセッション情報を管理します。
session.setAttribute("UserName", username);
このサーバー側のセッション情報を JSP でクライアントに送信します。次に例を示します。
<script>
var username = "<%=username%>";
</script>
または、
<script>
var username = '<%=session.getAttribute("UserName")%>';
</script>
経験豊富な JSP プログラマーは、(JSP によって生成された) HTML/Javascript と JSP 自体の間の分離を理解するでしょう。また、JSP で直面していた制限が、GWT に目を向けている理由です。
JSP 生成クライアントと GWT 生成クライアントの類似点
ときどき (おそらく頻繁に) プログラマーは、サーバー側のコードをクライアント側のコードと間違えたり、その逆を行ったりします。あなたがしたように。
どちらも、クライアントに送信されて実行される JavaScript 要素と HTML 要素を生成します。
JSP によって生成された JavaScript で実行できないことはすべて、GWT クライアント側 Java ソースでも実行できません。
JSP によって生成されたクライアント コードで実行する必要があることはすべて、GWT クライアント コードでも実行する必要があります。
HTTP ヘッダー、POST、または GET パラメータにセッション情報を埋め込むことができます。
ほとんどの場合、Cookie の形式で、クライアントがセッション情報を維持する必要があります。
特定の状況下では、jsessionid Cookie がサーバーの応答によって設定されません。
サーブレットまたはそのコンテナーは、JSESSIONID の http set-cookie ヘッダーを生成できます。
request.getSession() により、サーブレットは Cookie ヘッダーがいつ作成されるかを制御できます。
.
JSP生成クライアントとGWT生成クライアントの違い
JSP によって生成されたクライアントは、要求/応答ごとに更新されます。そのため、すべての要求/応答について、クライアントとサーバーの間で変更とデータを送信できます。
GWT によって生成されたクライアントは、クライアントに対して永続的であり、更新されません。これが、GWT に目を向けている理由です。
この更新の違いは、JSP と GWT のコーディングの違いを理解する上で非常に重要です。
JSP の Java コードはすべてサーバー側のコードです。JSP には、Java で記述されたクライアント側のコードはありません。HTML/javascript の生成に使用される Java コードでさえ、サーバー側のコードです。
すべてのクライアント側の Java コードは、Javascript に変換/コンパイルされます。したがって、GWT Java コードは実際には「コンパイラ側」のコードです。
.
GWT におけるクライアントサーバー間の通信手段
Dictionary クラスのクライアント側コードを使用して、ホスティング ファイルで定義された Javascript オブジェクトを通じて静的設定を GWT アプリに送信することを忘れないでください。JavaScript オブジェクトを変数として設定すると、gwt モジュールがロードされた後に Dictionary クラスで読み取り可能になります。
JSP を使用して GWT ホスティング ファイルを生成できることを忘れないでください。これにより、アプリの呼び出しごとに個別化できるさまざまな辞書の読み取りによって提供されるさまざまな動作を作成できます。
ただし、セッション ID または認証情報をホスティング ファイルに配置しないでください。JSP によって動的に生成されますが、永続的な GWT クライアントでは実際には静的であるためです。
Window.Location.reload() を使用して、不必要に GWT クライアントをリフレッシュできます。これは、JSP のリフレッシュ効果がまだ気に入っている場合に備えてです。
GWT-RPC
RequestBuilder
リクエストファクトリー
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 の個人用コピーで参照してください)。 .
... set および get ヘッダーを定義できる場所。サーバー側は、使用するヘッダー名についてクライアントと合意する必要があります。
「セッションを維持する」ために、従来の 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 を使用した他の形式のクライアント/サーバー通信に関する説明がある以前の投稿を閲覧できます。