気楽に行こう

やはり、あるんだな。
ColdFusion on Wheels
どんなんだろうか。
あ、ColdFusion8 限定。しかも、DBが、SQLServer と、MySQL5 だけだ・・・。

ColdFusion on Wheels をちょっとやってみた。

http://ドメイン/アプリケーションディレクトリ/index.cfm/●●●●/▲▲▲▲?reload=development

?以下（URL引数）は、なしでもよい。

index.cfm で終わる場合、
/cfwheels/config/routes.cfm の最初の addRoute の Route が処理される。
デフォルト状態では、

のみなので、コントローラー main.cfc の welcomeToWheels という関数が処理され、
/cfwheels/view/main/welcomeToWheels.cfm という画面が表示される。

上記ＵＲＬの場合、コントローラー ●●●●.cfc の ▲▲▲▲ という関数が処理され、
/cfwheels/view/●●●●/▲▲▲▲.cfm という画面が表示される。
このとき、routes.cfm の記述は要らないようだ。

最後にある ?reload=development のＵＲＬ引数は、実際にはこのように使うのかわからないが、
こうすることで、application.settings.environment に値を設定できる。
もちろん、この記述をしないのが普通。
この値により、/cfwheels/config/environments/ の中の、それぞれ対応するファイルを読み込むようにできる。
現状、design とか、development、production などだ。

/cfwheels/config/environment.cfm の中で、この値を設定しているいるが、この値を変えても、
初回起動時（アプリケーションのスタート時）にしか変わってくれないので、強制的に変えたいときに使うのかもしれない。

コントローラーの関数内で設定した変数

は、view の画面ファイル内で、
#testValue#
など、そのまま使えるようにしてくれるようだ。
これは、簡単で便利なんだけど、逆に、想定できないようなバグを発生させる危険性もあるだろう。

バージョンが 0.7 ということで、まだまだ、これからのようだ。
ファイルの一覧を眺めても、基本的なことしかできないのかなぁと感じる。
これからに期待ってことで。

ちょくちょく参考にさせてもらってるなんちゃってCF-OOP！で、Model-Glue の次期バージョンの話が出てた。Model-Glue3(Gesture)αリリース！。
なにやら、いろいろと機能が追加されるようだけど、個人的には、Model-Glue3.0の新機能1：イベント自動生成が気になる。
Model-Glue などのフレームワークで一番の（個人的な）不都合は、設定ファイルをＸＭＬで書かなきゃいけないことだと思っている。
そんな不満をある程度解消してくれそうな機能なのではないのだろうか。

例えば、だいぶ前に WebSphere で ＩＢＭ謹製 Studio を使ったときに、設定ファイルは、入力ボックスに各種設定の文字を入れていくようなウィンドウが表示されて、ＸＭＬタグを見ることなく設定できた。
ＸＭＬファイルというのは、慣れていればいいのかもしれないが、経験の少ない開発者にとって敷居が高いものだと勝手に断定している。

一番いいのは、部品をドラッグアンドドロップとかで配置して、グラフィカルにＭＶＣの流れが見えることだと思うけど、そんなのはかなり厳しい話で、WebSphere のようなものが妥当な線なんだと思う。

Model-Glue のイベント自動生成機能は、イベント名を起こすだけで、ある程度の設定をしてくれるということだから、ゼロから設定ファイルを書くのではなく、都度変更すればよいわけだ。
ゼロからと、変更するだけでは、大きな違いがあると思うし、かなり敷居が低くなるんじゃないかと思う。

今までのようにＸＭＬを直接編集するしかないとか、（あくまで個人的に）作業効率が悪いままでは、結局フレームワークというものが、万人向けではなく、特定層向けツールで終わってしまっているというのが現状ではないだろうか。
なにしろ、ColdFusion の最大の特徴である、「未経験開発者の一定レベル到達時間が短い」を打ち消しかねない。
ちょっと言い過ぎた気もするけど、一向に ColdFusion のフレームワークの情報が世の中に増えてこないのは、その辺にあるのじゃないだろうか。
Model-Glue の新機能に期待である。

ColdBox を動かしてみよう。

もう、こんなの

や、こんなの

が表示されるだけで、「おぉ」と思ってしまうのは、よくない傾向だ。
我ながら、つくづく、見た目に騙されやすい。と思う。実際に役に立つ情報が表示されているのかどうかは、謎。

ColdBox 公式から、ダウンロードしてきて、解凍したファイルを WEBROOT に配置。
その中の ApplicationTemplate をコピーして、このディレクトリの名前を適当に変える。

