[Seasar-user:10726] Re: [Teeda]「値の保持」と「値の受け渡し」の両立のコツを教えてください

橋本 昇 [E-MAIL ADDRESS DELETED]
2007年 9月 26日 (水) 09:21:17 JST


こんにちは、遠藤さん。
橋本です。

レスに対するお返事が遅くなりましてすみませんでした。


>実は私も最近Teedaを使い始めて同じことに悩んでいて、MLでご意見を伺おうかなと
>思っていたところでした:-)。
やっぱり、お仲間はいるものですね。
ちょっと安心?しました。


>試行錯誤の結果、現在は
>・画面間で共有するプロパティをDTOに定義し、Pageクラスではプロパティの保持を
>そのDTOに委譲する。
>・そのDTOをSubapplictionScopeアノテーションを使って保持(またはHTML内の
><input type="hidden" id="[DTO名]SessionSave"/>を使って保持)
>としています。

このテクニックは基本的にはサブアプリケーション毎に1つの共有DTOを作成す
るという意味なのでしょうか?
それとも、値の受け渡し用としてプロパティを一つ決めて、それ以外は無視する
という事でしょうか?
勉強のため、もうちょっと具体的に教えてください。
よろしくお願いします。


># SubapplicationScopeアノテーションを使って保持するのとhiddenタグの〜
># SessionSaveを使って保持するのとはどう違うのでしょうか。
># こういう場合どちらを使うべきか迷っています。

正直私はSessionSaveの存在を知りませんでした。
※1.0.3からあったんですね。
知らなかった私が言うのもなんですが、もし望む効果がどちらでも達成できるの
であれば、私ならばアノテーションを利用します。
プロジェクトの規約をできるだけJava側に集中すれば下記の効果を期待できそう
だからです。
・コードレビューが少しでも楽になる
・開発者のスペルミスといったケアレスミスが減る


>ただしこの方法でも以下の難点があるのでいまいちすっきりしていません。
>・Pageクラス内でDTOのプロパティのgetter,setterを用意しなければならない
>(せっかくpublic field対応になったのに…)
これはどういう意味でしょう?
重ね重ね申し訳ありませんが、勉強の為に教えていただけますか?



>違う話になってしまいますが、他にTeedaを使っていて悩んでいるのはforeach
です。
>foreach用のDTOのプロパティをPageクラスで再度定義しなければいけないとい
うのが
>つらい。
>1ページ内で複数のDTOのforeachがあると全部のDTOのプロパティをPageクラス
に定義
>しておかなければならないですし、プロパティ名がぶつからないように注意し
なければなら
>ない。今は規約としてDTOのプロパティ名はempDtoNameのように先頭にDTO名を
>つけることにしています。しかし、そうすると非常にプロパティ名が長くなっ
てしまう、
>entityとDTOでプロパティ名が異なるのでDxoで全プロパティの変換ルールを書
かなけれ
>ばならないという不便さがあります。

このアイディアは、Dao用のDTO、Page用のDTO、そしてPageのプロパティこの3
つを準備すると言う事でしょうか?
※Page用のDTOはひょっとしてMapで代替可能?
もしそうだとすると、私が思いつかなかったアイディアです。
実はこの問題に対して私はすでにギブアップしていました。
※別の方法で回避したため、たまたまギブアップできました。(^-^;;
DaoのDTOとページのフィールドの名前変換の解決策になりますね。

しかし、下記のようなアノテーションがTeedaにあったらうれしいなと妄想だけ
はしていました。
@ForEach(prefix="empDto")
public List<EmpDto> empDtoItems;
public String empDtoName;
public Integer empDtoAge;

アノテーションでforeach用のプロパティのprefixを指定できる。
効果
1.複数のforeach用のプロパティ名の変換ルールをPageクラスで定義できる
※Pageに指定するプロパティ名はprefix+DTOのプロパティ名
2.コードの可読性が上がる
※foreachの為のプロパティを見分ける手段がコメント以外にもあった方がコード
レビューが楽
3.foreach用のプロパティがSmartDeployのCustomizerから判断できるので、新
しい工夫が出てくるかも・・
※受け渡し時のデフォルトの変更などが考えられます


遠藤さん。
教えてくださいや、妄想の話題ばかりで申し訳ございません。
また、他のアイディアをお持ちの方がいらっしゃったら是非教えてください。
よろしくお願いします。


en kimi wrote:
> こんにちは。遠藤と申します。
>
> 07/09/20 に 橋本 昇<[E-MAIL ADDRESS DELETED]> さんは書きました:
>   
>> Teedaを利用している皆様にアドバイスをいただきたく思い、質問させていただ
>> きました。
>> 現在私は社内システム開発を通してTeedaの使い方の習得に励んでいるのです
>> が、答えが見えないテーマがあります。
>> Teedaを使った開発の際のページの「値の保持」と「値の受け渡し」の両立です。
>> ありがちなシチュエーションですが下記の答えが見えないのです。
>> 検索画面(1画面)⇒1件選ぶ⇒編集画面(1〜n画面続く)⇒更新orキャンセル⇒
>> 検索画面に戻る
>> という流れのサブアプリケーションがあるとします。
>> 編集画面から元の検索画面に戻ったときに当時の検索条件を保持するにはどうす
>> るのが合理的か?
>>     
>
> 実は私も最近Teedaを使い始めて同じことに悩んでいて、MLでご意見を伺おうかなと
> 思っていたところでした:-)。
>
> 試行錯誤の結果、現在は
> ・画面間で共有するプロパティをDTOに定義し、Pageクラスではプロパティの保持を
> そのDTOに委譲する。
> ・そのDTOをSubapplictionScopeアノテーションを使って保持(またはHTML内の
> <input type="hidden" id="[DTO名]SessionSave"/>を使って保持)
> としています。
>
> # SubapplicationScopeアノテーションを使って保持するのとhiddenタグの〜
> # SessionSaveを使って保持するのとはどう違うのでしょうか。
> # こういう場合どちらを使うべきか迷っています。
>
> ただしこの方法でも以下の難点があるのでいまいちすっきりしていません。
> ・Pageクラス内でDTOのプロパティのgetter,setterを用意しなければならない
> (せっかくpublic field対応になったのに…)
> ・DTOの生成タイミング、いつSubapplicationScopeにつっこむかのタイミングが
> 難しい
>
> こういう場合のベストプラクティスはどんな感じになるのでしょうか。
>
>
> 違う話になってしまいますが、他にTeedaを使っていて悩んでいるのはforeachです。
> foreach用のDTOのプロパティをPageクラスで再度定義しなければいけないというのが
> つらい。
> 1ページ内で複数のDTOのforeachがあると全部のDTOのプロパティをPageクラスに定義
> しておかなければならないですし、プロパティ名がぶつからないように注意しなければなら
> ない。今は規約としてDTOのプロパティ名はempDtoNameのように先頭にDTO名を
> つけることにしています。しかし、そうすると非常にプロパティ名が長くなってしまう、
> entityとDTOでプロパティ名が異なるのでDxoで全プロパティの変換ルールを書かなけれ
> ばならないという不便さがあります。
> _______________________________________________
> Seasar-user mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-user
>
>
>   




Seasar-user メーリングリストの案内