Paul KennyからTartan1.05のプレビューがリリースされた。
どうやら、TartanからColdSpringが使えるように、User-defined Factoriesを実装したようだ。
サンプルプログラムもMach-IIの一部が移植されているようなので、じっくりながめてみてから報告します。
Property Manager - tartan.core.PropertyManager
ServiceContext - tartan.context.ServiceContext
User-defined Factories - tartan.core.Factory (abstract base class)
configure() methodFlash Remoting
XmlReaders/Builders
Sample Applications
前回、紹介した資料の最終ページにあるとおり、
Sean CorfieldのColdfusionフレームワーク用サンプルアプリケーションGGCCでファイル数を比較してみると、ModelGlue+ColdSpringのModelGlue+Tartanに対する優位性がはっきりわかります。
Tartanは、サービスコントローラがあり、コマンドcfcを介して、VO/DAO/Gateway/Exceptionなどのモデルcfcにアクセスするため、サービスコントローラやCommandファイルの分だけファイル構成が複雑になります。
したがって、ModelGlueのフットワークの軽さにフィットするのは、ColdSpringになるのかもしれません。
ColdSpringに触れてから、ModelGlue＋ColdSpringの組合せを研究してきたけど、
ここらで一旦
の違いについて整理してみる。
各々の特徴と概観を資料 にまとめてみました。ご参考までに 。
今日は、getMembersについて・・・
init()メソッドで定義したLoacalServiceへのproxyとサービス定義を使って、これに
コマンド名
引数パラメータ（struct)
戻り値（struct)
を定義して、あとはほいっと
<cfset result = proxy.invokeCommand(service, command, args) />
でコールするだけです。
<cffunction name="getMembers" returntype="ModelGlue.Core.Event" access="public" output="false" hint="I return a query object containing all of the members' information">
<cfargument name="event" type="ModelGlue.Core.Event" required="yes" />
<!--- appended for Tartan handling 2005/06/28 By Tomoaki Tanaka --->
<cfset var proxy = GetTartan() />
<cfset var service = getHelloService() />
<cfset var command = "getMembers" />
<cfset var args = structNew() />
<cfset var result = structNew() />
<cfset result = proxy.invokeCommand(service, command, args) />
<cfif structKeyExists(result,"users") >
<cfset arguments.event.setValue("users",result.users) />
<cfset arguments.event.setValue("userByCookie",result.userByCookie) />
<cfset arguments.event.setValue("userByID",result.userByID) />
</cfif>
<!---
<cfif structKeyExists(result,"result") >
<cfset arguments.event.addResult("setIdentitySuccess") />
<cfelse>
<cfset arguments.event.addResult("setIdentityFailure") />
</cfif>
--->
<cfreturn arguments.event />
<!--- Original setting & scripts ggcc7
<cfset var users = 0 />
<cfquery name="users" datasource="#variables.dsn#" username="#variables.dbUser#" password="#variables.dbPass#">
SELECT * FROM ggccuser
ORDER BY firstName
</cfquery>
<cfset arguments.event.setValue("users",users) />
<cfreturn arguments.event />
--->
</cffunction>
modelGlue+tartanは、modelGlueのControllerをシンプルにすることが、重要かなあー。
なぜなら、modelGlueのControllerを複雑にしても、Tartan側のサービスは一つだけだから・・・
それに、ModelGlueからTartanをコールする際にメモリを節約したいよねえ・・・
さて、modelglue.xmlの一例を紹介したところで、controller<userManager>を見てみます。
controller<userManager>は、ModelGlue.Core.Controllerを拡張したものです。
冒頭に、お決まりのinit( )メソッドがありますが、一般的なmodelglueアプリケーションの場合と比較して、tartan連携モデルでは、tartanサービスの呼出し手続きをinit( )で行います。
1.一般的modelGlueアプリケーション
<cffunction name="init" returntype="usermanager" access="public" output="false">
<cfargument name="core" type="ModelGlue.ModelGlue" required="true"/>
<cfset super.init(arguments.core) />
<cfset variables.dsn = arguments.core.getConfigSetting("dsn") />
<cfset variables.dbUser = arguments.core.getConfigSetting("dbUser") />
<cfset variables.dbPass = arguments.core.getConfigSetting("dbPass") />
<cfreturn this />
</cffunction>
2.tartan連携modelGlueアプリケーション
<cffunction name="Init" access="Public" returnType="userManager" output="false" hint="I build a new SampleController">
<cfargument name="ModelGlue" type="ModelGlue.ModelGlue" required="true" />
<cfset var result = "" />
<cfset super.Init(arguments.ModelGlue) />
<!--- Load the config params for the Tartan app we're talking to --->
<cfset result = getModelGlue().getConfigBean("Tartan.xml") />
<!--- Load the Tartan proxy --->
<cfset variables.tartanProxy = createObject("component", "ModelGlue.Util.TartanProxy").init(result) />
<!--- We're going to need the catClub service universally --->
<cfset variables.clubService = getTartan().CreateService("catClub") />
<!--- append from original "init" function --->
<cfset variables.dsn = arguments.ModelGlue.getConfigSetting("dsn") />
<cfset variables.dbUser = arguments.ModelGlue.getConfigSetting("dbUser") />
<cfset variables.dbPass = arguments.ModelGlue.getConfigSetting("dbPass") />
<cfreturn this />
</cffunction>
tartan連携アプリケーションでは、以下の部分をおまじないとして追加すればいいようです。
（ただし、CreateService( ) 内のサービス名をターゲットに応じて変更してください。）
<!--- Load the config params for the Tartan app we're talking to --->
<cfset result = getModelGlue().getConfigBean("Tartan.xml") />
<!--- Load the Tartan proxy --->
<cfset variables.tartanProxy = createObject("component", "ModelGlue.Util.TartanProxy").init(result) />
<!--- We're going to need the catClub service universally --->
<cfset variables.clubService = getTartan().CreateService("catClub") />
次回は、メソッド<getMembers>について、紹介します。
ggcc8におけるevent-handlerとcontrollerの関係を、ggcc.homeイベントを例にじっくり見てみる。
ggcc.homeイベントは、以下のように定義さｒている。
<event-handler name="ggcc.home">
<broadcasts>
<message name="needMembers"/>
</broadcasts>
<views>
<include template="dspShowHome.cfm" name="content">
<value name="XFA.ShowTasks" value="ggcc.showmanager"/>
<value name="XFA.Constitution" value="ggcc.showpage"/>
<value name="XFA.Bylaws" value="ggcc.showpage"/>
<value name="XFA.Minutes" value="ggcc.showpage"/>
</include>
<include template="layGGCC.cfm" name="final"/>
</views>
</event-handler>
ggcc.homeイベントの挙動は次のようになる。
1.<needMembers>リスナーを呼び出し、
2.<dspShowHome.cfm>にいくつかのパラメータを渡しながら、その表示結果を<content>に保存し、
3.最後に<layGGCC.cfm>で端末に表示している。
<needMembers>リスナーはどこで定義されているかと、controllersセクションを見渡すと、
controller<userManager>に"needMembers"がある。
<controller name="usermanager" type="ggcc8.controller.usermanager">
<message-listener message="needMembers" function="getMembers"/>
<message-listener message="choseIdentity" function="setIdentity"/>
<message-listener message="checkIdentity" function="checkIdentity"/>
</controller>
したがって、message<userManager>がブロードキャストされると、userManager.cfc内のファンクション<getMembers>をコールしています。つまり、フレームワーク名：ModelGlueの指し示すとおり、イベントとモデル（ビジネスロジック）を接着することがこのフレームワークの特徴と言えます。
さて、前回のディレクトリ構成とコンフィグ構成に続いて、今日はコンフィグ構造に着目します。まずは、modelglue.xmlから。
1.<controllers>セクション
5つのcontrollerが定義されている。
mailer メール送信マネージャ
taskmanager タスクマネージャ
usermanageｒ ユーザマネージャ
relocator リロケータ
viewConstants キュー完了フォロワー
2.<event-handlers>セクション
13のevent-handlerが定義されている。
ggcc.home デフォルトイベント
ggcc.showpage スタティックページ表示用イベント
ggcc.contact コンタクト問い合わせイベント
ggcc.sendmail メール送信イベント
ggcc.identify ユーザ認証イベント
ggcc.setidentity ユーザ完了イベント
ggcc.showmanager 最新情報表示イベント
ggcc.showtask 最新タスク表示イベント
ggcc.newtask 新規タスク生成イベント
ggcc.savetask タスク保存イベント
ggcc.addtask タスク追加イベント
addnoteandnotify 記事追加＆通知イベント
failure 例外発生イベント
前回、再度紹介したmodelglue+tartanアプリケーション例”ggcc8”について、しばらく解説していきたいと思います。初回は、ディレクトリ構成とコンフィグ構成について紹介します。なお、アプリケーション名とアプリケーションフォルダはともに、ggcc8とします。
１．ディレクトリ構成
ColdFusionのWWWルートフォルダの配下に、modelglue、tartan及びggcc8フォルダを配置します。
cfmx_wwwroot--+---modelglue/
+---tartan/
+---ggcc8/--+--application.cfm
+--index.cfm
+--config/--+--ModelGlue.xml
| +--service.xml
| +--beans/tartan.xml
+--controller/--+--mailer.cfc
| +--relocate.cfc
| +--taskmanager.cfc
| +--usermanager.cfc
| +--viewconstants.cfc
+--view/--+--layGGCC.cfm
| +--dspShowHome.cfm
| +--dspxxxxxxxxx.cfm
| +--exception.cfm
| +--etc.cfm
+--tartan/--+--services/localservice.cfc
+--commands/someCommand.cfc
+--vo/someBean.cfc
+--data/--+--someDAO.cfc
| +--someGateway.cfc
+--exceptions/xxxxxx.cfc
２．コンフィグ構成
ggcc8の配下にあるconfigフォルダに、
1)modelglue用コンフィグファイル：ModelGlue.xml
2)tartan用コンフィグファイル ：service.xml
config/beansフォルダに、
3)tartanマッピング用コンフィグビーン：tartan.xml
を配置します。
次回は、各々のコンフィグファイルについて解説します。
ModelGlueとTartanの連携について、資料 をまとめてみた。
しばらく、このパターンでアプリケーション開発にいそしんでみようと思う。
また、ModelGlueのサンプルアプリケーションの中から、tartan連携アプリケーション：helloWorldをまとめてみた。modelgluetartan_example.txtをダウンロード
SeanCorfieldに紹介された応用アプリケーションggcc8のダウンロードはこちらから、どうぞ！
Tartan1.04がリリースされました。詳細はこちら。
1.unit testsの追加
2.tartan.service.LocalServiceProxy classの追加
RemoteFlashService と RemoveSoapServiceのベースクラスに！
tartan.service.RemoteService classは廃止
3.tartan.service.RemoteService classの追加
MachIIListener classの別機能として追加
4.その他・・・
Sean Corfieldの記事にあったサンプルアプリケーションGGCCをModelGlue＋Tartanに移植してみた。
移植に際してのベースアプリケーションは、GGCC7（ModelGlue）＋GGCC6（FuseBox4.1＋Tartan）。
動作確認済コードは、GGCC8です。興味のある方はこちら
から、どうぞ！
FuseBox4.1＋Tartanの動作環境から大きく変更したポイントは以下のとおりです。
詳細は、ぼちぼちご案内します。
Tartanの公式サイトを訪問してみた。
Tartanとは？を読むと・・・こんな感じかなー。
リリースノートを見ると、Mach-IIのリスナーとして使えるようだ。
また、ロードマップを見ると、FuseBox4.1やFlashRemotingにも対応予定みたい。
ColdFusionMX ７のAsynchronous CFML Eventsもサポート予定。
Tartanのことを調べていたら、Model-Glueにたどり着いた。
確かに、一回目の記事で、Coldfusion用フレームワークのひとつとしてSeanの記事を引用していたのだけど、Model-GlueがTartanの機能を包含しているようだ。
There's been a lot of talk about using ColdFusion Components (CFCs) to seperate presentation layer from business logic. Model-Glue facilitates this by giving you an easier, more powerful way to connect your presentation layer (View) from your business logic (Model). It does this by letting you create what are called "Controllers", and then letting you define how they interact with the presentation layer (We're calling it View from now on!) through a simple XML schema.
Model-Glue also provides a configuration utility for your applications called ChiliBeans. It makes it easy to offload configuration information (like development datasource vs. production datasource) into XML files. More on that in another Quickstart.
Mach-IIの思想を取り入れつつ、Fuseboxの敷居の低さを追求しているのだろうか？もう少し調べてみよう。
CFMX開発とフレームワークをGoogleで検索したら、ここに参考資料がありました。
フレームワークとは？を以下のように述べている。ふむふむ・・・
１．パターン
家づくりを考えろ！
建築様式と建造方法にはどんなパターンがありますか？
２．ルール
やっていいこと、やってはいけないこと、そして最適解。
屋根を地面にある家はないだろう？
３．構造
壁、ドア、窓、屋根の型式を定義しなさい。
産業的に統一されたパターンとルールが、標準ドア（カスタムフィットオプションが可能な）を供給する。
さらに、Coldfusionの３つのフレームワークを以下のように比較している。
１．Mach-II
MVCイベントドリブンベースのcfcフレームワーク
２．Fusebox4.1
簡単、標準、柔軟、自然なｃｆｍフレームワーク
３．Tartan
オブジェクト指向のコマンドドリブンベースのサービス層フレームワーク
なんとなく、個人的な好みとしては、Mach-II＋Tartanかなー。
最近のコメント