2012-02-28 25 views
0

上に保持されていない私は、動的に私はこのリストを反復処理するとき、私はその実現、JSF 2 - 動的に追加されたコンポーネントのIDがポストバック

UIComponent c = new UICustomComponent(); 
    c.setId("someIdGeneratedDynamically"); 
    facet.getChildren().add(c); 

しかし、ポストバック上を使用してコンポーネントを追加し、その中のコンポーネント内のファセットを持ちますコンポーネントは存在しますが、そのIDは前に指定したものとは異なります。 (具体的には、これらのIDの形式は「j_id9、j_id10」など)

StateManagementStrategyImplで少しのコードをデバッグし、ビューを保存する際に意図的にコンポーネントIDを格納していないことに気付きました。

私の質問は、JSFがコンポーネントIDを保存しないのはなぜですか?

答えて

1

最後に記載された質問に答えるには、RestoreViewフェーズで、JSFが要求されたビューをテンプレートファイルから再構築します。テンプレートが変更されない限り、コンポーネントは常に同じIDを受け取ります。状態はclientIdsをキーとして保存されます。プログラムでクライアントIDを変更した場合、状態を正しく復元することは不可能です。再作成されたコンポーネントは元のIDを持ち、その状態は別の(変更された)IDの下に格納されます。それがclientIdを「保存」しない理由です。これは一定であることが予想され、再作成されたコンポーネントを以前の要求からの状態と突き合わせることを可能にするものです。

この動作は、テンプレートから作成されたコンポーネントにのみ当てはまります。 JSFには、プログラムによって追加されたコンポーネントを処理するための専用のメカニズムがあり、このメカニズムが期待通りにclientIdを処理することが期待されます。

+0

わかりました。動的に追加されるコンポーネントのクライアントIDは保存されます。 'StateManagementStrategyImpl'の' ComponentStruct'を参照してください。私の質問は、クライアントIDではなくコンポーネントIDに関するものでした。 – Nerrve

+0

それはまさに私が書いたことです:動的に追加されたコンポーネントは状態管理のために別々のメカニズムを使いますが、私はあなたの質問が一般的なメカニズムに関係していると理解しました。クライアントIDはコンポーネントIDの派生物です。 – mrembisz

+0

は、コンポーネントIDまたはクライアントIDに関係なく、コンポーネントインスタンスの次の要求では保持されません。クライアントIDは(マップのキーとして)状態を復元するためだけに使用されますが、おそらくそれが使用されている唯一のものです。 – Nerrve

関連する問題