気楽に行こう

ColdFusionに、フレームワークが必要なのかどうかわからないけど、とりあえず、読んでみよう。
Model-Glue、ColdSpring、Transferの組み合わせで、何が便利なのか、確認。
Reactorではなく、Transferなのは、APIドキュメントに、“Transaction”があって、「トランザクションの記述が簡単なのかな？」と思っただけのこと。
実際には、その辺りについては、あんまり変わらないみたいな気がしてきている。
Transferの方が、いろいろと、ごてごて機能満載な感じがしている。

さて、フレームワークというものは、ちょっと動くものを作ってみようということが、なかなか難しい。
いろいろと、やらなきゃいけないことが多くて、「フォームでポストリクエストを受け取って、画面に表示」ということだけでも、めんどくさいだけにしか感じない。
こういったことは、ColdFusionの手軽で、軽快な作業性とは、大きく反している。
フレームワークの利点ってのは、巨大なプロジェクトで、大人数が作業する際に、真価が発揮されると思っているんだけど、そういったあたりも、確認できればいいな。

Model-Glueの設定ファイル“ModelGlue.xml”を見ただけでも、ちょっと引いてしまったのは、内緒。
ここで重要なのは、イベントと、メッセージだろうか。
イベントとは、文字通り、リクエストなどのイベント。URLの後ろに“event=＜イベント名＞”と付けたりする。
そうでなくても、構造上は、イベントは、“ModelGlue.xml”で任意に発生させることができる。
で、メッセージは、コントローラーへ処理を渡す際に発生させるという感じだろうか。
イベントは、そのメッセージを発生させたり、画面遷移させたり、追加でイベントを発生させたりできる。
メッセージは、単に、“function”を実行させるだけという認識でいいのではないだろうか。

もちろん、この２つ以外にも、Model-Glueには、色々な概念があるけど、一つ一つ、確認していかないと、混乱してしまうから、まずは、ここまで。

では、Model-Glue において、イベントやメッセージが発生した場合に何が引き起こされるのだろうか。

メッセージは、コントローラーが引き受けるもので、その挙動は、ModeGlue.xml の
　modelglue
　　controllers
　　　controller
　　　　message-listener
に定義されている。
メッセージは、メッセージリスナーが受け取ることになる。
メッセージリスナーがメッセージを受け取ると、messege-listener の messege 属性に一致するメッセージを探して、
その function 属性に設定されている関数が実行される。
関数は、modelglue => controllers => controller の type 属性に指定してあるコントローラー内に定義されている。

イベントが発生した場合の振る舞いは、ModelGlue.xml の
　modelglue
　　event-handlers
　　　event-handler
に定義されている。

イベントが発生すると、event-handler の name 属性の中から一致しているものを探す。
そこで定義されている、broadcasts、results、views が処理される。
broadcasts は、message 子要素を持ち、メッセージを発生させる。
results は、result 子要素を持ち、追加的にイベントを発生させる。
result 要素は、name 属性を設定することができるが、設定されていない場合は、常に、do 属性のイベントが発生し、
設定されている場合は、コントローラー内で addResult() 関数によって登録された name が存在する場合に、イベントが発生する。
views は、include 子要素を持ち、文字通り、ユーザーが受け取る画面を構成する情報を指定する。
include は、画面のどこ（name 属性）に、どのファイル（template 属性）による情報を表示するかを指定する。
また、include は、value 子要素を持ち、value 要素は、画面を構成する際に必要となる引数を設定する。

これらの振る舞いがどのような順番で処理されるかははっきりわからないが、ロジックを処理するために
コントローラーへメッセージを渡し（broadcasts）、画面のベースとなるテンプレート（html、head、bodyタグで構成される）を
書き起こし（results）、各画面ごとに異なる情報や、ロジックになどにより処理された情報などを表示（views）するという
流れで、サンプルが作られているようだ。

イベントは、どうやって発生させるのだろうか。
方法は、二通りあるようだ。
一つめは、以前にも書いたように、event-handler の results => result 要素で発生させる。
二つめは、さらに、以前に書いたように、「URLの後ろに“event=＜イベント名＞”」として、リクエストによって、発生させる。
このイベント名がそのまま、発生するイベントとなっている。

