なんちゃってCF-OOP！

CFMX開発 Mach-II vs FuseBox

Mach-IIとFuseBoxの領域モデルについて、Hal Helms とJeff Petersが熱く語っているサイトの内容をゆっくり熟読してみた。
広くCFMX開発者で認識されている

Mach-I I ⇒ OO(Object Oriented)
FuseBox ⇒ Procedual

ではなく、

Mach-I I ⇒ 厳密なOO　　　　
　　　　　　　⇒ OOを熟知したOOPが必須
                 　⇒　敷居が高い
FuseBox ⇒ ゆるやかなOO
                ⇒ OOを熟知していなくても、OOPもどきができる
                 　⇒　敷居が低い

ということのようだ。
ブログの記事をハックして表示するためのサンプルプログラムを作りながら、比較してみよう。

CFMX開発 Tartanとは？

Tartanの公式サイトを訪問してみた。

Tartanとは？を読むと・・・こんな感じかなー。

リリースノートを見ると、Mach-IIのリスナーとして使えるようだ。
また、ロードマップを見ると、FuseBox4.1やFlashRemotingにも対応予定みたい。
ColdFusionMX ７のAsynchronous CFML Eventsもサポート予定。

1. Tartanは、ColdFusion MX 用のコマンドドリブンのサービスフレームワーク
2. 機能性の完全分離かレイヤリングを指向する大規模なアプリケーションアーキテクチャのサービスレイヤを開発を手助けするもの
3. ビジネスロジック配下に対する全てのアクセスは、ローカルアクセスのCFCsとリモートアクセスとしてのFlash RomortingおよびSOAPウェブサービスにアクセス可能なパブリックサービス(public service)に制御される。
4. ひとつのサービスは、いくつかのコマンドで構成され、各コマンドはアプリケーションにおいて、ある分離された機能を実装している。
5. 各コマンドは、アプリケーションのコアロジックを包含している。
6. 各コマンドは、DAOsを介してデータベースと通信し、クライアントから受信したデータを取り扱い、他のコマンドを実行し、他のリモートサーバ上で利用可能なサービスと通信することができる。
7. Tartanには、６つのコアクラスがある。
   • Core Clases
   • RemoteService
   • LocalService
   • Command
   • DAO
   • VO(Value Object)
   • ExceptionHandler
8. 6つのコアクラスは、フレームワークの主要機能を提供し、アプリケーション開発者によって継承可能。

 

CFMX開発 Fusebox4.1 with Lexicon

Fuseboxのサブフレームワークとして、'Lexicon'がリリースされていた。
Fuseaction毎のView表示に異なるスタイルシートを適用するためのようだ。

CFMX開発 フレームワーク比較表２

CFMX用フレームワーク比較表で、Fusebox、Mach-II、Model-Glueの比較をしていたことを思い出して、もう比較表を見直してみました。
やっぱり、Fuseboxは敷居の低さ、Mach-IIはプロフェッショナル用、Model-Glueは両方のいいとこ取りって感じです。

各比較項目のうち、1行目は共通点、2行目以降は差異点です。
（以下、各フレームワークの略称　FB:Fusebox/M2:Mach-II/MG:Model-Glue）

