Adobe ColdFusion から Railo に移行する際に問題になる可能性のある主な領域が 2 つあります。
- Railo でサポートされていない機能領域の使用
- ずさんな CFML コード
前者には、Exchange や SharePoint などの Microsoft テクノロジとの統合や、Office ドキュメントの操作が含まれます。PDF フォームといくつかのより高度なドキュメント操作。UI「ウィジェット」の統合。cfSpreadsheetなど、一部の Microsoft 統合にはサードパーティの拡張機能がありますが、PDF 関連のものについては、Java ライブラリを使用して独自に展開する必要があります (PDF フォームと高品質の HTML から PDF への変換は Adobe の専門分野であるため、これらに依存している場合は、移行でかなりの作業を行う必要があります)。UI「ウィジェット」に関しては、「正しい方法」で行う方がよいため、それらに依存する場合は、ColdFusion UI The Right Way を読む必要があります。
後者は特定するのが難しい問題です。Railo への移行を行った人々によるメーリング リストやブログへの経験の投稿を除いて、違いは十分に文書化されていませんが、次のようなものがあります。
- スコープ名を変数として使用する (Railo はパフォーマンス上の理由からスコープを予約名として扱います)
- たとえば、タグ内にコメントを埋め込む
<cfif x gt y <!--- check boundary --->>
(古い CFML コードでこのようなものを見たことがありますが、うまくいくことに驚きました)。
- 宣言されていない
a.b.c = 0
場合など、ネストされた struct 要素の自動作成への依存。a
- 長い間廃止されてきた機能への依存
parameterExists()
。
他にも多くの小さな違いがあります。Railo は一般に Adobe ColdFusion よりも構文とセマンティクスについて厳密であり、多くの場合、これらの決定は、Adobe ColdFusion との互換性により Railo が遅くなるというパフォーマンス上の懸念によって決定されます。
ここでの完全な開示: 私は Railo を 5 年間ほぼ独占的に使用しており、以前は Railo のコンサルティング事業の米国部門を経営していました。とは言うものの、Railo は小さな会社であり (5 人のかなり大きな元 Adobe パートナーの支援にもかかわらず)、エンジンに取り組んでいる人はほんの一握りであり、より最先端の部分以外の製品についての認識はほとんどないことを考慮する必要があります。 CFML コミュニティ。それに比べて、アドビには大規模なチームとマーケティング予算があります。開発者を見つけるのが難しいという懸念は、Railo に切り替えても解決されません。より大きな開発者プールにアクセスするには、別のエンジンではなく、より一般的な言語に切り替える必要があります。
最後に、Blue Dragon のエンジン、特に Open BlueDragon について一言: このプロジェクトのメンテナーは、他のエンジン (Adobe、Railo) との互換性は彼らにとって主要な関心事ではないことを何度か公に述べています。まだサポートされていないか、少なくとも互換性のある方法でサポートされていない言語機能。最後に確認したところ、長年にわたって Adobe ColdFusion と Railo でサポートされていたにもかかわらず、フル スクリプト コンポーネントがそのリストに含まれていました (これcomponent { ... }
は、フォームではなく使用を意味し<cfcomponent><cfscript> .. </cfscript></cfcomponent>
ます)。CFML の BlueDragon 方言は長年にわたって着実に分岐してきたため、CFMX7 / ACF8 でまだ実行される非常に古い学校の CFML を使用していない限り、Open BlueDragon に移行しようとしてもあまり成功しないでしょう。