9

現在、かなり大規模なアプリケーションに Adob​​e ColdFusion 9 を使用しています。ライロかブルードラゴンへの乗り換えを考えています。

どのような問題に遭遇するでしょうか?

  • 大量のリファクタリングが必要ですか、それともほとんどの CFML コードは新しいシステムで動作しますか?
  • 代替エンジンはほとんどすべての公式タグをサポートしていますか、それともより制限されていますか?
  • 要するに、これらの代替言語は公用語からどの程度離れているのでしょうか?
  • このプロセスの負担を軽減するためにできることはありますか (最初に CF11 にアップグレードするか、特定の機能を削除/回避するなど)?

私の質問は、Railo、Open Bluedragon、および Adob​​e Coldfusion の間に注目すべき違いは何ですか?に似ています。、しかし、それは実際的な違いに関係していますが、移行/実装の実用性についてより具体的に尋ねています。

4

3 に答える 3

3

ここにはいくつかの良い答えがあり、それらに与えられたアドバイスに感謝します。この質問をしたとき、もう少し具体的なものを探していたので、アプリを Railo に移行することを実際に試す機会があったので、戻って遭遇した問題をリストアップする必要があると思いましたそして、同様に重要なのは、重大度と回避策です。うまくいけば、これは他の人がジャンプを検討するのに役立つでしょう:

  1. cfMessageBox: cfMessageBox は Railo でサポートされているタグではありません。私たちが思いついた最善の解決策は、MessageBox.cfm という新しいカスタム タグを作成し、それを「{railo-install}/lib/railo-server/context/library/tag/」にドロップすることです。これにより、コアタグとして認識され、「」を介して参照されるようになり、それを呼び出す何百ものテンプレートを更新する必要がなくなります. もちろん、これにはメッセージ ボックスのカスタム タグを最初から作成する必要があります。

  2. cfDiv: cfDiv を使用して JS 関数にバインドすると、JS エラーが発生するようです。これは、JS バインディングが公式にサポートされていないためであり (公式ドキュメントで参照が見つからないことを考えると)、ACF では遅延実行として許可されていますが、Railo では単純に受け入れられていないためだと思います。上記 (1) で説明したように JS setTimeout を生成するカスタム タグを作成するだけで問題は解決しましたが、実際にこのタグを意図した目的で使用するアプリケーションには、さらに困難な道が待っている可能性があります。

  3. cfWindow: Railo での cfWindow のサポートは限定されているようです。具体的には、新しいウィンドウを手動で表示する必要があり、destroy メソッドは存在しません。他にもさまざまなバグが発生しました。JQuery ベースのモーダルに移行する方が理にかなっていると判断しました。

  4. cfLayout: cfLayout のサポートには疑問があります。ACF のバージョンのような Ext-JS ではなく、JQuery に基づいています。現在 JQuery 1.10 を実行しており、組み込みタグが JQuery 1.8 以降では機能しないように見えるため、これが問題を引き起こします。実際、タグが完全に機能する JQuery バージョンは見つかりませんでした。ここでも、JQuery に基づいて独自のカスタム タグを作成するのが最善であると判断しました。

  5. cfDocument: Railo では cfDocument の動作が異なり、より厳密な HTML が必要なようです。hereで多くの役立つ情報を見つけましたが、まだ実際には cfDocument 呼び出しが期待どおりに機能していません。

  6. 相対 cfLocations: 「../」で始まり、webroot を超えてバックトラックされた cfLocations は、奇妙な Java エラーをスローします。これは最終的に Tomcat のバグであり、バージョン 4.3.1.003 で Railo チームによってパッチが適用されました。Railo の古いバージョンをダウンロードすると、この問題が発生する可能性があり、すべての cfLocation 呼び出しを更新する必要があります。

  7. Oracle Thin Client: データベース担当者から、Railo では OCI クライアントがネイティブにサポートされていないため、Oracle Thin Client をセットアップしたとの報告がありました。関連する可能性があるthisを見つけましたが、確かに言う専門知識がありません。

  8. ドキュメンテーション: ACF Livedocs は、いくつかのタグの実装方法のより重要な複雑さに触れていないため、時々悪化していますが、Railo のバージョンはミニマリストの定義です。Railo には各タグと関数を指定するドキュメントがなく、Adobe に頼らざるを得ないと言っても過言ではありません。これは、2 つの実装の違いを知る必要がある場合に深刻な問題を引き起こします。

最終的には、以前の回答で予測されたように、UI タグが問題の大部分だったようです。以前のコメントに基づいて、あちこちで微調整が必​​要なだけのより良い実装を望んでいましたが、(少なくとも私たちのニーズでは) Railo バージョンは境界線上に機能しないように見え、完全に置き換える必要があるようです. 私たちにとって、これは現実的ではないかもしれませんが、まだアイデアを投げかけています.