この“event=＜イベント名＞”を省略した場合は、どうなるのか。
http://～～～/～～～/index.cfm とした場合である。
どうやら、ColdSpring.xml で定義されている、

　<beans>
　　<bean id="modelGlueConfiguration" class="ModelGlue.unity.framework.ModelGlueConfiguration">
　 　<property name="defaultEvent"><value>page.index</value></property>
　　</bean>
　</beans>

page.index が発生するらしい。
確かに、“イベント指定なし”と“event=page.index”では、同じ挙動になる。

他にも、exception
とあるように、エラーが発生すると、exception というイベントが発生するようだ。

この部分を見つけるまで、ColdSpring.xml の modelGlueConfiguration は、あまり注意してみていなかったけど、どうやら、
結構重要らしい。

サンプルなどを見ると、このイベントをリンクなどのURLに指定する際に、画面表示プログラム埋め込み文字列ではなく、
views => include => value で引数として画面表示プログラムへ渡している。
果たして、これにどれほどの意味があるのかわからないけど、引数の渡し方は、ここから、わかる。

この“xe.cartinsertitem”が引数の変数名で、“CartInsert”がその値となる。
“xe”という単語が気になるが、“eXit Event”を示しているらしい。
ただし、この“xe”という単語が機能上特別な意味を持っているのかは、わからなかった。

では、画面側で、それらの値を受け取る場合は、どうなるのか。
viewstate.getValue("xe.cartinsertitem")
とすることで、値を受け取れる。
viewstate というのは、コントローラーなど、ロジック上から、値を渡す場合などにも、この空間？に設定されるものである。

また、myself や、self という予約後もあり、viewstate.getValue("myself") とすると、
リクエストページが index.cfm の場合「index.cfm?event=」という値を得ることができる。

前回、viewstate というものの読み解いた。似たような単語で、viewcollection というものがある。
前者が view の state 状態ということであれば、後者は、view の集合となるのだろうか。余計わかりにくいか。

画面表示プログラム上で、viewcollection.getView("body") としてやることで、画面表示を埋め込むことができる。
event-handler => views の要素、include で画面に埋め込むプログラムを設定する。
<include name="body" template="dspCart.cfm" />

viewcollection.getView("body") に、dspCart.cfm が埋め込まれるわけである。

viewcollection.getView("body")この記述は、event-handler の results => result 要素で生成した画面上でしか、
機能しなかったが、実際のところは、どうなのだろうか。
動いてくれると、便利なんだが。

コントローラーから画面に値を渡す場合は、どうなるのか。
viewstate で受け取れるようにする方法である。
<cfset arguments.event.setValue("cartData", cartData) />
こうすることで、cartDate という変数の cartDate という値を渡すことができる。
arguments.event というのは、重要な概念で、HTTP でいうところのイベントを意味している。
これは、リクエストも、レスポンスも含んでいるようである。

つまり、レスポンスで画面に値を渡すわけであるから、レスポンスというイベントに値を設定（setValue）するということである。

わかりにくいかもしれないが、ポストリクエストのポストデータを受け取るときも、このイベントを利用する。
<cfset var itemId = arguments.event.getValue("itemid") />
こうすることで、フォームの itemid という値を取得することができる。

このイベントは、コントローラー上でのみ、扱える空間のようだ。
もちろん、引数などで渡してやれば、どこでだって使えるのであるが、コントローラー上では、イベントを受け取ることを
書いてしまえば、受け取ることができる。
他にも、コントローラ上でのみ扱える ModelGule API とか、コントローラーは、いろいろ便利に使えるようである。

サンプルアプリケーション
これまでの情報から、ものすごくシンプルなアプリケーションを作ってみた。
商品リストから商品を選んで、カートに入れるというよくあるカートアプリケーション。

作成したイベントは３つ。

　CartInsert
　CartDeleteItem
　CartDeleteAll

メッセージは、４つ。

　ItemList
　CartInsertAction
　CartDeleteItemAction
　CartDeleteAllAction

