在子目录中扩展 application.cfc
我有以下两个文件,希望第二个文件扩展第一个文件:
- wwwroot\site\application.cfc
- wwwroot\site\dir\application.cfc
但是,当我去声明第二个文件的组件时,我没有确定在 extends 属性中放置什么。 我的问题是,多个开发站点(具有共享 SVN 存储库)正在运行同一个 ColdFusion 实例,因此我不能像这样在 CF 管理中创建映射:
<cfcomponent extends="site.application">
但是,ColdFusion 不会不喜欢:
<cfcomponent extends="..application">
或任何动态输入,例如:
<cfcomponent extends="#expandpath('..').#application">
有什么方法可以引用父目录来完成我的扩展吗?
编辑以澄清:由于上面的粗体文本,ApplicationProxy 解决方案不起作用。 目前,作为一种解决方法,我们只是不将 \dir\application.cfc 检查到 SVN,以便每个开发人员都可以保留扩展他/她自己的根 application.cfc 的版本。 显然,这并不理想。
I have the following two files and would like the second to extend the first:
- wwwroot\site\application.cfc
- wwwroot\site\dir\application.cfc
However, when I go to declare the component for the second file, I'm not sure what to put in the extends attribute. My problem is that several dev sites (with a shared SVN repository) are running off the same instance of ColdFusion, so I can't just create a mapping in the CF admin like so:
<cfcomponent extends="site.application">
However, ColdFusion doesn't like:
<cfcomponent extends="..application">
or any dynamic input like:
<cfcomponent extends="#expandpath('..').#application">
Creating a runtime mapping (like here) doesn't seem possible either. Creating it in the base application.cfc is useless because that code hasn't yet executed by the time the inheriting cfc is being declared; and I can't create the mapping before the inheriting component is defined because there isn't yet an application to attach it to.
Is there any way I can reference the parent directory to accomplish my extends?
Edit to clarify: The ApplicationProxy solution doesn't work because of the bolded text above. Right now, as a workaround, we're simply not checking the \dir\application.cfc into SVN so that each developer can keep a version that extends his/her own root application.cfc. Obviously, this is not ideal.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
Sean Corfield 有一篇博客文章解释如何扩展根 Application.cfc 。
以下是从该条目复制的相关信息。
这是您的根 CFC /Application.cfc:
这是您的代理 CFC /ApplicationProxy.cfc:
它完全是空的,仅用于为您的根 /Application.cfc 创建别名。 这是您的子目录 CFC /app/Application.cfc:
每个单个站点的根目录应该有自己的主应用程序:
所有这些应用程序都是单独的单独应用程序,它们之间没有任何共享。
如果这些单独的站点中的任何一个需要有子应用程序,那么在主应用程序旁边应该有 ApplicationProxy.cfc,
然后,对于每个子应用程序,您都有一个扩展代理的子应用程序:
Sean Corfield has a blog entry explaining how to extend a root Application.cfc.
Below is the relevant information copied from that entry.
Here's your root CFC /Application.cfc:
Here's your proxy CFC /ApplicationProxy.cfc:
It's completely empty and serves merely to create an alias for your root /Application.cfc. Here's your subdirectory CFC /app/Application.cfc:
The root of each individual site should have its own Master App:
All these applications are separate individual apps with nothing shared between them.
If any of these individual sites need to have sub-applications, then there should be ApplicationProxy.cfc alonside the Master,
Then, for each sub-application you have the one that extends the proxy:
以下代码对我有用。 但我注意到的一件事是 application.cfc 似乎已被缓存,因此可能不会反映对父应用程序 cfc 的更改。 我通过对子应用程序 cfc 进行一些简单的更改来解决这个问题。
The following code is working for me. One thing I noticed though is that the application.cfc seems to get cached, so changes to the parent application cfc might not be reflected. I got around this by doing a trivial change to the child application cfc.
我知道这是一个老话题,但我找到了一种方法来做到这一点(在我的测试中似乎有效),而无需使用 CF 管理员映射。
您可以通过使用扩展的相对路径在子 Application.cfc 中添加每个应用程序映射来做到这一点:
是的,这感觉有点 hacky,但它似乎有效。
I know this is an old topic, but I found a way to do it (that seems to work in my testing) without using the CF Administrator mappings.
You can do this by adding a per-application mapping in your child Application.cfc using an expanded relative path:
Yeah, it feels little hacky, but it seems to work.
爱德华等人,我在下面的帖子中提到了您的评论。 请参阅 https://gregoryalexander.com/blog /2021/1/30/Extending-Applicationcfcs-using-mappings-and-proxies
您绝对可以使用映射来扩展 cfc。 我必须自己做。
我在 ColdFusion 中必须处理的最令人沮丧的事情之一是尝试创建一个向公众开放的外部应用程序,并且必须使用子文件夹中的应用程序来保护该站点的一部分,并从基础扩展逻辑应用程序.cfc。 我将引导您了解开发人员用于解决此问题的当前方法,并向您展示当可能存在使用虚拟目录的托管提供商时如何额外使用映射。
这是一篇相当长的文章,如果您想跳到摘要,请向下滚动到本页底部。
许多年前,我第一次尝试执行此操作时,无论我尝试什么,我都会收到以下消息:“找不到 ColdFusion 组件或接口 xxx”。简而言之,使用这种方法的问题是root 和子文件夹具有相同的名称,即 Application.cfc,并且 ColdFusion 无法正确识别要扩展的组件。最后,经过一番认真的调查,有人提出了创建驻留在同一文件夹中的 proxy.cfc 的想法。根目录作为根 Application.cfc,子文件夹中的 Application.cfc 扩展了一个空 proxy.cfc,该代理.cfc 扩展了根 cfc,如下所示:
根目录:Application.cfc
此根 Application.cfc 不扩展任何内容
也在根目录中:Proxy.cfc
Proxy.cfc 有以下代码,它本质上是空的。 Proxy.cfc 所做的唯一事情是扩展同一目录中的 Application.cfc:
子目录,例如名为 admin 的文件夹。
该子目录还有另一个Application.cfc。 假设该组件负责保护应用程序并具有登录逻辑以及调试设置等。 此 Application.cfc 将扩展 Proxy.cfc 以获取根目录中 Application.cfc 的方法和属性,如下所示:
这种方法是天赐之物,并且在博客中被广泛讨论。 本·纳德尔 (Ben Nadel) 发表了许多非常有用的帖子,我将在本文底部分享这些帖子。
除非您位于托管域或使用虚拟目录的服务器上,否则这种方法效果很好。 在这种情况下,我们就处于我们出发时的同一条船上。 现在我们又回到了“找不到 ColdFusion 组件或接口 xxx”的地狱!
虽然这个棘手问题有一个解决方案,但我们还需要使用映射!
这是一个常见的误用词,您不能使用映射来扩展我不太确定这种误解最初是从哪里来的,但事实证明这是不正确的,有些情况下我们必须使用映射来解决一些恼人的问题,就像
这个特定的网站由 hostek 托管的。他们是一家很好的公司,但由于目录结构的原因,我的网站所在的服务器有一些特性。在这里,当我使用 Proxy.cfc 方法从基础 Application.cfc 扩展逻辑时。到 admin 文件夹中的 Application.cfc 时,我收到了可怕的“无法找到...组件”错误。当我第一次看到它时,我很沮丧地想到了这一点,所以我转向 ColdFusion CFC 映射告诉 ColdFusion 在哪里。查找文件以及文件关系是什么。
让我们回顾一下刚才讨论的 CFC 结构。 例如,想象以下目录结构:
根目录:即 www.gregoryalexander.com/
子目录: www.gregoryalexander.com/admin/
正如所讨论的,我们有一个 Application.cfc 和Proxy.cfc 在根目录中,Application.cfc 在“admin”子目录中。 Proxy.cfc 扩展了根目录中的Application.cfc,子目录(admin) 中的Application.cfc 扩展了根目录中的Proxy.cfc。
根目录:包含 Application.cfc 和 Proxy.cfc(扩展根 Application.cfc)。
子目录:Application.cfc(扩展 Proxy.cfc)。
现在我们还需要在根 Application.cfc 中添加以下映射。 此映射逻辑应位于根 Application.cfc 的顶部附近,并且不应位于任何 Application.cfc 事件处理程序(onApplicationStart、onApplicationRequest 等)内。 此映射代码不需要位于根 Application.cfc 之外的任何位置:
我使用 rootCfc 来标识根目录中的 Application.cfc,而 adminCfc 适用于 admin 目录中的应用程序。 这些变量可以命名为任何名称。 请注意,adminCfc 映射末尾的“/admin”字符串指向“admin”文件夹,它是一个子目录。
现在我们在根 Application.cfc 中拥有了映射,我们需要将它们应用到位于子目录中的 Application.cfc 中的 extends 语句。 在 /admin/Application.cfc 模板中使用:
/admin/Application.cfc
当然,rootCfc告诉子目录中的Application.cfc去根目录中寻找Proxy.cfc模板。 与其他“extend”语句一样,您不需要在 Proxy 末尾指定“.cfc”。
您不需要在根 Proxy.cfc 或 Application.cfc 模板中使用此“扩展”映射。 他们已经可以找到对方,因为它们都位于同一根目录中。
/Proxy.cfc
概括
为了绝对清楚起见:
根应用程序.cfc
包含映射逻辑。 具有根目录和子目录的映射。
不使用“扩展”语句
root Proxy.cfm
一个简单的“extends=”Administrator”就可以了。
没有映射逻辑。
子目录应用程序.cfc
extends 语句必须是文件夹的映射变量名称 (rootCfc)、一个点 (.),最后是不带 .cfc 前缀的 Proxy.cfc 模板的名称 (Proxy)
很抱歉这么冗长。 我在写这篇文章时让自己很恼火——但当我试图解决这个问题时却没有那么恼火!
小心!
Edward, et-al, I referred to your comment in the post below. See https://gregoryalexander.com/blog/2021/1/30/Extending-Applicationcfcs-using-mappings-and-proxies
You absolutely can extend a cfc with mappings. I had to do it myself.
One of the most frustrating things that I have had to deal with in ColdFusion is trying to create an external application that is open to the general public and having to secure a portion of that site with an application within a subfolder and extending the logic from base application.cfc. I'll walk you through the current approach that developers use to solve this as well as showing you how to additionally use mapping when there may be a hosting provider that uses virtual directories.
This is a rather long article, if you want to jump to the condensed summary, scroll down to the bottom of this page.
Many years ago, the first time that I tried to perform this, I received the following message no matter what I tried: "Could not find the ColdFusion component or interface xxx'. In a nutshell, the problem using this approach is that both the root and the subfolders have the same name, i.e. Application.cfc, and ColdFusion can't properly identify what component to extend. Finally, after some serious investigation, someone came up with the idea to create a proxy.cfc that resides in the same root directory as the root Application.cfc, and the Application.cfc in the subfolder extends an empty proxy.cfc that extends the root cfc like so:
root directory: Application.cfc
This root Application.cfc does not extend anything
Also in the root directory: Proxy.cfc
Proxy.cfc has the following code, it's essentially empty. The only thing that the Proxy.cfc does is to extend the Application.cfc that is in the same directory:
Subdirectory such as a folder named admin.
This subdirectory has another Application.cfc. Let's say that this component is responsible for securing the application and has login logic as well as debugging settings for example. This Application.cfc will extend the Proxy.cfc to gain the methods and properties of the Application.cfc in the root directory like so:
This approach was a godsend and it was heavily blogged about. Ben Nadel has made a number of very helpful posts which I will share at the bottom of this article.
This works quite well unless you're on a hosted domain or a server that uses virtual directories. In this case, we are in the same original boat in which we started from. Now we are back into the "Could not find the ColdFusion component or interface xxx' hell!
There is a solution for this tricky problem though, we need to also use mapping!
It is a common misnomer that you can't use mapping to extend components. I am not quite sure where this misconception originally came about, but it has been proven that this is just not true. There are occasions where we must use mapping to solve some annoying problems, like here.
This particular site is hosted by hostek.com. They are a fine company to deal with, but the server that my site is hosted on has some idiosyncrasies due to the directory structure. Here, when I use the Proxy.cfc method to extend the logic from the base Application.cfc to the Application.cfc in the admin folder I receive the dreaded 'could not find the ... component' error. When I first saw it I was dismayed thinking not this again, so I turned to ColdFusion CFC mapping. Mapping tells ColdFusion where to find the file and what the file relationships are.
Let's review CFC structure that was just discussed. For example, imagine the following directory structure:
root directory: i.e. www.gregoryalexander.com/
subdirectory: www.gregoryalexander.com/admin/
As discussed, we have an Application.cfc and the Proxy.cfc in the root directory, and we have the Application.cfc in the 'admin' subdirectory. The Proxy.cfc extends the Application.cfc, also in the root directory, and the Application.cfc in the subdirectory (admin) extends the Proxy.cfc in the root directory.
root directory: contains both Application.cfc and Proxy.cfc (that extends the root Application.cfc).
subdirectory: Application.cfc (that extends Proxy.cfc).
Now we need to also add the following mapping in the root Application.cfc. This mapping logic should be near the top of the root Application.cfc, and it should not be within any of the Application.cfc event handlers (onApplicationStart, onApplicationRequest, etc). This mapping code does not need to be anywhere else other than the root Application.cfc:
I used rootCfc to identify the Application.cfc in the root directory, whereas adminCfc applies to the Application in the admin directory. These variables can be named anything. Note that the "/admin" string at the end of the adminCfc mapping points to the 'admin' folder, which is a subdirectory.
Now that we have the mappings in the root Application.cfc, we need to apply them to the extends statement in Application.cfc located in the subdirectory. In the /admin/Application.cfc template use:
/admin/Application.cfc
Of course, rootCfc tells the Application.cfc in the subdirectory to look for the Proxy.cfc template in the root directory. Like other 'extend' statements, you don't need to specify '.cfc' at the end of Proxy.
You don't need to use this 'extend' mapping in either the root Proxy.cfc or Application.cfc templates. They can already find each other as they are both in the same root directory.
/Proxy.cfc
Summary
For the sake of absolute clarity:
root Application.cfc
Contains the mapping logic. Has the mappings for both of the root and subdirectory.
Does not use an 'extend' statement
root Proxy.cfm
A simple 'extends="Administrator" works.
No mapping logic.
subdirectory Application.cfc
The extends statement must be the mapping variable name of the folder (rootCfc), a dot (.), and finally the name of the Proxy.cfc template without the .cfc prefix (Proxy)
My apologies for being so verbose. I annoyed myself while writing this- but not as annoyed when I was while trying to solve this problem!
Take care!