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

Koichi Kobayashi [E-MAIL ADDRESS DELETED]
2009年 1月 26日 (月) 04:30:09 JST


小林 (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: リリース計画

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

お疲れ様でした.

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

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

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

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

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

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

> <3点目>
> H2 ベースで説明するドキュメントを追加しました。
> DEPTとEMPを例にとって説明するようにしました。

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

それから,<2点目> の制約についてドキュメントに
記載があった方がいいと思います.

また,「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>



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