ゆっちのＢｌｏｇ

今日は JSR296 のリソースファイルを利用した仕組みについて調べてみます。

DesktopApplication1AboutBox クラスを参考にします。

initComponents() メソッドの処理の中に見慣れないコードがあったのを覚えているでしょうか？

まず、JDialog のタイトルを見ましょう。

org.jdesktop.application.ResourceMap resourceMap = org.jdesktop.application.Application.getInstance(desktopapplication1.DesktopApplication1.class).getContext().getResourceMap(DesktopApplication1AboutBox.class);
setTitle(resourceMap.getString(“title”)); // NOI18N
setModal(true);
setName(“aboutBox”); // NOI18N

この見慣れないコードによってリソースファイルの情報を取得してアプリケーションにセットしてます。

最初の３行で org.jdesktop.application.ResourceMap resourceMap にリソースファイルの情報を取り込んでます。

desktopapplication1.DesktopApplication1.class のインスタンス、コンテキストを取得し、

getResourceMap() メソッドの引数で指定されている DesktopApplication1AboutBox.class のリソースファイル

つまり、DesktopApplication1AboutBox.properties ファイルが使用されるということですね。

４行目の

setTitle(resourceMap.getString(“title“)); // NOI18N

によって DesktopApplication1AboutBox.properties の

title = About: ${Application.title} ${Application.version}

でタイトルが設定されるようです。

${Application.title} ${Application.version} この二つはDesktopApplication1.properties の４行目と５行目にある

Application.title = +++ ** Basic Application Example ** +++

Application.version = 1.012345

です。

なんでこんなになっているんでしょうか？

リソースファイルを全てクラスごとに分けてもいいんでしょうが、アプリケーション全体で共有できるものはしたほうがいい。

たぶん、きっとそういう考えからだと思う。

その他のラベルも同じ仕組みになってます。

ソースを見れば一目瞭然です。

この DesktopApplication1AboutBox クラスは NetBeans によって自動生成されたものでしたね。

ちょっとラベルのプロパティを覗いてみましょう。

appTitleLabel を見てみます。

Swing Application Framework のリソースインジェクションを使用するために、

リソースとして定義のチェックボックスにチェックを入れてありますね。

ローカライズ機能を使用するために、ローカライズ版にもチェックが入ってます。

ここで注目なのがスコープの設定がアプリケーションになっているということです。

キーに先ほど出てきた DesktopApplication1.properties ファイルの Application.title が設定されてます。

値はそれに設定した +++ ** Basic Application Example ** +++ が入ってます。

これは自動生成されたものですが、自分で作ったラベルにももちろん設定できます。

こういった設定が GUI 操作でできるのはうれしいです（＾＾）

さすが NetBeans と褒めておこう！

ちなみに？マークのヘルプがあるので表示させてみる。

ここではリソースファイルと言わずにプロパティファイルと言ってますね。

そのプロパティファイルの値をアプリケーションリソースと呼んでます。

そう言われてみればそうなんですが、ここで言うプロパティファイルは一般的にはリソースファイルでも通じますよね？

なんだか細かなことだが気になります。

とりあえず今日は、イベントを発生させることができないラベルについて調べてみました。

面白い仕組みになってます（＾＾）

OpenSolaris 2008.05 をインストールしてみた。

適当にマニュアルを見ずにインストールして root でログインしようとしたら蹴られた orz

これは root だけ設定し、ユーザーを作らなければ回避できるらしい。

今までの Solaris とはあきらかに違う。

おまけにシェルも普通と違うらしい。

さらに私にとって致命的なのは VMwareTools がインストールできないということだ。

OpenSolaris 2008.05 って今の段階では情報不足（日本語）かもしれない。（情報収集努力不足とも言う）

ちなみに OpenSolaris 2008.05 でなければいけない理由もない。

強いて言うならば Windows 以外の OS を触ってみたいだけ（爆

今日はプロジェクトのプロパティを設定します。

アプリケーションのプロパティを見てみます。