・XML
All use XML config files
FB has multiple XML,  M2/MG has one XML
・MVC
Can use MVC
FB allows but does not enforce, M2/MG pretty much forces it
・MVC Structure
Model/View directories
FB typically has controller circuit directory, M2/MG has implicit controller in framework
・CFCs
Can use CFCs
FB allows but does not enforce, M2/MG pretty much forces it
・Plugins
All have plugin points
FB has more plugin points, M2 distinguishes events and views, MG has simple request/queue model
・Access control
All have private / public concepts
FB has per circuit and per fuseaction as well as roles-based model, M2/MG has per event access only
・Auth / Security
None
FB has roles support builtin, M2 provides a sample filter, MG is free form
・Install / Config
One-stop core files, basic properties in XML file
One-stop core files is brand new in FB41, FB provides finer control over framework behavior, MG has a simple framework control model
・Modularity of Application
None
FB has circuits to partition large applications
・Modularity of Site
None
M2 allows multiple sub-applications to share application scope
・Commonality
Can explicitly invoke fuseactions / announce events / add results to handle common functionality  FB has per-circuit pre-/post-fuseaction hooks, providing framework level support for commonality
・Views
All encourage views to contain “only HTML” (no logic)
FB/MG lets you include a view directly, M2 requires that you declare all views in XML
・Handler Model
All declare 'handlers' for 'events' in XML
FB is a static, explicit invocation model, M2 is a dynamic, implicit invocation model, MG is somewhere in between
・Data bus
Can use request scope as data bus (but it's not always best practice) – MG uses event object  　FB allows variables scope as data bus, M2 allows event object as data bus, MG enforces event object as data bus
・Global data
None
FB has fusebox.init.cfm, M2 uses either 《property》 tags or plugin (or both), MG has settings
・Model CFC Structure
Most CFC methods could be the same
FB uses standard init() construction controlled by explicit code in fusebox.init.cfm or circuit, M2 reserves init() and uses a managed configure() method to initialize CFCs – with no arguments – and CFCs must extend the framework, MG has base controller init() method
・Conditional logic
None
FB has some conditional logic in the XML grammar, M2 requires conditional logic placed in CFCs, MG requires controller CFCs
・Model Actions
All have the concept of separating business model logic from presentation logic
FB allows a model action to set multiple outputs, M2 uses strict call/return semantics so each action can have only one result, MG allows a model to set multiple outputs via event object
・Model Queries
None
FB specifically separates out persistence operations (by a naming convention on files), M2/MG draws no distinction between actions and queries

ちょっと長かったかな？

CFMX開発 Model-Glue

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開発 フレームワーク論

CFMX開発とフレームワークをGoogleで検索したら、ここに参考資料がありました。
フレームワークとは？を以下のように述べている。ふむふむ・・・

１．パターン
家づくりを考えろ！
建築様式と建造方法にはどんなパターンがありますか？
２．ルール
やっていいこと、やってはいけないこと、そして最適解。
屋根を地面にある家はないだろう？
３．構造
壁、ドア、窓、屋根の型式を定義しなさい。
産業的に統一されたパターンとルールが、標準ドア（カスタムフィットオプションが可能な）を供給する。

さらに、Coldfusionの３つのフレームワークを以下のように比較している。

１．Mach-II
MVCイベントドリブンベースのcfcフレームワーク
２．Fusebox4.1
簡単、標準、柔軟、自然なｃｆｍフレームワーク
３．Tartan
オブジェクト指向のコマンドドリブンベースのサービス層フレームワーク

なんとなく、個人的な好みとしては、Mach-II＋Tartanかなー。

CFMX開発 Fuseboxドキュメント

Fuseboxの日本語ドキュメントを探したら、ここにありました。

Fusebox メソドロジー

FuseboxとMach-IIを比較すると、こんな感じかなー。

Fusebox　ｃｆｍベースのフレームワーク（シロウトさんもOK！）

Mach-II　　cfcベースのフレームワーク（プロ向け！）

CFMX開発 Fuseboxって？

Fuseboxの本家は、ここなんだけど、googleで国内サイトを検索したら、リンコムのテクノロジー紹介に、Fuseboxの記事が載っていた。
>岩上さん、わかりやすい紹介ありがとうございます。

それによると、

【Fuseboxの設計手法上の特徴】
Fuseboxが提供しているものは単にプログラム設計手法だけでなく、ドキュメンテーションなど多岐に渡っています。ここではそのうち、「リンコム ネクスト 2」が採用しているプログラム設計手法に的を絞って説明していきます。

Fuseboxの設計手法上の特徴は大きく分けて以下の2つがあります。
    （1）プログラムのモジュール化/コンポーネント化
    （2）役割に応じたプログラムファイルの分割

とFuseboxの特徴が紹介されていて、
1)プログラムののモジュール／コンポーネント
では、cfmプログラムをヒューズボックスのように、多段構成的にディスパッチすることから、Fuseboxというフレームワーク名となったことが書かれてあった。ふむふむ・・・・
2)役割に応じたプログラムファイルの分割
では、cfmファイルを役割に応じて使い分ける手法がとられているとのこと。