これらは、ModelGule.xml から見つけることができる。
Controller.cfc に、メッセージに対応する関数を一つずつで、４つの関数。
ロジックとして、CartProcess.cfc に、ロジックの関数として３つ。
データベースを使わなかったために、商品リストを保持する Common.cfc を作成。

やはり、これぐらいの規模の仕組みでは、フレームワークのメリットを感じることはできなかったが、Model-Glueの基本的な作り方は、把握できた。

dspIndex.cfm で商品リストを表示する際に、Controller.cfc の getItemList 関数で、変数 itemMasterArray に、
arguments.event.setValue("itemMasterArray", ★商品の一覧データ★)で、レスポンスデータに保存。
dspIndex.cfm の viewstate.getValue("itemMasterArray") で商品の一覧データを取得する。

商品を選択すると、イベント CartInsert で、商品ＩＤをポストリクエスト送信すると、メッセージ CartInsertAction が発生する。
Controller.cfc の関数 cartInsertItem によって、ロジックのモデル CartProcess.cfc のインスタンスを生成し、
arguments.event.getValue("itemid") でポストデータ itemid を取得して、関数 insertItem に渡す。関数 insertItem からは、
カートのデータが戻ってくるので、arguments.event.setValue("cartData", ★カートのデータ★) で、画面に変数 cartData で渡す。

他のイベントの場合も、似たような感じになっている。
いわゆる、ＭＶＣが構築されているわけになるが、当然、理想は、理想で、実際にシステムを作っていく上では、
こんなにきれいに分かれないだろう。
ここでポイントになるのは、ＶとＣの流れの調整を ModelGlue.xml だけで行うということだろうか。
ModelGlue.xml では、Ｍのモデル（ロジック）部分のことは、制御外になっている。コントローラーの先は、作り手次第になっている。

ColdSpring を活用してみよう。
すでに ColdSpring の機能である、“ＤＩ”というものについての記述は、たくさんあるので、どのように使うかを見ていく。
よい題材が思いつかなかったので、Common.cfc で生成していた商品リストを「強引に」ColdSpring でやってみよう。
ColdSpring.xml に下記のように記述する。

　<bean id="itemArrayBean" class="shopping.model.ItemArrayBean">
　　<property name="itemArray">
　　　<list>
　　　　<map>
　　　　　<entry key="name"><value>光学式マウス</value></entry>
　　　　　<entry key="price"><value>2600</value></entry>
　　　　</map>
　　　　<map>
　　　　　<entry key="name"><value>ボール式マウス</value></entry>
　　　　　<entry key="price"><value>1100</value></entry>
　　　　</map>
　　　　<map>
　　　　　<entry key="name"><value>レーザー式マウス</value></entry>
　　　　　<entry key="price"><value>4800</value></entry>
　　　　</map>
　　　</list>
　　</property>
　</bean>

ここで注意しなければならないのは、Model-Gule は、ColdSpring.xml などのファイルを、ＯＳのデフォルトエンコーディングを前提に
読み込んでいるらしく、Windows で動作させる場合は、Shift_JIS で保存しなければ、文字化けしてしまった。

　<?xml version="1.0" encoding="UTF-8"?>

としても、だめだった。他のＯＳでは試していないので、あくまで、推測である。
自動で判別してくれるとか、先頭行をチェックしてから読み込むということは、してくれないようである。

shopping.model.ItemArrayBean は、商品リストデータを保持するコンポーネント。
Java でいうところの、Bean ということになる。ColdSpring でも、この Bean という単語を採用している。
デフォルトでは、リクエストごとに、インスタンスが生成されているようだ。
固定値を保持するような Bean は、アプリケーションで１インスタンスでいいのだから、何かしら、やり方があるのだろうか。
singleton とかの記述もマニュアルにあるし、できそうな雰囲気もあるが、試していない。

では、実際に、これを利用するためには、どうすればよいのか。
コントローラーでは、非常に簡単に利用できる。
getModelGlue().getBean("itemArrayBean") これだけで、取得できてしまうのである。
Controller.cfc にある、onRequestStart 関数に
<cfset variables.itemArrayBean = getModelGlue().getBean("itemArrayBean") /> とすれば、Controller.cfc 上では、いつでも、利用可能になる。