このように自動生成されてます。

次に

デスクトップアプリケーションを見てみましょう。

説明に共通アプリケーションを補う Swing Application Framework 固有のプロパティとあります。

これも上記のように自動生成されてます。

これらって、何処かで見たような記憶がありますね。

面白いことにこれらの設定は Swing Application Framework のリソースファイルに反映されるようです。

そう、Help メニューのAbout… ポップアップする JDialog の表示内容です。

試しに設定を下記のように変更してみます。

それでは、アプリケーションを実行してみましょう。

おお！ 予想通りの結果ですね。

リソースファイルの DesktopApplication1.properties ファイルも変更されてます。

ここで天の邪鬼な私としては、リソースファイルの DesktopApplication1.properties ファイルを変更したらどうなる？

もちろん、試してみました。

上記のように設定を変更し、アプリケーションを実行してみます。

やはり、想像通りの結果となりました。

プロジェクトのプロパティの設定も確認してみます。

あれれ？

アプリケーションの設定は変更されてないですね。

デスクトップアプリケーションはリソースファイルでの変更が反映されてるのに・・・

まぁ、こういう仕様なんだと思って深く追求しないことにしときます。（追求する力が無いというのが正解）

とりあえず、リソースファイルの情報をなんらかの手段によってアプリケーションに反映させていることだけは確認できました。

今日はここまでってことで（＾＾；

このトリックがどうなってるのか楽しみですね。

今日は DesktopApplication1AboutBox クラスをみてみます。

ぱっと見は普通の JDialog のようですが・・・

また見慣れないコードがあります。

それに initComponents() の処理のところにこんなのも

いったいこの怪しいコードで何がおこなわれているのでしょうか？

プロジェクトツリーの desktopapplication1.resources の中にある

DesktopApplication1 properties

DesktopApplication1AboutBox properties

DesktopApplication1View properties

この三つのプロパティファイルが JSR296 の鍵になるはずだから

見慣れない怪しいコードはこれらが深く関わっていると思う。

とりあえず、このプロパティファイルをちょっと見てみましょう。

キーとバリューの関係のようですね。

おそらく、JSR296 ではこれらのリソースファイル（プロパティファイル）を積極的に使用するのでしょうか。

適当に変更して変化を見てみるのも面白そうですが今回はここまでにします。

とりあえず、プロジェクトのプロパティの設定もしてないのでそれをしてからいろいろ遊んでみようと思います。

DesktopApplication1View クラスを調べてみます。

このクラスは DesktopApplication1 クラスの startup() メソッドにある show() メソッドに渡されます。

GUI の初期化などをしています。

継承元の FrameView クラスをみてみます。

java.lang.Object
  → org.jdesktop.application.AbstractBean
      → org.jdesktop.application.View
          → org.jdesktop.application.FrameView

上記のような継承関係になってます。

rameView クラスのドキュメントがないのでとりあえずソースを見てみます。

getFrame()メソッドに何やら怪しい方法で JFrame のタイトルを取得して生成しているようです。

このようなコードは JSR296 を使う上ではよく見ることになるでしょう。

リソースファイルにアクセスして指定したコンポーネントのプロパティを取得し、それらを使用するのが

JSR296 の必須テクノロジーのようです。

とりあえず今は何かな？と思うだけでさらりと流しましょう。

FrameView クラスは JFrame を作るためのクラスのようなものですね。

しかし、FrameView クラスは JFrame クラスを継承せずに View クラスを継承してます。

よって、menu bar, tool bar, component,status bar が View クラスによって作成されます。

これもソースを見れば BorderLayout で配置されているのが確認できます。

あとこの DesktopApplication1View クラスを見ると

helpMenu.setText(resourceMap.getString(“helpMenu.text”)); // NOI18N
helpMenu.setName(“helpMenu”); // NOI18N

とか、

ResourceMap resourceMap = getResourceMap();
int messageTimeout = resourceMap.getInteger(“StatusBar.messageTimeout”);

のような感じのコードとか、

