クラスAjaxBehaviorRenderer のソース (260 行目)には、明らかにNamingContainerId を のオプション パラメータのリストに追加する行がありますmojarra.ab(...)。私はこれに出くわしたことがないので、いつ使用されるのか興味があります。
RenderKitUtils.appendProperty(ajaxCommand, "com.sun.faces.namingContainerId", namingContainerId, true);
260行目
先週、仕様の問題 790に取り組んでいるときに、 ajax によって他のフォームをレンダリングするとビューステートが失われる問題を解決する必要があります。これを元に戻すにはどうすればよいですか? 、これはポートレットの専門家である Neil Griffin によって説明されました。
ポートレットは、同じ HTML ドキュメントにレンダリングする複数の JSF ビューを持つことができ、それぞれが独自のビュー ステートを持つようです。ポートレットには、UIViewRootを実装する特別なインスタンスがありますNamingContainer。通常のレンダリング中、すべてのフォーム、入力、およびコマンドには、ビューの独自のクライアント ID がプレフィックスとして付けられた ID と名前が付けられます。これは、同期ポストバック中に正常に機能します。このようにして、ポートレットは復元する正確なビューを識別できます。
ただし、非同期ポストバック中、 は、 、 などjsf.jsの追加の ajax 固有のリクエスト パラメータの束を作成します。これらのリクエスト パラメータ名には、ビューの独自のクライアント ID がプレフィックスとして付けられません。したがって、ポートレットはそれらを特定のビューに関連付けることができません。したがって、実装の問題 3031。javax.faces.sourcejavax.faces.partial.event
このように ajax 応答のビュー ステート識別子が適切に名前空間化されないという別の問題がありました。したがって、ポートレットの実装では、いわゆる「JSF ブリッジ」でパーシャル レスポンス ライターをカスタマイズする必要がありました。これは、仕様の問題 790 の実装時に考慮されます。現在の実装のように「ポートレット環境」をスニッフィングする代わりに、UIViewRoot instanceof NamingContainerどちらがより柔軟でポートレットに依存しないかがチェックされます。Mojarra 固有のものcom.sun.faces.namingContainerIdも削除されます。代わりに、この値はレンダリングされ、そこから抽出できる<partial-response id="...">ようになります。jsf.js
全体として、サーブレットベースの環境のみをターゲットにしている場合は、それほど重要ではありません。
balusC コメントによると:
これは、ポートレット ベースのアプリ (サーブレット ベースのアプリではありません) に対してのみ興味深いものです。それがなぜ、何のために使われるのかを正確に説明することはできませんが (ポートレット/liferay 担当者ならそうかもしれません)、ポートレット固有の機能は「名前空間パラメーター」と呼ばれます。https://web.liferay.com/web/meera.success/blog/-/blogs/liferay-requires-name-spaced-parametersを参照してください