また、あたかも、AutoWire のように、

　<cffunction name="setItemArrayBean" access="public" returnType="void" output="false">
　　<cfargument name="itemArrayBean" type="any">
　　<cfset variables.itemArrayBean = arguments.itemArrayBean />
　</cffunction>

としてやるだけでも、取得できてしまう。
「あたかも、AutoWire のように」としたのは、ColdSpring.xml の bean タグに、AutoWire の設定することなく、
setter 関数が処理されたためにこのような表現をした。コントローラーは、本当に特別なもののようだ。
AutoWire については、また、後日、読み解いてみたい。

さて、たびたび出てきた AutoWire とは、何か。
ColdSpring のドキュメントによると、

The term "autowire" refers to the ability of the ColdSpring beanFactory to automatically wire dependent objects together without necessarily having to define those dependencies in the xml bean definitions.

とある。
簡単に言うと・・・、説明は止めておこう。実際に、どのように動くのかを見た方がわかりやすい。
検索すれば、AutoWire も、いっぱい出てくる。もちろん、ColdSpring での情報は少ないが。

前回、

　<bean id="shopping" class="shopping.model.CartProcess">
　　<property name="itemAB">
　　　<ref bean="itemArrayBean" />
　　</property>
　</bean>

このような記述をした。
ColdSpring.xml の Bean は、基本的にリクエストごとに、初期化される。
shopping.model.CartProcess を初期化する際に、setItemAB 関数を探して、引数として、itemAB という名前で、itemArrayBean を
渡して処理しなさいということであった。

AutoWire を使えば、この記述が以下のように簡単になる。

　<bean id="shopping" class="shopping.model.CartProcess" autowire="byName" />

autowire="byName" をautowire="byType" とすることもできる。
要するに、Bean を受け取りたい側（この場合は、CartProcess.cfc）で、setter 関数を記述さえすれば、取得できるわけである。

byName と、byType は、どう違うのか。名前と型なわけで、全く違うわけだが、byName であれは、setItemAB と名前で探すのに対し、

<bean id="shopping" class="shopping.model.CartProcess" autowire="byType" />


<cfargument name="itemArrayBean" type="shopping.model.ItemArrayBean" />

byType の場合は、setter 関数の名前は set で始まっていればよく、引数の受取の型指定が一致しているものを探すわけである。

同じ型で複数の Bean を作りたい場合には、byName にすることになるだろう。
byTypeの方は、すでに setter 関数があって、名前が重複してしまった場合などに利用することになるだろう。

基本的には、好みで決めればいいのだろう。byType の方が、好みだ。

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

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

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

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

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

サンプルアプリケーションは、データベースのトランザクション処理ができていない。
こんなアプリケーションが許されるわけはないので、トランザクションを実装しなければならない。
トランザクションはどのように実装するのか。

やり方としては、コンポーネント内の指定した関数を丸ごとトランザクション処理するというイメージになる。
shopping.model.CartProcess の transfer.TransferFactory を AutoWire したタイミングで、transfer.TransferFactory から transfer.com.sql.transaction.Transaction を取得する。

<cffunction name="setOrmService" access="public" returntype="void" output="false">
　<cfargument name="ormService" type="transfer.TransferFactory" required="true">
　<cfset variables.transfer = arguments.ormService.getTransfer() />
　<cfset variables.transaction = arguments.ormService.getTransaction() />
</cffunction>

その Transaction を利用して、

　<cfset transaction.execute(component, methodName, [arguments]) />

と、直接的に関数をトランザクション指定で起動することもできる。
直接指定の場合は、その関数を利用するときに、上記の記述で利用することになる。

また、ＡＯＰのように記述して、関数を指定することで、指定した関数が丸ごとトランザクション処理されるようだ。
この記述の場合は、事前に行っておくことで、その関数を通常のように利用した場合でも、トランザクション処理されることになる。

