[Seasar-user:12877] Re: 【teedaExt】saveState/restoreStateの動作に関して

[Yasuo Higa]

ひがです。
> 
> > また、セッションに保存するときに、コンポーネントステートの
> > オブジェクト(SerializedView)を作るので、動作も遅くなるでしょう。
> 
> この点気になるのですが、SerializedView自体は毎回作っていると思います。
> 作った後にTeedaStateManagerImplのsaveSerializedViewToServerで
> 既に保存済みか否かを確認しています。
> 保存済みか確認して無ければ作るのでは問題があるのでしょうか？
> それとも全く違う部分の実装の事でしょうか？
> 
がーん。
無駄にオブジェクト作ってますね。
保存済みならSerializedViewは作る必要ない気がします。

> > お勧めは、UIComponentをステートレスに作ることです。
> > 直前の状態が復元されることを当てにしないという意味です。
> 
> なるほど。今回問題になったのは、
> te:condition,te:forEachを組み合わせたようなコンポーネントです。
> ループの件数やRenderしたかいなかを元に子コンポーネントを
> Restore/Decodeしないと厳しいのでその状態を
> saveState/restoreStateを使って保っていました。
> 
> と言う事で、
> TForEach、TCondition中を見ました。非常に参考になります。
> こちらもどちらかを参考にして実装を変更しようと思います。
> TForEach:pageScopeにアクセスする
> TCondition:ComponentStatesHolder.save/resotoreを利用
> と方法違うのですね。
> TForEachがRender時のデータ件数を覚えている方法の、
> ComponentStatesHolder.save/resotoreを利用する方法は、
> JSF通常の方法なのでしょうか？

TForEachがJSFの通常の方法かといわれるとなんともいえません。
TConditionは特殊なことは間違いないです。

> どちらがお勧めでしょうか？どちらにしてもTeeda内部の実装を
> 利用するので、今後変更にならない方が嬉しいです。
> 
優劣はないと思うので自分にあった方法を選ぶのがいいと思います。
基本的に、Teedaの内部の構造は、できるだけ変えないように作業を
すすめていますが、絶対にないかといわれると
なんともいえないというのが正直なところです。

よろしくお願いします。