9

我们目前正在为一个相当大的应用程序使用 Adob​​e ColdFusion 9。我们正在考虑搬到Railo 或Blue Dragon。

我们会遇到什么问题？

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

我的问题类似于Railo、Open Bluedragon 和 Adob​​e Coldfusion 之间有哪些显着差异？，但是虽然这与实际差异有关，但我更具体地询问了过渡/实施的实用性。

4

3 回答 3

6

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

作为 Railo 的示例 - CFML 兼容性

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

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

于 2014-06-19T14:57:28.563 回答
3

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

  • 使用 Railo 不支持的功能区域
  • 马虎的CFML代码

前者包括与 Microsoft 技术的集成，例如 Exchange 和 Sharepoint，以及 Office 文档操作；PDF 表单和一些更复杂的文档操作；UI“小部件”集成。一些 Microsoft 集成有第三方扩展，例如cfSpreadsheet，但对于与 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当a尚未声明时。
  • 依赖于长期弃用的功能，例如parameterExists().

还有许多其他小的差异：Railo 在语法和语义方面通常比 Adob​​e ColdFusion 更严格，而且这些决定通常是由性能问题驱动的，因为与 Adob​​e ColdFusion 的兼容性会使 Railo 变慢。

在这里全面披露：我几乎只使用 Railo 五年了，我曾经经营过 Railo 咨询业务的美国分部。也就是说，你需要考虑到 Railo 是一家小公司（尽管有五个相当大的前 Adob​​e 合作伙伴的支持），只有少数人在引擎上工作，除了更前沿的部分之外，对产品的了解很少。 CFML 社区。相比之下，Adobe 拥有庞大的团队和营销预算。切换到 Railo 不会解决您对难以找到开发人员的担忧 - 要访问更大的开发人员池，您确实需要切换到更流行的语言，而不仅仅是不同的引擎。

最后，谈谈 Blue Dragon 的引擎，特别是 Open BlueDragon：该项目的维护者多次公开表示，与其他引擎（Adobe、Railo）的兼容性并不是他们主要关心的问题，而且确实有很多现代的他们仍然不支持或至少不以兼容的方式支持的语言功能。最后我检查了一下，尽管 Adob​​e ColdFusion 和 Railo 多年来一直支持完整的脚本组件（我的意思是使用component { ... }而不是<cfcomponent><cfscript> .. </cfscript></cfcomponent>表单），但完整脚本组件仍在该列表中。CFML 的 BlueDragon 方言多年来一直在稳步分化，所以除非你有非常老的 CFML，它仍然可以在 CFMX7 / ACF8 上运行，否则你可能不会在尝试迁移到 Open BlueDragon 时取得太大成功。

于 2014-06-23T16:25:35.537 回答
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 的支持似乎有限。具体来说，新窗口需要手动显示，并且不存在销毁方法。各种其他错误也出现了。我们认为只迁移到基于 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 中的一个错误，Railo 团队在 4.3.1.003 版本中对其进行了修补。如果您下载较旧的 Railo 版本，您可能会遇到此问题并需要更新所有 cfLocation 调用。

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

  8. 文档： ACF Livedocs 有时会加重问题，因为它们没有涉及一些标签如何实现的更重要的复杂性，但 Railo 的版本是极简主义的定义。我认为公平地说，Railo 没有指定每个标签和功能的文档，并且它们让您依赖 Adob​​e，当您需要知道这两种实现有何不同时，这会导致一个严重的问题。

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

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

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

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

  3. 成本： 这是我们决定寻找替代方案的主要原因之一。只需将一些企业许可的 ACF 服务器切换到 Railo，就可以节省 2 万美元以上的升级到最新版本的 ACF。此外，随着性能的提高，您可以看到更多的硬件需求节省。这一点的一个副作用是，无需对阻碍升级的许可成本进行持续的成本/收益分析，就可以保持更新。

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

  5. Longevity： 当然，这是一个非常自以为是的观点，但随着每个新版本的推出，Adobe 似乎越来越将 ACF 置于阴影之下，Railo 似乎致力于发展社区。结合其开源性质，我认为这使它成为未来长期支持的更安全的选择，即使这种支持只是我们在需要时将开发掌握在自己手中。

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

于 2014-06-30T19:53:27.037 回答