Coldfusion - the Best Practice sdc 技術研究会 Coldfusion user Group いまい ※ featuring Coldfusion MX7

Coldfusion  概要  Adobe システムズ産  最新バージョンは【 Coldfusion 8 】  つまるところは  Application framework / Application server

Coldfusion  概要続き  実装言語  CFML / ActionScript  仕様  JavaEE 準拠 .NET 上でも稼動可能。（ 8 から？）  Apache / MS-IIS の上で稼動する。

Operating System JavaEE 準拠 Coldfusion Web server (Apache / IIS) Application server (JRun) Coldfusion Engine ざっくりアーキテクチャ・モデル

Coldfusion の特徴 １．良い部分  Ｊａｖａライブラリが使用可能。 .NET/JavaEE などの Platform に依存しな い。  PDF の生成など取扱いが容易。  なにげに一番の目玉かも。  Flash との親和性が高い。

Coldfusion の特徴 ２．悪い部分  サーバが有償。  開発環境は無償。  適当な IDE がない。  Dreamweaver はあるけど有償だし。  CFEclipse→Eclipse3.3(Europa) で稼動しない事を確 認済 orz  結局、 HTML/JavaScript からは逃げられない。  Flash を使うにはイマイチ「お得感」がない。  でも、おかげで Ajax とか使える。  OSS:ajaxcfc とか  Coldfusion8 からは標準装備。

Coldfusion の特徴 ２．悪い部分  MS-Excel をサポートしてない。  まぁ当然。  ドキュメントが不足気味。  Web 上では少ない。  書籍も少ない。  ・・・個人的には、 CFML リファレンスで十 分だと思うケド。

Coldfusion の特徴 ３．微妙な部分  OSS ではない。  テクノロジーが隠蔽されている、というセ キュリティ要素がある。  本当に知りたいことは調べようがない。  実は ”cfusion.jar” なんてあったりするから、 jad で デコンパイルすると何かつかめるかもｗ  言語仕様が簡単。  後述！

CFML  スクリプト言語  タグで記述。  大文字 / 小文字を区別しない。  WindowsOS 上ではね。  Linux 上だと当然区別する。  動的プログラミング言語  ・・・と、一般には認知されている。  要は java.util.Map の ConcreteClass が全てを支配して いると思えば良い。

CFML （実装例） ■ ローカル変数の宣言 --JavaScript var operand; --Java char operand; --CFML ■ 単純な文字列比較 --JavaScript var operand1 = “test”; var operand2 = “test.”; var result = (operand1 == operand2) --Java String operand1 = “test”; String operand2 = “test.”; boolean result = operand1.equals(operand2); --CFML ■ テーブルの記述 --HTML No Title ＊ループ＊ ＊カウンター＊ ＊タイトル＊ ＊ループ＊ --CFML ＊ SELECT 文＊ #xx.No# #Title#

CFML の特徴  タグベース  JSP- カスタム・タグに類似。  トレーニング・コストが比較的低い。  制御文が理解できていれば実装はできる。  あくまで比較的。。。  XML パーサで解析できない！  って、おいーーーー（怒怒怒怒）！！

ActionScript  元々は Flash 向けのプログラミング言語。  Adobe Flex でも使用。  詳しくはリファレンスを！  Imai はあまり知らないです。  つまり、ある程度の機能なら CFML だけで十分と いうこと。

Imai が考える開発ツールとして の Coldfusion  使いどころ（要件編）  HTML ベースの Web-UI を提供する。  CFML を用いてサクサク開発可能。  ・・・落とし穴もある。  サクサク作れる＝メンテナンス性の低いものが作 られる覚悟は、しておいた方が良い。  Flash を使う場合  Flex 使った方が良いかも。

Imai が考える開発ツールとして の Coldfusion  使いどころ（要件編）  Mobile 向けドメインがある。  Mobile 向けライブラリが有償で存在する。  Coldfusion8 では？