公平を期すために、私たちの調査とテストから得られたいくつかの良い点を以下に示します。

  1. パフォーマンス: 互換性の問題により、多くのパフォーマンス テストを行うことができませんでしたが、最初のスポット チェックでは、ほとんどのページで実行時間が約 50% 短縮されました。

  2. デバッグ: Railo のデバッグ オプションは非常に優れています。さまざまな開発者 (IP アドレス) ごとに異なる形式を指定するなど、書式設定のオプションがはるかに多くあります。驚くべき機能の 1 つは、ページで実際に使用されたクエリ フィールドのカンマ区切りのリストが含まれていることです。これにより、「select *」クエリに基づいて効果的に開発し、最後にフィールドリストをコピーしてクエリに貼り付けるだけで済みます。これにより、使用しているビューと同じくらい大きなビューで多くの時間を節約できます。

  3. コスト: これは、代替案を検討することにした大きな理由の 1 つです。数台のエンタープライズ ライセンスの ACF サーバーを Railo に切り替えるだけで、最新バージョンの ACF にアップグレードするよりも 2 万ドル以上節約できます。さらに、パフォーマンスが向上すると、ハードウェア要件がさらに大幅に節約される可能性があります。この点の副作用は、アップグレードを遅らせるライセンス費用の継続的な費用対効果分析を行わなくても、はるかに多くの最新情報を維持できることです。

  4. サポート: サポート契約がなければ、アドビはユーザーの懸念に対応していないようです。ACF 9 以降、プロダクションに影響するバグが報告されましたが、まだ修正されていません。それでも、Railo コミュニティは、私が今まで見た中で最も役に立ち、反応が良いコミュニティの 1 つであり、開発者は、私が提起した懸念事項やバグ レポートに直接対応してくれました。

  5. 寿命: もちろん、これは非常に独断的な点ですが、Adobe は新しいバージョンごとに ACF をますます影に追いやっているように見えますが、Railo はコミュニティの成長に専念しているようです. そのオープンソースの性質と相まって、これは長期的には将来のサポートに対するより安全な賭けになると思います.

CFML の互換性が異なるなど、さまざまな理由から、Blue Dragon のテスト段階には至りませんでした。

于 2014-06-30T19:53:27.037 に答える
3

Adobe ColdFusion から Railo に移行する際に問題になる可能性のある主な領域が 2 つあります。

  • Railo でサポートされていない機能領域の使用
  • ずさんな CFML コード

前者には、Exchange や SharePoint などの Microsoft テクノロジとの統合や、Office ドキュメントの操作が含まれます。PDF フォームといくつかのより高度なドキュメント操作。UI「ウィジェット」の統合。cfSpreadsheetなど、一部の Microsoft 統合にはサードパーティの拡張機能がありますが、PDF 関連のものについては、Java ライブラリを使用して独自に展開する必要があります (PDF フォームと高品質の HTML から PDF への変換は Adob​​e の専門分野であるため、これらに依存している場合は、移行でかなりの作業を行う必要があります)。UI「ウィジェット」に関しては、「正しい方法」で行う方がよいため、それらに依存する場合は、ColdFusion UI The Right Way を読む必要があります。

後者は特定するのが難しい問題です。Railo への移行を行った人々によるメーリング リストやブログへの経験の投稿を除いて、違いは十分に文書化されていませんが、次のようなものがあります。

  • スコープ名を変数として使用する (Railo はパフォーマンス上の理由からスコープを予約名として扱います)
  • たとえば、タグ内にコメントを埋め込む<cfif x gt y <!--- check boundary --->>(古い CFML コードでこのようなものを見たことがありますが、うまくいくことに驚きました)。
  • 宣言されていないa.b.c = 0場合など、ネストされた struct 要素の自動作成への依存。a
  • 長い間廃止されてきた機能への依存parameterExists()

他にも多くの小さな違いがあります。Railo は一般に Adob​​e ColdFusion よりも構文とセマンティクスについて厳密であり、多くの場合、これらの決定は、Adobe ColdFusion との互換性により Railo が遅くなるというパフォーマンス上の懸念によって決定されます。

ここでの完全な開示: 私は Railo を 5 年間ほぼ独占的に使用しており、以前は Railo のコンサルティング事業の米国部門を経営していました。とは言うものの、Railo は小さな会社であり (5 人のかなり大きな元 Adob​​e パートナーの支援にもかかわらず)、エンジンに取り組んでいる人はほんの一握りであり、より最先端の部分以外の製品についての認識はほとんどないことを考慮する必要があります。 CFML コミュニティ。それに比べて、アドビには大規模なチームとマーケティング予算があります。開発者を見つけるのが難しいという懸念は、Railo に切り替えても解決されません。より大きな開発者プールにアクセスするには、別のエンジンではなく、より一般的な言語に切り替える必要があります。

最後に、Blue Dragon のエンジン、特に Open BlueDragon について一言: このプロジェクトのメンテナーは、他のエンジン (Adobe、Railo) との互換性は彼らにとって主要な関心事ではないことを何度か公に述べています。まだサポートされていないか、少なくとも互換性のある方法でサポートされていない言語機能。最後に確認したところ、長年にわたって Adob​​e ColdFusion と Railo でサポートされていたにもかかわらず、フル スクリプト コンポーネントがそのリストに含まれていました (これcomponent { ... }は、フォームではなく使用を意味し<cfcomponent><cfscript> .. </cfscript></cfcomponent>ます)。CFML の BlueDragon 方言は長年にわたって着実に分岐してきたため、CFMX7 / ACF8 でまだ実行される非常に古い学校の CFML を使用していない限り、Open BlueDragon に移行しようとしてもあまり成功しないでしょう。

于 2014-06-23T16:25:35.537 に答える