[seasar-dev:1022] Re: リリース計画

[Koichi Kobayashi]

小林 (koichik) です．

Date:    Sun, 25 Jan 2009 20:27:12 +0900
From:    [E-MAIL ADDRESS DELETED]
To:      [E-MAIL ADDRESS DELETED]
Subject: [seasar-dev:1021] Re: リリース計画

> ソースとドキュメントをコミットしました。

お疲れ様でした．

> ＜１点目＞
> ダイアログのディテール側のテーブルを表示する方法ですが、
> ダイアログの detail を選ぶ選択リストに、テーブルを全部表示するようにしま
> した。

それが分かりやすくていいと思います．

> ＜２点目＞
> 「DEPT と EMP は 1 対多の関係」に対応するようにソースを変更しました。
> このための制約として、
> DEPT のプライマリキーが EMP にある場合、その列名を「DEPT_ID」と仮定しま
> した。
> つまり、「"マスタテーブル名"+"_ID"」がマスタとディテールの関連を表す制約
> としました。
> 
> master-detail については仕様・UI とももう少し検討した方が良いと
> 私も思いますので、暫定の制約として、Rails と似たような規約に合わせたました。

了解です．
今度のリリースはこの暫定版でいきましょうか．

しかし．．．
我が家の環境で試そうとすると，Scaffold Type が
空っぽです．．．
Teeda + S2Dao なのに．うーみゅ．．．
明日職場の環境で試してみます．

ドキュメントではこの Scaffold Type に
「Master-Detail ...」と表示されるようですが，
Master-Detail の部分は不要じゃないでしょうか？
それはこのダイアログで自明なので，表示する
情報はその後だけで十分だと思います．

> ＜３点目＞
> H2 ベースで説明するドキュメントを追加しました。
> ＤＥＰＴとＥＭＰを例にとって説明するようにしました。

元のドキュメントはそのままで新しいページを
追加したんですね．
元のドキュメントは前述の変更が反映されていませんが，
それなら元のドキュメントを修正した方がよかったのでは？
ほぼ同じドキュメントが複数あってもメンテナンスの
負担が増えるので，整理したいところです．

それから，＜２点目＞ の制約についてドキュメントに
記載があった方がいいと思います．

また，「Retrieval Condition」のところに通常の
scaffold と同じような説明があった方がいいと
思います．
ここで何を指定するか分からない人もいると思うので．



Master Detail ではない通常の scaffold ですが，
「Retrieval Condition」のところに「(Only forS2Dao」
という文言があります．
これはどういうことでしょう？
Kuina-Dao も対応していますよね？

制限がある場合は文言で示すのではなく，サポート
していない Scaffold Type が選ばれた場合に
「Retrieval Condition」を無効化する方がいいと思います．


-- 
<component name="koichik">
    <property name="fullName">"Koichi Kobayashi"</property>
    <property name="email">"[E-MAIL ADDRESS DELETED]"</property>
    <property name="blog">"http://d.hatena.ne.jp/koichik"</property>
</component>