从Adobe ColdFusion迁移到替代CFML引擎时会出现什么问题？

Question

我们目前正在将Adobe ColdFusion 9用于相当大的应用程序。 我们正考虑搬到Railo或Blue Dragon。

我们会遇到什么问题？

• 它需要大量的重构还是大多数CFML代码才能在新系统上运行？
• 替代引擎是否为大多数官方标签提供支持，还是更有限？
• 简而言之，官方语言的这些替代方案有多么不同？
• 我们能做些什么来减少这个过程的痛苦（比如首先升级到CF11或者删除/避免使用某些功能）？

我的问题类似于Railo，Open Bluedragon和Adobe Coldfusion之间存在哪些值得注意的差异？ ，虽然这与实际差异有关，但我更具体地询问过渡/实施的实用性。

Answer 1

这一切都取决于您的代码和您正在使用的特定Adobe ColdFusion功能。 在大多数情况下，每个CFML迭代都支持相同的标签/功能。 他们偏离Adobe产品的地方通常会被记录和解释。 您需要深入了解代码库并专门查看正在使用的功能，并将其与您选择的CFML引擎进行比较。 或者你可以下载并启动备用CFML引擎，删除你的代码库，看看有什么中断。

作为Railo的一个例子 - CFML兼容性

Railo试图尽可能地遵守CFML标准，仍然存在一些差异，例如缺少标签和功能或者行为略有不同。 此页面和下面的页面应描述不兼容性。

我不得不质疑你的评论基础是什么？ “ 尤其是与他们的未来非常不确定 ”。 您正在运行ColdFusion 9.自那时起，Adobe已经实施了两个主要版本（10和11），目前正在开发未来版本。

Answer 2

从Adobe ColdFusion迁移到Railo时，有两个主要方面可能会出现问题：

• 使用Railo不支持的功能区域
• 邋CF的CFML代码

前者包括与Microsoft技术的集成，如Exchange和Sharepoint，以及Office文档操作; PDF表格和一些更复杂的文件操作; UI“小部件”集成。 某些Microsoft集成有第三方扩展，例如cfSpreadsheet ，但对于与PDF相关的内容，您需要使用Java库自行推出（PDF格式和高质量的HTML到PDF转换是Adobe专业，因此请准备好如果您依赖这些，请在迁移中做相当多的工作）。 对于UI“小部件”，你最好做“正确的方式”，所以如果你依赖那些，你应该阅读ColdFusion UI正确的方法 。

后者是一个难以解决的问题。 这些差异没有得到很好的记录 - 除了邮件列表的经验帖子以及过渡到Railo的人的博客 - 但它们包括以下内容：

• 使用范围名称作为变量（出于性能原因，Railo将范围视为保留名称）
• 在标签内部嵌入注释，例如<cfif x gt y <!--- check boundary --->> （我在较旧的CFML代码中看到了类似的东西，并且很惊讶它有效）。
• 依赖于自动创建嵌套的struct元素，例如，当a尚未声明时， abc = 0 。
• 依赖于长期弃用的功能，例如parameterExists() 。

还有许多其他小的差异：Railo在语法和语义上通常比Adobe ColdFusion更严格，并且这些决策通常由性能问题驱动，因为与Adobe ColdFusion的兼容性会使Railo变慢。

在此全面披露：我已经将Railo专门用了五年而且我曾经在Railo的咨询业务中经营美国分公司。 也就是说，你需要考虑到Railo是一家小公司（尽管得到了五个相当大的前Adobe合作伙伴的支持），只有少数人在使用该引擎，并且很少有人知道该产品在更前沿的部分之外CFML社区。 相比之下，Adobe拥有庞大的团队和营销预算。 切换到Railo无法解决您对寻找开发人员困难的担忧 - 要获得更大的开发人员访问权限，您真的需要切换到更流行的语言，而不仅仅是不同的引擎。

最后，关于Blue Dragon的引擎，特别是Open BlueDragon：该项目的维护者多次公开表示与其他引擎（Adobe，Railo）的兼容性并不是他们的主要关注点，事实上有很多现代的他们仍然不支持或至少不以兼容方式支持的语言功能。 最后我查了一下，尽管Adobe ColdFusion和Railo多年来一直支持，但是全部脚本组件都在该列表上（我的意思是使用component { ... }而不是<cfcomponent><cfscript> .. </cfscript></cfcomponent>表格）。 这些年来，CFML的BlueDragon方言一直在稳步发展，所以除非你有非常老的学校CFML，那仍然可以在CFMX7 / ACF8上运行，你可能不会在尝试迁移到Open BlueDragon方面取得多大成功。

Answer 3