とりあえず、これだけで、先ほどのような画面が表示されるようになる。

ここにあった Eclipse のプラグインのインストールができなかった。
バージョンが europa ではだめなのか、はたまた、Eclipse に色々つっこみすぎているのがいけないのか。

なんだか、ドキュメントの項目だけを見ても、機能がいっぱいあるように見える。
個人的には、Model-Glue のようにシンプル設計がいいと思うのだけど、実際のところは、どうなのか。

Model-Glue で作っていたサンプルアプリケーションを移植してみようとしたら、文字化けした・・・。

前回の文字化けは、ColdBox 上の問題ではなく、Ant 上の問題だった。
やはり、慣れないものを使うときは、慎重にしないといけないということか。

ColdBox のパッケージに含まれる ApplicationTemplate に入っている build.xml を使うときは、

<filterchain>
　<concatfilter prepend="header.txt"/>
</filterchain>

を削除するなり、コメントアウトするなりしよう。

Ant のコピーコマンドは、通常そのままファイルをコピーするのだけど、filter 設定があると、ファイルを開くわけで、その際に、デフォルトではＯＳデフォルトエンコーディングでファイルを開く。
ファイルが異なるエンコーディングで保存してある場合、問題があるわけで、その結果、ファイルを保存することになると、文字化けする。copy コマンドに encoding 属性を付けるという手もある。

また、上記の Ant 設定は、全てのファイルの先頭に、header.txt の内容を挿入するという内容らしい。
その header.txt も、Ant が都度書き出していて、内容は、CFML のコメントになっている。
CFML のファイルだけなら、いいのだが、外部スタイルシートファイルや、JavaScript ファイルにも入れてしまって、結果、エラーが発生する。

こんなことで、半日以上費やしてしまった・・・。

なんとか、Model-Glue 版ショッピングカートを ColdBox 版ショッピングカートに移植完了。
でも、View 周りがなんとなく、汚い気がする。

基本的には、両者とも、ＭＶＣフレームワークなわけで、「とりあえず作ってみました」的なレベルでは、大して差はなかった。

Controller に当たる handler で、設定することなく（Model-Glue は、設定することなく、setter 関数を入れるだけ） AutoWire はしてくれなかったので、handler 上の init 関数などで以下のように、取得する必要がある。

<cffunction name="init" access="public" returntype="any" output="false">
　<cfargument name="controller" type="any">
　<cfset super.init(arguments.controller)>
　<cfset variables.shopping = getPlugin("ioc").getIoCFactory().getBean("shopping") />
　<cfset variables.itemArrayBean = getPlugin("ioc").getIoCFactory().getBean("itemArrayBean") />
　<cfreturn this>
</cffunction>

こうしておけば、handler が初めてよびだされるときに、ColdSpring で設定された Bean を呼び出してくれるのであろう。

また、Model-Glue では、ＸＭＬファイルで処理のフローを設定していたものが、ColdBox では、上記の handler 内でほとんど行うようだ。
ApplicationRoot
　┗handlers
　　┗gengeral.cfc
gengeral.cfc という handler があって、その中に書かれている関数がイベント名になる。
例えば、gengeral.cfc に、CartView という関数があるとすると、gengeral.CartView というイベントを駆動させると、その CartVew 関数が処理される。

あとは、TransferFactory など、AutoWire 関連の記述を書き換えるぐらいでモデルなどのコードは、ほとんど変更しなかった。この辺りは、さすがである。
当然、画面表示周りの部分は、それなりに書き換える必要がある。イベント名の作法が変わるわけだし、画面表示自体の作法が変わる。

個人的な問題として気になることがあった。
開発する際、ＷＥＢサーバー（Windows マシンで、IIS）のドキュメントルートにプログラムを置くのではなく、リポジトリとして決めてある場所にプログラムを保存して、実行は、IIS 上で仮想ディレクトリを設定してある。
プログラムを変更した場合、保存後、すぐに、ブラウザのＦ５リフレッシュで変更結果を確認している。

ColdBox でそのように作成しようとしたら、なぜか、エラーが発生してしまった。設定があるのかもしれないが、わからなかったので、結局、Ant を使って、ＷＥＢサーバーのドキュメントルートに配置していたわけで、結果、前回のようなエラーにも遭遇した。
ColdBox のイメージがちょっぴり悪くなってしまった。もちろん、ColdBox は悪くないのだろう。あくまで、個人的な問題だ。

折角なので、もうちょっと ColdBox をやってみる。

