Nic*_*las 9 coldfusion railo bluedragon
我们目前正在将Adobe ColdFusion 9用于相当大的应用程序.我们正考虑搬到Railo或Blue Dragon.
我们会遇到什么问题？
我的问题类似于Railo,Open Bluedragon和Adobe Coldfusion之间存在哪些值得注意的差异？,虽然这与实际差异有关,但我更具体地询问过渡/实施的实用性.
这一切都取决于您的代码和您正在使用的特定Adobe ColdFusion功能.在大多数情况下,每个CFML迭代都支持相同的标签/功能.他们偏离Adobe产品的地方通常会被记录和解释.您需要深入了解代码库并专门查看正在使用的功能,并将其与您选择的CFML引擎进行比较.或者你可以下载并启动备用CFML引擎,删除你的代码库,看看有什么中断.
作为Railo的一个例子 - CFML兼容性
Railo试图尽可能地遵守CFML标准,仍然存在一些差异,例如缺少标签和功能或者行为略有不同.此页面和下面的页面应描述不兼容性.
我不得不质疑你的评论基础是什么？" 尤其是与他们的未来非常不确定 ".您正在运行ColdFusion 9.自那时起,Adobe已经实施了两个主要版本(10和11),目前正在开发未来版本.
这里有几个很好的答案，我很欣赏其中给出的建议。当我问这个问题时，我正在寻找更具体的东西，所以现在我有机会真正尝试将我们的应用程序迁移到 Railo，我想我应该回来列出我们已经解决的问题遇到同样重要的严重性和解决方法。希望这能帮助其他考虑跳槽的人：
\n\ncfMessageBox: \ncfMessageBox 不是 Railo 中支持的标签。我们提出的最佳解决方案是创建一个名为 MessageBox.cfm 的新自定义标签，然后将其放入 \xe2\x80\x9c{railo-install}/lib/railo-server/context/library/tag/ \xe2\x80\x9d。这将允许它被识别为核心标签并通过 \xe2\x80\x9c\xe2\x80\x9d 引用，这使我们无需更新数百个调用它的模板。当然，这需要我们从头开始创建一个消息框自定义标签。
cfDiv: \ncfDiv 在用于绑定到 JS 函数时似乎会引发 JS 错误。我猜测这是因为 JS 绑定不受官方支持（鉴于我在官方文档中找不到任何参考），虽然 ACF 允许延迟执行，但 Railo 根本不支持 xe2x80 \x99t 接受它。我们可以创建一个自定义标签来生成 JS setTimeout，如上面 (1) 中所述，这解决了我们的问题，但实际使用此标签来实现其预期目的的应用程序可能会面临更困难的道路。
cfWindow: \nRailo 中对 cfWindow 的支持似乎有限。具体来说，新窗口需要手动显示，并且不存在销毁方法。还出现了各种其他错误。我们认为转向基于 JQuery 的模式更有意义。
cfLayout： \ncfLayout 支持有问题。它基于 JQuery 而不是像 ACF\xe2\x80\x99s 版本那样的 Ext-JS。这会导致一个问题，因为我们现在运行 JQuery 1.10，并且内置标记\xe2\x80\x99t 似乎无法在 JQuery 1.8 之外工作。事实上，我找不到该标签可以完美运行的任何 JQuery 版本。我们决定最好再次基于 JQuery 编写我们自己的自定义标签。
cfDocument： \ncfDocument 在 Railo 中的工作方式不同，并且似乎需要更严格的 HTML。我在这里找到了很多有用的信息，尽管到目前为止我还没有真正让任何 cfDocument 调用按预期工作。
相对 cfLocations：以 \xe2\x80\x9c../\xe2\x80\x9d 开头并回溯到 Webroot 之外的 \ncfLocations 会引发奇怪的 Java 错误。这最终成为 Tomcat 中的一个错误，并由 Railo 团队在版本 4.3.1.003 中修复。如果您下载较旧的 Railo 版本，您可能会遇到此问题，并且需要更新所有 cfLocation 调用。
Oracle 瘦客户端： \n我们的数据库人员向我报告他安装了 Oracle 瘦客户端，因为 Railo 本身不支持 OCI 客户端。我发现了这个，这可能是相关的，但我没有专业知识可以肯定。
文档： \nACF Livedocs 有时会让人恼火，因为它们没有触及某些标签如何实现的更重要的复杂性，但 Railo 的版本是极简主义的定义。我认为可以公平地说 Railo 没有指定每个标签和功能的文档，并且它们让您只能依赖 Adobe，当您需要知道这两种实现有何不同时，这会导致严重的问题。
最后，正如之前的答案所预测的那样，UI 标签似乎是我们的主要问题。根据之前的评论，我希望它们能有更好的实现，可能只需要在这里和那里进行一些调整，但是（至少对于我们的需求）Railo 版本似乎无法正常工作，看起来我们需要完全替换它们。对我们来说，这可能不现实，尽管我们仍在考虑这个想法。
\n\n公平地说，以下是我们的研究和测试中的一些优点：
\n\n性能： \n虽然兼容性问题使我无法进行大量性能测试，但初步抽查显示大多数页面的执行时间减少了大约 50%。
调试： \nRailo 中的调试选项非常令人惊奇。格式化选项有更多，包括为不同的开发人员（IP 地址）指定不同的格式。一个令人难以置信的功能是包含页面中实际使用的查询字段的逗号分隔列表：这可以让您基于“select *”查询进行有效开发，然后只需将字段列表复制并粘贴到最后的查询中开发，这将节省大量时间，并且视图与我们正在使用的视图一样大。
成本： \n这是我们决定研究替代方案的更大原因之一。与升级到最新版本的 ACF 相比，仅将少数企业许可的 ACF 服务器切换到 Railo 即可节省 2 万美元以上。此外，随着性能的提高，您可以看到硬件需求的进一步节省。这一点的一个副作用是，无需对许可成本进行持续的成本/效益分析来阻止升级，就可以保持更多的更新。
支持： \n如果没有支持合同，Adobe 似乎不会回应用户的疑虑。自 ACF 9 以来，我报告了一个影响生产的错误，但该错误仍未得到修复。然而，Railo 社区是我见过的最有帮助和反应最快的社区之一，开发人员甚至直接回应了我提出的问题和错误报告。
长寿： \n当然，这是一个非常固执己见的观点，但虽然 Adobe 似乎在每个新版本中都越来越将 ACF 置于阴影之下，但 Railo 似乎致力于发展社区。结合其开源性质，我认为从长远来看，这使其成为未来支持的更安全选择，即使这种支持只是我们在需要时将开发掌握在自己手中。
由于多种原因，包括不同的 CFML 兼容性，我们甚至没有进入 Blue Dragon 的测试阶段。
\n