这里有几个很好的答案，我很欣赏他们给出的建议。 当我问这个问题时，我正在寻找更具体的东西，所以现在我已经有机会真正将我们的应用程序迁移到Railo我想我应该回来并列出我们遇到的问题而且，同样重要的是，严重性和变通方法。 希望这会有助于其他人考虑跳跃：

1. cfMessageBox： cfMessageBox不是Railo中支持的标记。 我们提出的最佳解决方案是创建一个名为MessageBox.cfm的新自定义标记，然后将其放入“{railo-install} / lib / railo-server / context / library / tag /”。 这将允许它被识别为核心标记并通过“”引用，这使我们无法更新数百个调用它的模板。 当然，这需要我们从头开始创建消息框自定义标记。

2. cfDiv： cfdiv在用于绑定JS函数时似乎抛出了JS错误。 我猜这是因为JS绑定没有得到官方支持（鉴于我在官方文档中找不到任何引用），而ACF允许它作为延迟执行，因此Railo根本不接受它。 我们可以创建一个自定义标记来生成JS setTimeout，如上面（1）中所述，它解决了我们的问题，但实际上将此标记用于其预期目的的应用程序可能会面临更加困难的道路。

3. cfWindow：在Railo中对cfWindow的支持似乎有限。 具体来说，需要手动显示新窗口，并且不存在destroy方法。 还出现了各种其他错误。 我们认为仅仅转向基于JQuery的模态更有意义。

4. cfLayout： cfLayout支持值得怀疑。 它基于JQuery，而不是像ACF版本那样的Ext-JS。 这会导致问题，因为我们现在运行JQuery 1.10并且内置标记似乎不能超越JQuery 1.8。 事实上，我找不到任何标签工作完美的JQuery版本。 我们决定最好再次编写基于JQuery的自定义标记。

5. cfDocument： cfDocument在Railo中的工作方式不同，似乎需要更严格的HTML。 我在这里找到了很多有用的信息，但是到目前为止我还没有让我的任何cfDocument调用按预期工作。

6. 相对cfLocations：以“../”开头且在webroot之外回溯的cfLocations会引发一个奇怪的Java错误。 这最终成为Tomcat中的一个错误，并且由版本4.3.1.003中的Railo团队修补。 如果您下载较旧的Railo版本，则可能会遇到此问题并需要更新所有cfLocation调用。

7. Oracle瘦客户端：我们的数据库人员向我报告他设置了Oracle瘦客户端，因为在Railo中本身不支持OCI客户端。 我发现这可能是相关的，但我没有专业知识可以说肯定。

8. 文档： ACF Livedocs有时会加剧，因为它们没有触及更复杂的标签实现方式，但是Railo的版本是极简主义的定义。 我认为可以说Railo没有指定每个标签和功能的文档，并且它们让你依赖Adobe来实现这一点，当你需要知道这两个实现有何不同时，这会导致一个严重的问题。

最后看起来，正如之前的答案预测的那样，UI标签是我们问题的主要部分。 基于之前的评论，我希望能够更好地实现它们，这可能只需要在这里和那里进行调整，但（至少对于我们的需求），Railo版本似乎是边缘无功能的，看起来我们需要完全替换它们。 对我们来说，这可能不太现实，尽管我们仍在抛弃这个想法。

公平地说，以下是我们研究和测试的一些优点：

1. 性能：尽管兼容性问题使我无法进行大量性能测试，但初始抽样检查显示大多数页面的执行时间减少了大约50％。

2. 调试： Railo中的调试选项非常棒。 格式化的选项还有很多，包括为不同的开发人员（IP地址）指定不同的格式。 一个令人难以置信的功能是包含页面中实际使用的以逗号分隔的查询字段列表：这可以让您基于“select *”查询进行有效开发，并简单地将字段列表复制并粘贴到查询中开发，这将节省大量时间与我们正在使用的视图一样大。

3. 成本：这是我们决定研究替代品的一个较大原因。 只需将少数企业许可的ACF服务器切换到Railo，即可在升级到最新版本的ACF时节省2万美元以上。 此外，随着性能的提高，您可以看到更大的硬件需求节省。 这一点的一个副作用是，如果没有持续升级的许可成本的成本/收益分析，就可以保持更新。

4. 支持：如果没有支持合同，Adobe似乎不会回应用户关注的问题。 自从ACF 9以来，我已经报告了一个影响生产的错误，但仍未修复。 然而，Railo社区是我见过的最有帮助和最敏感的社区之一，开发人员甚至直接回应了我提出的问题和错误报告。

5. 长寿：当然，这是一个高度自以为是的观点，但是随着每个新版本Adobe越来越多地将ACF降级为阴影，Railo似乎致力于发展社区。 结合其开源性质，我认为这使得它对未来长期支持更加安全，即使这种支持只是我们在需要时将开发掌握在自己手中。

由于多种原因，包括不同的CFML兼容性，我们甚至没有进入Blue Dragon的测试阶段。