@Action

などがあります。

それ以外のコードは今までと変わりないので問題ないですね。

上記のコードがいったい何なのか楽しみですね（＾＾）

＊注意　この内容は Javadoc を元に調べたもので英語が良く解らない私が勝手に解釈した内容です。

　　　　よって間違っているかもしれません。

今日はノートＰＣを物色してました。

ある量販家電店で買い換え下取りキャンペーンと派手にやっていたので私のコンパック７０１ＪＰでもＯＫかと尋ねたところ

見事に玉砕でした。（＞＜）

店頭にならんでいたノートＰＣをちょっといじらせてもらったがあきらかに私のノートとは比べものにならなかった。

現金値引きは無いに等しく、量販家電店指定のプロバイダと契約をすると割引があったりとか私にはメリットのないものでした。

マイクロソフトのオフィス系のプログラムは要らないのでハードだけで安く売っているものは無いかとみたが、ゲートウェイくらいしかなかった。

これもＯＳは付いてくるようでそれなりに安い値段の設定になってました。

買おうかと思ったが、キャンペーンや抱き合わせセット割引で安く購入する人がいると思うと公平性に欠けるんじゃないかと思いやめてしまった。

やはり、Ｄｅｌｌなどの通販で買うのがいいのかなぁ・・・・・

DesktopApplication1 クラス最後のメソッドを調べてみます。

getApplication() メソッドです。

メソッド名からただのゲッタのようですね。

DesktopApplication1 クラスのインスタンスを返すだけのようです。

これで自動生成された DesktopApplication1 クラスを一通りみたわけですが今までの Swing アプリケーションとは

ずいぶん違ってきてますね。

次は DesktopApplication1View クラスについてみることにします。

＊注意　この内容は Javadoc を元に調べたもので英語が良く解らない私が勝手に解釈した内容です。

　　　　よって間違っているかもしれません。

DesktopApplication1 について調べてきましたが自動生成されたコードも残り僅かになりました。

引き続きみてみましょう。

今回は configureWindow() メソッドについてみてみます。

どうやらリソースインジェクションによって表示を初期化するようです。

引数に java.awt.Window とあるようにアプリケーションのウィンドウが表示される場所と大きさを制御しているようです。

ここで注意なのが最近では一般的になりつつあるマルチスクリーン画面の場合、セカンドスクリーン上でアプリケーションを

終了すると次回の起動はデフォルトの場所と大きさでウィンドウが立ち上がります。

これは java.awt.Window がマルチスクリーンに対応してないからだと思います。

ちょっと残念な気分にさせてくれます（＾＾；

ちなみにいつの間にかワイドスクリーンを購入し、今まで使っていた古い物でマルチスクリーン環境を構築してます。

デスクトップが広いのはいいですね。

おまけにマルチスクリーンだとなおさらです（＾＾）

ちょっと話が逸れましたが今日はこのへんで。

＊注意　この内容は Javadoc を元に調べたもので英語が良く解らない私が勝手に解釈した内容です。

　　　　よって間違っているかもしれません。

ダウンロードしようとしたがサイトにアクセスできない（＞＜）

今日は startup() メソッドについて調べてみます。

前回、main() メソッドの中にある launch() メソッドから呼ばれるということが解りました。

さて、startup() メソッドがどういう役割を果たしているのかみてみましょう。

上記のような簡単なコードが生成されてます。

startup() メソッドは暗黙的に呼ばれている [ main frame ] を作るだけのようですね。

この startup() メソッドをオーバーライドしてGUI 関連のコードを記述すればいいわけですが NetBeans ではshow() メソッド

に渡しているようです。

今回のアプリケーションではDesktopApplication1View クラスを show() メソッドに渡しています。

実際に表示されるウィンドウは DesktopApplication1View クラスにお任せってことでしょうか。

効率的な作りになってますね。

＊注意　この内容は Javadoc を元に調べたもので英語が良く解らない私が勝手に解釈した内容です。

　　　　よって間違っているかもしれません。