[uruma-dev:81] Re: うるすた ver 0.1.0 構想(更新版)

KOMORI Yusuke [E-MAIL ADDRESS DELETED]
2008年 2月 22日 (金) 01:46:11 JST 

　小森です。

　すみません、返信遅くなりました。

> 1.メソッド・バインディングを支援する
> 　1.アクションクラスに対応した画面定義が存在するかチェックする。
> 　2.EventListenerアノテーションに対応するidを持つGUIコンポーネントが
> 　　画面定義に存在するかチェックする。
> 　　（アノテーションの引数あり／なし共に対応）
> 　3.EventListenerアノテーションにtypeを指定した場合、
> 　　指定したイベントをサポートするGUIコンポーネントかどうかチェックする。

　これ、重要ですね。優先順位も1,2,3の順がよいと思います。
　あと、QuickJUnit みたいに、Eclipse上で画面定義ファイルと対
応するアクションクラスの間をワンタッチで移動できる機能がある
と便利です。

> 2.ウィジット・インジェクションを支援する
> 　1.アクションクラスのフィールドにwidgetクラスを指定した場合、
> 　　対応するGUIコンポーネントが画面定義に存在するかチェックする。

　これもあると嬉しいですね。
　Kijimuna みたいな機能になると思いますが、 ウィジットインジェ
クションは Kijimuna ではチェックしてくれないので。
　対応するGUIコンポーネントが見つからないときはEclipse上で警
告マーク付けてくれるとサイコーです。

> 3.バリュー・バインディングを支援する
> 　1.ImportValueアノテーションのチェック
> 　2.ExportValueアノテーションのチェック
> 　3.BindingLabelアノテーションのチェック
> 　4.フォーム・オブジェクトのチェックは、ちょっと複雑かな…
> 
> 4.セレクション・バインディングを支援する
> 　1.ImportSelectionアノテーションのチェック
> 　2.ExportSelectionアノテーションのチェック

　このへんは、ひとまず指定された ID の整合性チェックがあると
便利ですが、将来的には画面遷移にともなってどのフィールドがイ
ンポート/エクスポートされるのかをドキュメント出力してくれる
機能があると嬉しいかも。

> ◆実現しないこと
> 
> 1.画面定義自体のフォーマットチェックは行わない
> 　→スキーマ等、別の手段で行うべき。
> 
> 2.diconファイルの自動生成は行わない
> 　→app.diconが不要になるため、需要がなくなるため。

　よいと思います。
　フォーマットチェックは XMLSchema のバリデータに任せている
ので、Uruma 本体もあまりチェックしてません。

　dicon の自動生成も不要でよいと思います。

　ひとまず、JIRAに「UrumaStudio」というカテゴリを追加したの
で、そこへ New Feature としてどんどん追加していってはどうで
しょうか。

https://www.seasar.org/issues/browse/URUMA

　ではでは。

On Wed, 20 Feb 2008 23:53:19 +0900, snuffkin <[E-MAIL ADDRESS DELETED]> wrote:

> 束野@snuffkinです。
> 
> アノテーションにアットマーク付けたら、
> メールアドレスと認識したようなので、再度送ります。
> 内容的には[uruma-dev:79]と変わっていません。
> 
> 
> ◆機能名
> 　ガーディアン（仮）
> 　※センスある名前募集中
> 
> 
> ◆目的
> 　Urumaを利用した開発の実装段階で、
> 　実装と画面定義の整合性を取ること。
> 
> ◆概要
> 　Urumaはアノテーション・規約を利用して、
> 　実装と画面定義を結び付けている。
> 　この結び付けは通常、実行するまで正しさを確認することができない。
> 
> 　そこで、実装時に、実装と画面定義の整合性をチェックし、
> 　不整合であれば、実装者に知らせる仕組みを作る。
> 
> 　Uruma Studioの一部として開発する。
> 　技術解としては、Irenkaを利用し、Eclipseプラグインとして提供する。
> 
> 　このような規約厳守のための仕組みは、
> 　規模の大きなプロジェクト程、大きな効果を発揮すると考えている。
> 
> ◆実現すること
> 
> 　Urumaの持つ「××バインディング」「××インジェクション」を
> 　一通りサポートする。
> 
> 　まずは、作りやすい所、需要のある所から順に開発していく。
> 　将来的には以下の機能を開発したい。
> 　要望・フィードバックにより、以下の内容は柔軟に変更していく。
> 　（概ね、上から順に開発しようかと考えています）
> 
> 1.メソッド・バインディングを支援する
> 　1.アクションクラスに対応した画面定義が存在するかチェックする。
> 　2.EventListenerアノテーションに対応するidを持つGUIコンポーネントが
> 　　画面定義に存在するかチェックする。
> 　　（アノテーションの引数あり／なし共に対応）
> 　3.EventListenerアノテーションにtypeを指定した場合、
> 　　指定したイベントをサポートするGUIコンポーネントかどうかチェックする。
> 
> 2.ウィジット・インジェクションを支援する
> 　1.アクションクラスのフィールドにwidgetクラスを指定した場合、
> 　　対応するGUIコンポーネントが画面定義に存在するかチェックする。
> 
> 3.バリュー・バインディングを支援する
> 　1.ImportValueアノテーションのチェック
> 　2.ExportValueアノテーションのチェック
> 　3.BindingLabelアノテーションのチェック
> 　4.フォーム・オブジェクトのチェックは、ちょっと複雑かな…
> 
> 4.セレクション・バインディングを支援する
> 　1.ImportSelectionアノテーションのチェック
> 　2.ExportSelectionアノテーションのチェック
> 
> ◆実現しないこと
> 
> 1.画面定義自体のフォーマットチェックは行わない
> 　→スキーマ等、別の手段で行うべき。
> 
> 2.diconファイルの自動生成は行わない
> 　→app.diconが不要になるため、需要がなくなるため。
> 
> 以上です。
> 
> --------------------------------------------------
>  束野 仁政(Satoyuki Tsukano)
> 
>   E-Mail : [E-MAIL ADDRESS DELETED]
>     Blog : http://d.hatena.ne.jp/snuffkin/
> _______________________________________________
> uruma-dev mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/uruma-dev

----------------------------------------------
 小森 裕介 / Yusuke Komori

  E-Mail : [E-MAIL ADDRESS DELETED]
    Blog : http://d.hatena.ne.jp/y-komori/
     URL : http://www.littleforest.jp/

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