Coldfusion 在cfinclude'中使用相对路径；d文件

我对ColdFusion有点陌生，我正在尝试了解使用CFD文件的最佳方式。我发现的一个限制是，文件被在线包含，就好像它们是包含模板的一部分一样。这很好也很简单，但这意味着包含的文件中的任何相对路径都是相对于includer而不是包含的文件来解析的。这在以下文件布局中成为问题：

a.cfm   <--- cfincludes b.cfm
b.cfm   <--- cfincludes c.cfm
c.cfm
somedir/d.cfm   <--- cfincludes ../b.cfm

---

a.cfm基本上涵盖了这个主题。但只是为了表明使用的想法。假设我们的应用程序位于

这只是一个特殊的ColdFusion路径特性：“绝对”路径是Webroot的“/myapp/”

然后在Application.cfc（Application.cfm）中，您可以定义基本URL：

<!--- hardcoded --->
<cfset application.basePath = "/myapp/" />
<!--- more intelligent --->
<cfset application.basePath = GetDirectoryFromPath(CGI.SCRIPT_NAME) />



并包括模板，每次作为

<cfinclude template="#application.basePath#b.cfm" />



它只是给出了如何使包含独立于当前模板位置的基本概念

另一种方法是使用映射，或者（CF8+），但这是另一种情况

另一种方法是使用单调度器（index.cfm、page.cfm等）——在大多数现代应用程序中都使用，但这也是另一种情况。
解释这一点的最佳方法是将include（以任何语言）视为服务器端复制/粘贴。这就是ColdFusion、ASP、PHP、.NET的情况，你可以说。。。所包含的文件被视为在其父页面的上下文中运行。服务器实质上获取包含文件的内容并将其粘贴到父文件中

如果要包含具有自己包含的文件，最好使用根相对路径来确保路径始终指向正确的位置

丹
也许我的问题不清楚。我理解include文件是如何工作的。我想知道他们为什么那样工作。我看不到您希望包含的文件中的相对路径相对于父文件或“包含”文件进行解析的情况，但它们就是这样工作的（请参见上面的示例）。我希望有人能指出一个用例来证明这种行为的合理性。就像我说的，我对CF有些陌生，所以我可能错过了一些东西。啊，好的。想一想，老式的CF开发者会告诉你，从Alliare产品中产生这种路径系统的一些遗留原因。假设您正在比较PHP或其他方面的经验，其中包括初始模板上下文中的工作——如果我没记错的话。但它的工作原理和它的工作原理一样，因为对于CF-newcomers.CFINCLUDE来说，许多“奇怪”的事情基本上只是从包含的文件中获取代码块，并在编译时将其放入“父级”中。它不需要在web根目录中，也不需要是.cfm文件。至于设计推理，你可能需要问问Jeremy Allaire。一个人应该小心，谢谢你，丹。我想我的困惑在于ColdFusion模糊了代码和HTML之间的界限。在我看来，CF打破了HTML使用的关于相对路径的惯例，但如果我把cfinclude更像是一个SSI，那就没有意义了。尽管如此，我认为cfinclude的实用性受到了严重的限制，如果这一点被改变，它可能会显著增加。但是，现在太迟了。你只需要意识到cfinclude是一个SSI，它不是“像”一个：）。如果希望子页面遵循子页面位置的包含路径，请使用或自定义标记。只要知道，如果您使用cfmodule，您将无法访问父页面的变量，除非您使用调用者作用域从父页面获取变量。