Need Help Making A Viable ExpandServerPath() ColdFusion UDF

Posted July 3, 2007 at 2:39 PM

Tags: ColdFusion

ColdFusion provides a built-in function, ExpandPath(), which gives you a fully expanded server path based on the currently executing script. The problem is, a lot of our application templates are NOT on the same level as the currently executing script. Furthermore, if you are using some sort of URL re-writing, the real executing script and the web-visible executing script are not the same values.

What we need is a new function: ExpandServerPath(). This function would act in exactly the same way, only the passed in path (function argument) would be relative to the calling template and would have nothing to do with the executing script.

Back in November, I talked about using a CFTry / CFCatch block with a manually thrown exception to find out the calling template of the given function. I have taken that methodology and wrapped it up in the new ExpandServerPath() ColdFusion user defined function:

 Launch code in new window » Download code as text file »

This function would then just be called like ExpandPath():

 Launch code in new window » Download code as text file »

This would be looking for a DAT file within the directory "data" which is a sub directory of the directory containing the currently executing TEMPLATE (not the root script).

It works, so what's the problem? The problem is, it's not a good methodology. It's one thing to have something like this in a development environment where speed / processing drain is not that critical. But, putting something like this up in a production server is a huge No No. Creating exceptions is a very processing heavy activity. This is certainly not something that we want to be doing all the time.

Does anyone have any suggestions on where to improve this? I tried using the ColdFusion debugging information, but information about a processing template only gets put into it once the template has finished processing (which would not work since we need information about the currently processing template).

Help??

Download Code Snippet ZIP File

Post Comment  |  Ask Ben  |  Other Searches  |  Print Page

• Add To Del.icio.us
• Add To Digg
• Add to Spurl.net
• Add to Wists
• Add to Simpy
• Add to Newsvine
• Add to BlinkList
• Add to Furl
• Add to reddit
• Add to FARK
• Add to BlogMarks
• Add to Yahoo! My Web
• Add to smarking
• Add to Ma.gnolia
• Add to Segnalo

Reader Comments

Hey Ben! It was nice meeting you at the CFUNITED conference. Again, thanks for all of the posts.

I'm wondering why you wouldn't use GetBaseTemplatePath(). Doesn't that return the same information that grabbing the TagContext provides? Or am I missing something...

@Toby,

Really good to meet you to. I don't know why, but when you were talking, you sound exactly like Rob Lowe to me. I don't know if anyone has ever said that or if I have just watched Tommy Boy like a couple hundred too many times :)

As far as GetBaseTemplatePath(), you can actually use something similar to get a relative path, except with GetCurrentTemplatePath(). So, for the example above:

GetDirectoryFromPath( GetCurrentTemplatePath() ) & "data/2007_07_02.dat"

... would give us the same thing. But, to me,

ExpandServerPath( "./data/2007_07_02.dat" )

... just seems more elegant. Of course, I tend to do things that people later will tell me are bad practice, so it's possible that there is no need for this type of a template.

Additionally, my UDF will integrate the path constructs like "./" and "../" right into the returned path (rather than just appending it).

Of course, I might be totally missing something, so if you have an example to look at that you think might help, I would as always, be very greatful.

Yeah, use the getBaseTemplatePath() as your starting point. Much faster.

But, doesn't GetBaseTemplatePath() only return the top-level ColdFusion page. This won't work for any CFIncluded pages that need to get a relative path?

@Ben:

It's never good to throw an error when you can avoid it. (Throw/catching errors is slow.) Instead, use the code you posted as your starting point:

GetDirectoryFromPath( GetCurrentTemplatePath() ) & arguments.Path

You can then always clean up the path if you want so that the directory pathing ("." and "..") is cleaned up.

@Ben:

If you want the current template, use getCurrentTemplatePath().

That will get the current template you're in.

@Dan,

Certainly, I do not want to throw and catch errors on the production site. This is a new function, I don't actually use this anywhere. But, I like the idea of it. I wouldn't use it, as I know it is slow. I am posting it up just so people can see what I want to try and do and then offer suggestions. Of course, it might just not be possible.

My current methodology is using the GetCurrentTemplatePath() and all that jazz, but it just never feels elegant.

@Ben:

By why don't you use the getCurrentTemplatePath() in this function instead of throwing the error?

@Dan,

Because the GetCurrentTemplatePath() will give me the path of the template in which the UDF is defined. I need to go up one level to get to the template that invoked the UDF. That's why when I grab out of the Exception tag context, I grab index 2.

I can't think of any other way to get the calling template. It would be interesting to see *how* slow your UDF is; is it really that bad performance-wise?

@Aaron,

Good point. I have never tested this for speed. I have only been told that it is fast. I assume that it is nothing that would scale, but I'd be willing to run a loop :)

Ben,

I'm not sure I understand your desired function completely... you want the full path to any file where you give the relative path to the calling template? Well, that's exactly what ExpandPath() does...

ExpandPath( "./data/2007_07_02.dat" ) will give you the full path, so what's the difference to what you need?

Chris

@Chris,

ExpandPath() goes relative to the base template. For instance, imagine we had this code in the base template:

<!--- Called from top level. --->
#ExpandPath( "./" )#
#ExpandServerPath( "./" )#

<!--- Include sub directory template. --->
<cfinclude template="expand_server_path/test.cfm" />

... And then we had this in the include:

<!--- Called from sub-directory level. --->
#ExpandPath( "./" )#
#ExpandServerPath( "./" )#

... This would give us the following output:

D:\....\site_v1\testing\
D:\....\site_v1\testing\

D:\....\site_v1\testing\
D:\....\site_v1\testing\expand_server_path\

Notice that at the top level template, both in fact do the same thing. However, once you go into an include, ExpandPath() is still relative to the base template, where as ExpandServerPath() is relative to the currently executing template.

Does that clear up the difference in functionality?

Hi Ben,

Somewhat related to your post I have a technique here http://www.petefreitag.com/item/630.cfm for finding the application root (the dir containing the acting application.cfm file), you can then use that path and add to it. I know it doesn't solve your problem here but, I thought you might find it handy...

@Pete,

Thanks. If for no other reason, it's always good for people to see more recursive function examples so they can wrap their heads around it.

If I know that the path to my root is 5 slashes into the hard drive, I can use this:

<cfloop index="i" from="5" to="#ListLen(GetBaseTemplatePath(), Chr(92))#">../</cfloop>

to get the proper relationship.

@Dave,

I am not sure that I follow - wouldn't that take you to the root of the server?

Post Comment  |  Ask Ben

Post A Comment

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.

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Formatting: <strong>bold</strong> <em>italic<em>
	Remember my information
	Subscribe to entry *
	Send me a copy of this comment (as part of the comment thread)

 

* If you subscribe, any new posts to this thread will be sent to your email address.