ファイルの役割分担

・Displayファイル
    主に画面に表示するHTMLを記述したcfmファイルです。このファイルの中には極力ロジックの記述は避け、CFOUTPUTのような変数内容を表示するタグのみを記述するようにします。
    ファイル名は「dsp_***.cfm」というフォーマットになります。

・Actionファイル
    画面に表示する内容は含まず、プログラムロジックを記述したcfmファイルです。
    CFMLの表示をつかさどる機能を持ったタグ以外のほとんどのタグは、このファイル内に記述します。ただし以下に示すように、CFQUERYやCFLOCATIONは特別なファイルに分けて記述する場合があります。
    ファイル名は「act_***.cfm」というフォーマットになります。

・Queryファイル
    CFQUERYタグを使ってデータベースへアクセスする部分を切り出したファイルです。こうすることによって、同じクエリー文があったときにはQueryファイルをインクルードするようにすれば、クエリー文の再利用性が高まります。
    ファイル名は「qry_***.cfm」というフォーマットになります。

・Redirectionファイル
    CFLOCATIONタグを使って画面を遷移させる部分を切り出したファイルです。こうすることによって、モジュールを再利用した際に利用者が意図しない画面遷移が起きてしまうのを防ぎやすくなります。
    ファイル名は「url_***.cfm」というフォーマットになります。

４つのファイルは、各々DIsplay（View)、Action（Controller)、Query（Model)、Redirection（View)というように、MVCライクに使われるようです。ふむふむ・・・・

ちなみに、リンコムネクスト２は、Fuseboxの開発手法を取り入れているそうです。

CFMX用フレームワークの比較表

昨日の続き・・・
CF用フレームワークの比較表をSeanが作成していました。

CFMX開発者から、熱いコメントが寄せられているが、SeanはFuseBoxをもっとも支持しているようだ。

Roger Lancefield がそれにフォローする形で、以下のコメント。

Something else that I think would be very interesting for Fuseboxers (in particular), both more and less experienced, would be an analysis of the degree to which Fusebox applications can approximate the structural features of Mach-II applications, and in which areas it makes any sense to do so.

Roger Lancefieldは、CFMX開発には３つのスタイルがあると言っている。
　Fusebox
　Fusebox+Tartan
　Mach-II（'fat'Listnersスタイルと'thin'Listnersスタイル）

I'd say there are far more than two approaches to developing Fusebox applications. In my frameworks talk, I cover specifically three different styles of Fusebox application and then show a variant of one of those (using Fusebox with Tartan). I also show two Mach II styles (one with 'fat' listeners, one with 'thin' listeners and a separate business model).

もう少し、様子を見てみよう。

CFMX開発日記はじめよう！

会社の業務支援ツールを作るのに、何気に手にしたColdFusion(CF)のテキスト本・・・

『ColdFusionMXプロフェッショナルガイド』（奥川博司・須賀正明共著）

社内の業務ツールとかコソコソ<コツコツではない（爆）>作りながら、
日本のJCFMLで語られないCFのオブジェクト指向開発やフレームワークについて、
備忘録的に書き綴ってみたいと思う。

ということで、本日の話題は、CF用フレームワークについて・・・・

Sean Corfieldのブログサイトを除いてみると・・・・

    *  Traditional Fusebox
    * MVC Fusebox
    * OO Fusebox
    * Simple Mach II
    * Refactored Mach II using design patterns
    * Fusebox + Tartan
    * Model-Glue

なるフレームワークがCFにはあるそうな・・・・
個人的には、Mach-IIに興味を持ってきたが、こんなにあると何が最適解かわからなくなる・・・・

まあ、ぼちぼち考えていきます。