Imai が考える開発ツールとして の Coldfusion  使いどころ（対象編）  対象システム  ある程度なら対応可能。  例）中規模までの EC サイト  例）中規模までの社内イントラ・サイト  大規模は、 JavaEE/.NET の方が良いでしょう。  対応不可能。  例）学術計算が必要なシステム  CFML の言語仕様上しかたない。  例）オンライン証券取引システム  パフォーマンス耐性は未知数。  でも、良くはないと思う。

Imai が考える開発ツールとして の Coldfusion  使いどころ（対象編）  トランザクション制御は・・・  ほどほどのものが良い。  JDBC を使っているらしいけど、 ObjectPooling と かきちんとできているか謎。  目だった不具合はまだ見ていませんが。  隠蔽されているので「確認できない不安」がある。

Imai が考える開発ツールとして の Coldfusion  使いどころ（設計～開発編）  上級エンジニアが１人しかいない。  １人いれば、他は新人でも何とかなるかも。  勿論、ならないかも知れない。  「トレーニング」は必須。  みんなが新人 or 低スキル。  論外。  Layer を分けた設計で、更にサクサク開発可能にな る。  逆に設計がきちんとできないと、 PHP や Perl 、 (Classic VB の）など ASP と余り変わらない生産性しか出な い。  きちんと出来れば、 Agile 対応も可能。

そんな Coldfusion の（恐ら く） Best な使い方  Layer を意識した設計／実装を！  M-VC パターンの適用は必須。 MODEL 業務ロジック VIEW 画面 CONTROLLER イベントハンドラ SERVICE

Layer 分割をする意義－１  回帰テストを自動化しましょう。  Java の JUnit 、.NET の xUnit の良さを、この CF にも取り入れる！  作る →TestModule も作る → テスト実施  直す →TestModule を起動 → 確認 →OK♪  画面を触ったテストは、極力避けよう。  人間は誤操作をするし。  めんどいし。

Layer 分割をする意義－２  担当者を分けられるようにしましょう。  画面～イベントハンドラの中の人と、 業務ロジックの中の人は、別の方が良い。  こんな人が向いている（と思う）  画面～イベント  Web に精通してる人  Web に精通したい人  業務ロジック  業務に詳しい人  言われたとおり実装するのが精一杯な人 （ようするに、新人）

Coldfusion の勘所 Application.cfc  Servlet のようなもの  Client ⇔ Server の通信時のイベントに、ロジッ クを割り込ませられる。  ユーザ認証がある場合、 Session 切れ判定に便利。  Global 変数（≒定数）を定義する場所として良い （かも）。  Submit 発生時は、 Form 変数も参照できる。  入力値のサニタイジングに便利。  実は・・・  毎回、 Variable 領域にこのコンポーネントが突っ込 まれるｗｗｗ

Coldfusion の勘所 Application.cfc  イベント・ハンドラ  onApplicationStart  JRun が起動された時に実行  onApplicationEnd  全ての Session が途切れてから一定時間経過した後に実行  onSessionStart  ユーザから最初にアクセスを受けた際に実行  onSessionEnd  ユーザが最後にアクセスしてから一定時間経過した後に実 行

Coldfusion の勘所 Application.cfc  イベント・ハンドラ  onRequestStart  ユーザが画面上で Submit または画面遷移を行った際に実行  onRequest  onRequiestStart が実行された後に実行  onRequestEnd  ユーザにレスポンスを返す際に実行  onError  エラーが発生した際に実行

Coldfusion の勘所 変数について  Variables 領域の多用は危険。  スレッド内で共有されるので。。。  変数名が被ると更新されてしまう。  ループ・カウンタに使うと泣きを見る。

補足：「 M と VC 」モデル  キホン  いわゆる「 MVC モデル」  M と VC をきっちり分割したいので、あえて ” と ” を追加。  Model  Service/Entity/Dao などを包括。  View/Controller  画面  イメージ  情報表示のための制御文とクエリ  Event Handler  イベント・キャッチ  遷移先画面の振り分け

補足：「 M と VC 」モデル  有名な Jakarta Struts で言うと。。。  Model  Framework としての Struts には含まれない部分  自分で作らないといけない。  View/Controller  JSP と Action,ActionForm,ActionFormBean,struts- config.xml  StrutsServlet は同様に隠蔽されたまま。  多分、 CF 内に Servlet 的なものは存在する。  →JavaEE 準拠らしいから。

補足：「 M と VC 」モデル  目的  Model を xUnit テストが可能なように構成す る。  複雑なロジックを View/Controller から排除す る。

補足：「 M と VC 」モデル  効用  複雑なロジックのテストが自動化可能。  Agile 開発プロセス採択時に絶大かも。  UI だけサクサク開発。  Model の部分は Mock で良い。  業務要件が固まったら、 Model を実装。

補足：「 M と VC 」モデル  残念  View/Controller が泥臭くなるのは仕方がない。  View にクエリがガンガン記載される。  これもしかたがない。  課題  UnitTestingFramework 的なプロダクトが欲 しい。  今のままだと、 TestModule は１つずつ手作り。

ナレッジ集 舐めてかからない！ｗ  CFML は簡単。  でも、それはコードを書くのが簡単なだけ。  Coldfusion は、設計もコーディング規約も、何もサ ポートしてない。  自分たちでやらなきゃ駄目。  むしろ簡単なだけに。。。  可読性の低い訳の分からんコードが量産されやすい。  スクリプト言語だから動くまでエラーは出ないし。  Syntax が意外にいい加減だし。  [ ] も [ ] もどちら も同じように動く。

ナレッジ集 ダブル Submit  Framework はサポートしていない。  自力回避が必要 orz  現時点では、 JavaScript による回避しかないかも。 （以下のような超メンドイ構成が必要になる）  １度目の Submit でフラグを ON  フラグが ON の場合、 Submit を無効化する。  JavaScript を無効化されると万事休す。  JavaScript を使わないと Submit が出来ないようにする。  結果、 JavaScript への依存度が高い HTML の出来上 がり。

ナレッジ集 スコープに気をつける！  スコープの種類  Application  Application が起動されてから終了するまで有効。  どのスレッドからも参照される。  Session  Session が切れるまで保持される。  同一スレッド内からしか参照できない。

ナレッジ集 スコープに気をつける！  スコープの種類続き  Request  Variables  同一スレッド内では共有される。  スレッドが終了（レスポンスが ClientAgent に返却され るまで）し次第、消去される。  Form  Submit イベント時のみ使用可能。  CGI  調査中。

ナレッジ集 スコープに気をつける！  スコープの種類続き  Request  ローカル変数： cffunction 内のみで使用可  または で消滅。  多分 GC にエントリされるだけだと思うけど。

ナレッジ集 オブジェクト指向  オブジェクト指向風に実装は可能。  ただし  パラメータは原則「値渡し」。  オーバーライドは可能。  でも、オーバーロードは駄目。  言語仕様上使えないデザインパターンも ある。  純粋な OOPL じゃないから。

ナレッジ集 ステートレスに！  Session はなるべく使わない。  Coldfusion に限った話じゃないけど。  Web アプリケーションの特性  いつ切断されるか分からない。  切断された後、また接続されるかも知れない。  サーバ・サイドはスレッド乱立。  ただでさえ、アプリケーションでチューニングする余地が少 ない Framework 。  資源 (Memory) を大事に！  Session 変数を３箇所以上で参照 / 更新する場合。。。  管理しきれなくなることウケアイ！  別の方法を考えた方が良い。

ナレッジ集 URL 整合は諦める。  イベント・ハンドラを置くために。。。  cflocation と cfinclude が入り乱れる。  cflocation=URL は遷移先。  cfinclude=URL はそれを使ったイベント・ハンド ラ。  Form 変数は、 cfinclude を使わないと渡せな い。  cflocation は単なるリダイレクト。