id:susie_y さんへのお返事

Uruma

id:susie_y さんのコミッタお誘いに成功しました！

RSS リーダはサンプルとして再構成しますね。また、UrumaのSeasar2.4 の規約とcooldeployに対応した改修を行っています。手元ではそれっぽく動いてますが、もう少しまとめたら実装方針について質問させてください。

S2.4 の 規約 & cooldeploy 対応は、やらなきゃと思っていたところです。ぜひぜいひ、お願いします。

ユーザ操作により、すでに表示中のViewを異なる未表示のViewに表示を更新できないか。

ちょっとイメージ沸かないのですが、どんなシチュエーションでしょうか？

イメージはWebのような画面の遷移です。ユーザがメニューやボタンを押下すると、ビューがチェンジする（画面遷移してるように見える）感じです。

あらかじめ定義しておいたビュー表示する機能や、表示中のビューを破棄する機能になるかと思います。

なるほど。ただ、Web アプリケーションとしては画面遷移が多いですが、従来の GUI だと子ダイアログの表示や、ウィザードという形が多いのではないでしょうか？ これだとだめですか？？

アプリ全体の初期化のため、アプリケーション全体に緋もづくActionがないか。

⇒ AXISやRMI接続の初期化、DB接続の初期化などのため。

これも、実際のアプリケーションを作るために必要ですね。考えてみます。

WorkbenchActionの名称でクラスを作成し、@InitializeMethodアノテーションを定義したメソッドがアプリ全体の初期化メソッドにできればなぁと思っています。

いいですね！ ただ、@InitializeMethod だと、従来の動きと区別がつかなくなるので、別のアノテーションにした方が良いかもしれません。

【案１】
@ActivationMethod のように別のアノテーションを付けて、そのアノテーションをつけたメソッドがすべて呼び出される。

これだと、クラスが増えてくると検索に時間がかかるのでやめた方がいいかな。

【案２】

でも、「特定メソッド」は、やはりアノテーションか命名規約が必要だから、案1とあまり変わらない・・・

【案３】

  • 特定のインターフェースを用意して、そのインターフェースの実装クラスをUrumaから呼び出す。

POJO ではなくなるけど、これがわかりやすいかも。初期化時に呼び出されるような処理はあちこちに散らばってしまうとわかりにくくなるので、ある程度フレームワークで強制したほうが親切か。

このへんの議論を踏まえると、初期化なんてアプリケーション固有の処理がほとんどで、再利用する可能性はほとんどないから、基本に戻って起動、終了処理用のインターフェースを提供するのがよいでしょうか。

Urumaアプリケーションの実体は OSGi バンドルです。本来、OSGi バンドルでは、ライフサイクルを管理するために BundleActivater インターフェースの実装クラスを用意します。Uruma では、それを用意しなくてもよいよう、こっそりUrumaAppActivatorというクラスを提供しています。

ただ、BundleActivator をそのまま開発者に利用させると OSGi を意識することになるので、 Uruma でワンラップしたインターフェースをよういすればよいかな。

ながくなりましたが、いかがでしょう？？

WorkBentchに緋もづくGUI部品（Perspectiveなど）を直接制御したいため、WorkBentchに緋もづくActionがないか。

SWT まわりは最終的に Widget インジェクションを使えば細かい制御ができるのですが、Workbench まわりも必要ですね。Uruma 側で API を利用するか、Workbench 関連のインターフェースをインジェクションする機能があればいいでしょうか。

Urumaでラップ部品をインジェクションされて使うのは大変らくちんです。

しかし、Urumaでまだ提供されていない部品もあるため、ActionからネイティブなRCPに直接アクセスしコーディングできれば、開発が進めれるかと思いました。

そうですね。Uruma RCP 起動時に、必要なクラスを S2Container に登録してあげれば、DI で引っ張ってこれそうです。さしあたり、IWorkbench あたりがあればよいでしょうか。

ではでは。