ColdFusion ExpandPath() And GetCurrentTemplatePath()
Posted September 21, 2006 at 3:33 PM by Ben Nadel
One of the things that always get's me is the fact that in ColdFusion, the ExpandPath() method expands the path of the base path. I would say 95% of the time, this doesn't matter, but the other 5% of the time, I end putting stuff in the wrong directories. In my head, it just makes sense that ExpandPath() should expand the current template path since that is the one calling the code (just how the CFInclude template attribute works).
When I do need to expand the current path, not the base one, I just use the GetCurrentTemplatePath(). And, since expand path is meant to add to a directory, I get the directory from the returned path:
- <!--- Get expanded path of the BASE path. --->
- <cfset strPath = ExpandPath( "./" ) />
- <!--- Get the expanded path of the CURRENT template path. --->
- <cfset strPath = GetDirectoryFromPath(
- ) />
Assuming that we have the current directory structure:
and that our CGI.script_name points us to the page "index.cfm" but the code is being executed by the CFIncluded page, test.cfm, the first path would be:
and the second path would be:
So anyway, just keep that in mind. We use CFIncludes so much in ColdFusion that I feel it easy to make this mistake.
What Other People Are Searching For
[ local search ]
[ local search ] getting expanded path of sub folder
[ local search ] get expandpath for current template
[ local search ] getdirectoryfrompath expand
[ local search ] coldfusion expand path
[ local search ] coldfusion get current directory path
[ local search ] expand current path coldfusion
- Wanted: Full-Time ColdFusion Developer at Intoria Internet Architects
- Cold Fusion Senior Developer at Edge Information Management
- Back-End Web Developer-Information Technologist at Michigan State University
- ColdFusion Developer at Nonfat Media
- Mid-to-Senior Level Web Application Developer at SiteVision, Inc.
Thanks Ben - your Blog has to be the most useful resource out there when it comes to CF Quirks - I remember reading this entry a couple of years back - first port of call when I needed to do this...
I am always happy to hear that I have provided some value - thanks.
Hopefully this tip will help someone down the road too, or maybe someone can enlighten me as to the "right" way to code for the physical file path of an application.
I was setting the following code in the OnApplicationStart() method to set the application's physical file path (http://mydomain.com/myApplication):
<cfset application.rootpath = expandPath('./')>
The application uses index.cfm as a "controller" (i.e.index.cfm?disp=thispage) so I THOUGHT it would set the path relative to the root of the application (C:\inetpub\wwwroot\mydomain\myApplication)
Well, it does...MOST of the time....I still haven't gotten to the bottom of it, but sometimes the rootpath would get set to nested directories (C:\inetpub\wwwroot\mydomain\myApplication\middle\). I can only assume that the application would sometimes reinit when it was in the middle of processing something in the "middle" directory.
Long story short, I'm about to deploy this code fix to (hopefully) resolve the problem: <cfset application.rootpath = "#expandpath('/')##application.applicationname#\"> . The application.applicationname is the same as the "myApplication" directory, so I'm hopeful that this will work....at least my three test runs worked..lol
With any luck, all this code will actually show up so its readable on Ben's blog :)
The strategy that I have found to be very helpful is using:
getDirectoryFromPath( getCurrentTemplatePath() )
... inside of Application.cfc. Since you always know where the Application.cfc file lives, you know you can get the root directory by stripping off "Application.cfc" from the current template path (which is Application.cfc).
Here is a neat little script that gets just the current file name, no url variables or directories. I found that all the other examples return subdirectories and url info or the cfincluded file name. I just wanted the .cfm filename for writing log files.
#right(cgi.script_name, find('/', reverse(cgi.script_name), 1) - 1)#
getDirectoryFromPath() has a sibling function, getFileFromPath() that should help make that even easier:
#getFileFromPath( cgi.script_name )#
... should return the file name from the script name (or any other slash-delimited string).
Ok I'm been trying to fiqure this out for a long time.
I'm trying to get my structure organized. Say I have this
I'm trying to use header.cfm in multiple sub files of the root via cfinclude. But my css etc doesn't follow in the header.cfm depending on the location of file when I call the include.
So on my header.cfm I have
<link href="general.css" rel="stylesheet" type="text/css">
so index.cfm works great.
but on /test/test1.cfm it doesn't apply css because path is still
<link href="general.css" rel="stylesheet" type="text/css">
Am I going about this wrong? Is there a solution to expand the header.cfm pased on the callings page location.
Is the the industry standard to organizing files?
I think you are getting two different types of pathing mixed up. There is the pathing on the server, and then there is the pathing in the browser. On the server, you can use things like expandPath() and getCurrentTemplatePath() and getBaseTemplatePath() and a number of other things to deal with how files are related on the server-side.
CSS, however, is a concern of the browser. The URL that you provide for your CSS file is one that the browser has to make *back* to the server after the initial page has been pushed to the client. The Browser has no concept of the internal Include-structure on the server; as such, there is not inherent relationship between your includes and your CSS files.
... or you can create paths relative to the page you are currently viewing, example:
... which goes UP one directory to get to the CSS.
I personally prefer the "../../" style approach as it can be generated dynamically without hard-coding any logic in the application.
Check out this post:
This will explain the matter a bit better.
You can use Long Path Tool for such issues..