ColdBox は、Eclipse（CFEclipse）で開発することを意識しているようで、いろいろと便利小物を用意してくれている。

以前、インストールに失敗したプラグインが、改めてインストールしたら、あっさり完了した。
これは、ヘルプファイルのようで、

Eclipse 上でヘルプを参照できる。

また、ＷＥＢのルートにインストールした coldbox ディレクトリにある install ディレクトリ内に cfeclipse_dictionary と cfeclipse_snippets がある。
dictionary の方が、コード補完用のファイルで、snippets の用が、スニペット用のファイルとなっている。
コード補完は、あるのとないのでは、全然違ってくるので、ありがたい。
Eclipse のインストールディレクトリにある Plugins / org.cfeclipse.cfml_1.3.1.6 / dictionary に

とコピーして、その場所にある dictionaryconfig.xml を

と変更する。そうすれば、

のようにコード補完してくれる。しかし、cfscript 内の場合は、してくれなかった。

なにか、間違っているか、設定があるのか、「そんなのは、自分で加工しろよ！」なのか。
snippets については、ちょっとした発見（自分が知らなかっただけだけど）があって長くなりそうなので、また、後日。

CFEclipse にある、snippets という機能。
昔々の ColdFusion Studio という開発環境からあった機能だ。Dreamweaver にもあったかなぁ。

さて、ColdBox 用 snippets のインストール。
Eclipse のワークスペースにある .metadata / .plugins / org.cfeclipse.cfml / snippets に cfeclipse_snippets の coldbox ディレクトリを入れる。

いままで入れたことがなければ、keyCombos.properties というファイルがあるだけだろうか。
ちょっと自前 snippets を入れてあるので、いろいろ入っているけど、こんな感じ。
再起動して、ちゃんと Eclipse が認識すれば、こうなる。

次に、cfeclipse_snippets にある、keyCombos.properties で、既存の keyCombos.properties を上書きするのではなく、内容をコピーする。
このファイルの存在というか機能を、今回初めて知ったぐらいなので、空だったから、上書きしても問題なさそうだった。
さて、この keyCombos.properties とは、なんだろうか。
実は、なかなかの優れものだった。今回初めて知ってかなり驚いた。

例えば、switch と入力した状態で、Ctrl + J とキーをたたくと、
このようなダイアログが表示される。

ここで入力して OK ボタンを押すと、

こんな風になるのだ。思わず「おぉ」と声が出てしまった。
snippets とは、本来こういうものだったことを知らなかった。
しかし、この機能が使えない単語で Ctrl + J を押すと、

こういうダイアログが出てしまうのは、どうしたものか。

で、Snippets で ColdBox に関するコードが出てくるというわけで、なかなか便利そうである。
ほしいものがなければ、自分で作れということでもある。
これは、ColdBox ネタというより、CFEclipse ネタか。

さて、そろそろネタも尽きてきた。
ここらで、ColdFusion のフレームワーク利用について、考えてみる。

結果から言うと、使ってもいいし、使わなくてもいいというところだろうか。
やはり、フレームワークとなると、複数人で作業して、かつ、それぞれの技術能力にバラツキがある場合とかじゃないと、かえってマイナスの要因が目立ってしまう。
しかし、読んでみた率直な感想としては、自分一人で開発する場合でも、使ってみてもいいかなと感じる。

ＣＦＭＬが動く環境は、ColdFusion だけでなく、フォーラムにもあがっているように、Railo と、Open BlueDragon というものがある。
どうやら、両者とも、非商用は無料らしい。ということは、商用は有料となる。
Adobe 製 ColdFusion ではなく、Railo や、Open BlueDragon を選択する理由とは、なんだろうか。
Servlet を動かせるようだから、Java とのさらなる親和性かなぁ・・・。よくわからない。

さて、とにかく、Railo を動かしてみた。
結果的に、これまで作ってきた Model-Glue や ColdBox のアプリケーションは、見事、撃沈。
動いてくれなかった。フレームワーク上で発生している問題っぽい。
深くは調査しなかったので、何か方法があるのかもしれないけど、あっさりあきらめました。ごめんなさい。
残念な結果に終わってしまった。

CFEclipse を導入する際に、ずっと気になっていたけど、

こんな風だし、

右クリックで、“構成”を選択すると、

こんな警告出るし、

こんなウィンドウが表示されるだけで、なんなんだよ、これ。って感じで、放置していた CF Frameworks Explorer 。

でも、ここ の「08 CF Frameworks Explorer Introduction」を見て、一気に解決。