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

2007年 8月 16日 (木) 15:14:24 JST

橋本です。

ひがさん、大谷さん、御回答ありがとうございます。

ちょっと公の場に出すべき文章では無かったようです。
失礼しました。

結論的には、Pageコンポーネントをセッションに入れる事は特殊な利用法であ
り、製作者としてはコンセプト外という事ですね。
了解しました。

確かに、Pageがセッションに格納されているという状態はTeedaExtensionの
ActionSupportInterceptorのコードに垣間見えるだけであり、ドキュメントとし
て記述されているものではありませんね。
ただし、「画面の再描画を開発者の労力を最小限で実現する」という要望自体は
StrutsにおけるActionFormをセッションに格納する事によって実現できる効果と
同じ事を望んでいるつもりですので特殊ではないと思っています。

次はTigerScopeAnnotationHandlerの派生クラスを作成し、引継ぎスコープのデ
フォルトを変更するという方法で検討してみたいと思います。
これはすべてのフィールドにスコープ定義のアノテーションを記述する事と同じ
ですので、利用法としては問題がない（はず）と認識しております。


TO:ひがさん
>つまづきながら学習していき、最初は初心者でもいつのまにか
>中級者、上級者になっていく。
>そんな開発のやりかたが良いのではないかと思っています。

その通りですね。
私個人的にもそう思いますし、そうあって欲しいと思います。

しかし、職業でシステム開発を行っている方は現実としてご理解いただけると思
いますが、いつも技術的な教育や啓蒙を考慮できるケースばかりではありません。
よって、非常に寂しい事ですがプロジェクトによって使い分ける事を考えており
ます。
※公の場で使い分ける事ができなかったわけですが・・・

ひがさんの日ごろの活動を考慮した場合、気分を害する発言だったかもしれません。
すみませんでした。


TO:大谷さん

>保障の意味がよくわかりませんが、まずはご自身の力で解決することを
>念頭においた方が良いじゃないかと思います.

保障という言葉は不適切でした。
※無償で提供されるソフトウェアに対してふさわしい言葉ではないですね

作成者として、そしてTeedaとしてそのような利用法は想定内/許容範囲ですか？
という意味でした。
※明らかに例として見当たらない利用法でしたので・・・

調査を進める⇒うまくいかない⇒質問する⇒実はコンセプトレベルでの勘違い⇒相談不可
という流れを避けたかった、もしくは早期に気がつきたかったというのが本音です。

しかし実際は尋ね方の問題が大きかったのではないかと個人的に反省しております。


以上です。

Shinpei Ohtani wrote:
> 大谷です.
>
>   
>> 現在開発初心者でも敷居が低いフレームワークとして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
>>
>>     
>
>
>