<cffunction name="setOrmService" access="public" returntype="void" output="false">
　<cfargument name="ormService" type="transfer.TransferFactory" required="true">
　<cfset variables.transfer = arguments.ormService.getTransfer() />
　<cfset variables.transaction = arguments.ormService.getTransaction() />
　<cfset variables.transaction.advise(this, insertItem) />
</cffunction>

さらに、

　<cfset arguments.transaction.advise(this, "^save") />

と、正規表現で一括してトランザクション処理指定もできる。
トランザクションで処理したい関数を save で始まる関数名にしておけば、簡単に一括指定できる。

なんとか、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 は悪くないのだろう。あくまで、個人的な問題だ。

Model-Glue の Eclipse 用のコード補完設定ファイルを作ってみた。
modelglue.xml
インストールの仕方は、以前のエントリを参照。

また、関数へのマウスオーバーでポップアップするヘルプを公式ドキュメントから抜き出して日本語訳してみたが、間違いもあるだろう。
仕様として、同じ関数名があると後に定義されたヘルプが出てしまうようなので、同じ関数名は、属するオブジェクトを連ねて表示し、両対応の当たり障りのない（中途半端な）ヘルプ文章にした。

以下、ちょっと用語解説。

まず、前回の modelglue.xml をちょっと更新した。
ファイル modelglue-02.xml 。念のためファイル名は変えておいた。コード補完部分は変わっていない。

では、今回の本題。Scaffold という機能もなかなか便利。
サンプルアプリケーションでいうと、Transfer.xml に記述してあるオブジェクトを指定して Scaffold を設定すると、そのオブジェクトのデータ管理ができる機能が自動で生成される。
以下のように ModelGlue.xml に一行付け加えるだけで、その機能ができてしまうのである。

<event-handlers>
　……
　<scaffold object="master.Item" />
</event-handlers>

で、http://localhost/shopping/index.cfm?event=master.Item.list にアクセスすると、そのテーブル内のデータが表示できる。

Scaffold には、用意されたデザインではなく、自由にデザインを変更できる機能がある。
これを使えば、もしかすると、本番システムにおいても利用できる機能なのかもしれない。

ここらで、基本的なところに戻って、ColdSpring.xml の先頭にある、
<bean id="modelGlueConfiguration" class="ModelGlue.unity.framework.ModelGlueConfiguration">
を見ていこう。

ここでは、Model-Glue の各種設定項目を、ＤＩコンテナである ColdSprng で設定しているということになる。
設定できる項目は、以下の通り。

Google Groups に参考になるスレッドが上がってた。
addXXXObserver(component), where to call? is singleton required?
そこからのリンクMy Take on Transfer ORM Event Model - BeforeCreate Example 。
Observer の登録の仕方だ。これを参考にすると、すっきりした。

もともと、無精なものだから、どうにも Transfer の Generated Methods の入力が煩わしい。
多少でも楽になればと思い、ちょっとツールを作ってみた。
これを使えば、

こういう風に、一覧で利用できる関数を表示してくれる。

ColdSpring のドキュメントに Remote Facades という項目がある。
これも確か、デザインパターンで見たような気がする。
便利なサイトがあったので、参考にさせてもらった。ありがたい。
なるほどなるほど。
実際の実装にはここを参考にさせてもらった。

で、とりあえず、http://localhost/shopping/model/ItemArrayBean.cfc?method=getItemArray にアクセス。

コンポーネント [[リポジトリ]]\shopping\www\model\ItemArrayBean.cfc のメソッド 'getItemArray' はリモートでアクセスできません。

cffunction の access 属性が public なのだから当然。

Transfer を使っていると、何か問題があったときに、どこがいけないのか、本当にわかりにくい。
たいていの場合は、Transfer.xml の書き方が間違っている場合が多いのだけど、実際にどんなクエリを発行しようとしてエラーになったのか、どんなクエリを発行したのか。

以前のエントリーで、Railo に見事撃沈された我がサンプルアプリケーション。
その Railo が正式リリースされたと聞いたので、もう一度、動作確認してみた。

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

こんな風だし、

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

こんな警告出るし、

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

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