[Seasar-user:9929] Re: [Teeda]Pageコンポーネントをセッションに格納してもよい？

[Shinpei Ohtani]

大谷です.

> 現在開発初心者でも敷居が低いフレームワークとしてTeedaを検討しています。
> 生産性を上げる為の工夫には目を見張るものがあり、非常に魅力的なフレーム
> ワークだと感じております。
>
> しかし個人的に気になっている点があります。
>
> Teedaを利用した開発では下記の方法が推奨されていると思います。
> ・Pageコンポーネントはリクエストに格納
> ・Pageのフィールドの永続化はhidden項目やxxxItemsSaveを利用する事
>
> しかし、私はPageコンポーネントをセッションに入れる事を検討しております。
> 理由は、開発初心者には下記の点を理解/徹底してもらうのが難しそうだからです。
> ・画面に表示されない項目はhiddenを定義
> ・xxxItemsの為にxxxItemsSaveの定義
> ・できるだけ再描画を伴わない画面遷移で設計する事
>
> 一見完成した画面でも特定の動きをすると値が消えてしまうとかの不具合が発生
> しそうです。
> 神経も使います。
> ですので、いっそのことPageをセッションに入れる事ができれば、気が楽だなと
> 考えております。
> 少なくとも値が消える事は無い。VBと一緒。(^-^)
> だから、TeedaでもPageをセッションに入れてしまいたいのです。

Pageをセッションに入れることで別の問題が発生して
それはそれで神経を使う気がします.
例えばSessionからのクリアが足りなくて
思わぬところで値が復元されたりなどです.

というわけでPageをセッションに入れるべきではありません.

> このような条件下あれば動く予感がありますが、利用方法として保障の範囲で
> しょうか？

保障の意味がよくわかりませんが、まずはご自身の力で解決することを
念頭においた方が良いじゃないかと思います.
MLにメールもらえれば、それなりには回答されるはずですが
あまりに特殊な状況は好ましくないように思います.


07/08/16 に 橋本 昇<[E-MAIL ADDRESS DELETED]> さんは書きました:
> こんにちは。
> 橋本と申します。
>
> 現在開発初心者でも敷居が低いフレームワークとしてTeedaを検討しています。
> 生産性を上げる為の工夫には目を見張るものがあり、非常に魅力的なフレーム
> ワークだと感じております。
>
> しかし個人的に気になっている点があります。
>
> Teedaを利用した開発では下記の方法が推奨されていると思います。
> ・Pageコンポーネントはリクエストに格納
> ・Pageのフィールドの永続化はhidden項目やxxxItemsSaveを利用する事
>
> しかし、私はPageコンポーネントをセッションに入れる事を検討しております。
> 理由は、開発初心者には下記の点を理解/徹底してもらうのが難しそうだからです。
> ・画面に表示されない項目はhiddenを定義
> ・xxxItemsの為にxxxItemsSaveの定義
> ・できるだけ再描画を伴わない画面遷移で設計する事
>
> 一見完成した画面でも特定の動きをすると値が消えてしまうとかの不具合が発生
> しそうです。
> 神経も使います。
> ですので、いっそのことPageをセッションに入れる事ができれば、気が楽だなと
> 考えております。
> 少なくとも値が消える事は無い。VBと一緒。(^-^)
> だから、TeedaでもPageをセッションに入れてしまいたいのです。
>
> 非常に乱暴な動機ですみませんm(__)m
>
> Teedaのコンセプトとしてセッションにあまり物を詰め込まない事を推奨してい
> る事はわかっております。
> しかし、今回は実行時の効率より作成時の効率を重視して検討を行っております。
>
> で、思い立って実験してみたのですが・・・
> １．
> pageCreatorのinstanceDefをSESSIONに変更。
> actionCreatorはREQUESTのまま。
> ２．
> initialize/prerender/doXXXなど、すべてのイベントはActionに定義。
> ３．
> Pageにはインジェクションは行わない。
> 基本的にActionに対してだけインジェクションを行う。
> ※どうしてもPageで欲しければコンテナに対してgetComponent()を行う。
> ※ライフサイクルがセッションより短いコンポーネントだってあるかも知れない
> ため。
> ４．
> Pageの値復旧はセッションに格納されているため大丈夫なはず。
> ウインドウ別にセッションを管理できる事は未検討。(^-^;;
> Teedaの特徴なので、なんらか工夫したいのですが・・・知恵がたりないです。
> ５．
> サブアプリケーション内での値の共有方法としてPOST/GETの引渡しだけでなく
> Beanの共有手段として@SubapplicationScopeも利用する。
> ６．
> サブアプリケーションを移動した際のPageの破棄はフレームワーク担当者がカラ
> クリを作る。(^-^;;
> ※普通の開発者は気にしなくてもよい方向で・・・
> ７．
> PageコンポーネントにAOPは行わない。
> ※HotDeploy時にClassNotFoundが発生するため。
> ※そういうものなのですか？判断がつきません。
>
> このような条件下あれば動く予感がありますが、利用方法として保障の範囲で
> しょうか？
>
> また、特別な工夫をする事なく、Pageはリクエストのままで、ただしPageのすべ
> てのgetter/setterに対して@PageScope or @SubapplicationScopeをAOPする方法
> とではどちらの方が現実的でしょうか？
>
> コミッタの方々、どなたか御回答いただけないでしょうか？
>
>
>
> また、実験の最中に気がついたのですが、UIで利用しないフィールドに
> @PageScopeを指定し、ポストバックをした場合、リクエストスコープにこの値が
> 格納されないため値が受け継がれないようです。
> ※この実験はPageのinstanceDefをREQUESTにして行いました
> @SubapplicationScope/@RedirectScopeなどはリクエストスコープを利用して値
> を受け渡しているようですので、 @PageScopeもてっきり同じだと思ったのです
> が、この差は仕様なのでしょうか？
>
>
> 長文ですがよろしくお願いします。
>
> _______________________________________________
> Seasar-user mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-user
>


-- 
=============================
Shinpei Ohtani
[E-MAIL ADDRESS DELETED]
=============================