仕様の問題 949で説明されているように、これは新しい JSF 2.2 機能の一部です。基本的に、JSF がクライアント ウィンドウを識別できるようにします。基本的cidに CDI@ConversationScopedやwindowIdCODI の@ViewScoped/と同じ@ViewAccessScopedです。このクライアント ウィンドウ ID は、spec issue 730で説明されているように、特に新しい JSF 2.2@FlowScopedスコープによって使用されます。
「JSF 2.2 の新機能」私の仲間の Arjan Tijms の記事では、必要性をかなり明確に説明しています。
ライフサイクル
ウィンドウ ID を使用してクライアント ウィンドウを識別します
ほぼ間違いなく、Web アプリケーションの開発を開始以来悩ませてきた最大の問題の 1 つは、単一のブラウザーの異なるウィンドウから発信された要求を区別できないことです。実際の解決策が大幅に遅れただけでなく、これが問題であることに気付くまでに長い時間がかかりました。
問題の根源は、いつものように、HTTP プロトコルが本質的にステートレスであるのに対し、アプリケーションは一般的にそうではないということです。ただし、Cookie の概念はあります。これは、さまざまなユーザーからの要求を区別し、ログイン メカニズムの大部分が基づいているセッション スコープなどを実装するために圧倒的に使用されるメカニズムです。
これには Cookie が機能しますが、ブラウザーとドメインごとにグローバルです。ユーザーが同じドメインに対して複数のタブまたはウィンドウを開くと、それらからのリクエストはすべて同じ Cookie をサーバーに送信します。したがって、同じ Web サイトの別のウィンドウで別のユーザーとしてログインすることは通常不可能であり、別のウィンドウでワークフロー (ポストバック、ナビゲーションを含む) を使用することも、このため面倒になる可能性があります。
JSF には、これに何らかの形で関連するさまざまなソリューションがあります。ビュー スコープは、ユーザーが同じページにとどまり、ポストバックのみを行う限り、ウィンドウごとにセッションを効果的に実装します。Flash は、ナビゲーションが Redirect/GET を介して行われるときに、異なるページ間 (おそらく同じウィンドウ内) でデータを転送するために使用されます。同様のことを行うサードパーティによって実装されたさまざまなスコープがあります。
これらのすべてには、「クライアント ウィンドウ」の概念の暗黙の概念または仮定がありますが、これに対する明示的な API はありません。
JSF 2.2 では、これの 2 つの異なる側面のサポートが導入されます。
- 個々のウィンドウの識別: クライアント ウィンドウ ID
- ウィンドウの概念に関する API とライフサイクルの認識
どうやら、アプリケーションをそのように構成したようです。