Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at the New York ColdFusion User Group (Jan. 2009) with:

ColdFusion ExpandPath() And GetCurrentTemplatePath()

By Ben Nadel on
Tags: ColdFusion

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(
  • GetCurrentTemplatePath()
  • ) />

Assuming that we have the current directory structure:

sites
..test
....index.cfm
....sub
......test.cfm

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:

D:\sites\test\

and the second path would be:

D:\sites\test\sub\

So anyway, just keep that in mind. We use CFIncludes so much in ColdFusion that I feel it easy to make this mistake.




Reader Comments

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...

Reply to this Comment

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 :)

Reply to this Comment

@Dan,

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).

Reply to this Comment

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)#

Reply to this Comment

@Erik,

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).

Reply to this Comment

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

Root
css.css
Index.cfm
..Includes(Folder)
Header.cfm
Footer.cfm
..Test(folder)
test1.cfm

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?

Thanks

Reply to this Comment

@Mike,

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.

When you define your CSS URLs, they need to be relevant to the browser, not the include. Typically, you can either make linked assets like this (CSS, Javascript, Images, etc) always point to the root, example:

/css.css

... or you can create paths relative to the page you are currently viewing, example:

../css.css

... 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:

http://www.bennadel.com/blog/1655-Ask-Ben-Dynamic-Web-Root-And-Site-URL-Calculations-In-Application-cfc.htm

This will explain the matter a bit better.

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.