BlueDragon Blog
Here you'll find tips and information about making the most of BlueDragon, which offers several compelling implementation alternatives for your CFML applications. This blog was created originally by Charlie Arehart, who was New Atlanta CTO from 2003-2006.,He has since moved on to become an independent consultant but continues to answer comments raised in existing blog entries. BlueDragon continues, and you should look to the newer BlueDragon blog, from New Atlanta president, Vince Bonfanti, for more updated information.

GetDirectoryParent: A .NET trick for CFML coders (on BlueDragon/.NET)

posted Monday, 7 November 2005

Ever needed to get the name of a given directory's parent? Sure you can just append "/.." in many tags (like CFDIRECTORY) to go up a level, but what if you really need its name? .NET offers a nifty solution, and you can access it in CFML, on BD/.NET. (Java offers  a solution as well, which I'll show below.)

Just as CFML developers on CFMX and Java editions of BlueDragon can leverage nifty Java class library objects and their properties and methods to do things that CFML may not offer, so too does the .NET Framework also offer many (4500+) such classes. I wrote about acessing either Java or .NET objects from CFML, in my May 2005 CFDJ article, "Getting Started Integrating CFML with Java & .NET", available at http://cfdj.sys-con.com/read/86127.htm.

Since then, I found myself needing to get the name of the parent of a given directory for a browsing tool I was writing, and I wondered if .NET might offer a solution. Indeed it does, in the "getparent" method of the System.IO.Directory class. That returns a class of type DirectoryInfo, which then has a "fullname" property which can be accessed in BD/.NET using get_fullname (see the article and our docs for issues related to our J# heritage under the covers).

Anyway, here is the code to get the parent of my "c:\bluedragon.net\web site 1\work\temp" directory:

<cfset workdir="c:\bluedragon.net\web site 1\work\temp">
<cfobject class="System.IO.Directory" type=".net" action="CREATE" name="directoryclass">
<cfset updir = directoryclass.getparent(workdir).get_fullname()>
<cfoutput>#updir#</cfoutput>

the result would be "c:\bluedragon.net\web site 1\work". Nifty. There are many, many more such interesting tricks possible. Again, see the BD/.NET documentation dozens of far more compelling capabilities to truly intergrate CFML with .NET.

For those needing this solution on CFMX or the Java editions of BlueDragon, here's a corresponding solution using Java, which works just a little differently but produces the same result:

<cfobject type="java" class="java.io.File" action="CREATE" name="dirclass">
<cfset dirobj = dirclass.init(workdir)>
<cfset updir = dirobj.getparent()>
<cfoutput>#updir#</cfoutput>

Here's something else that's interesting: BD/.NET will also run the code above. Yep, even with the type="java". Again, it relates to the fact that we leverage J# under the covers, so we still have access to many Java libraries as enabled by the J# redistributable, which is installed by BD/.NET. So technically either solution will work, but one benefit of working with .NET is that Microsoft is always looking to improve ("embrace and extend") the kind of functionality provided by Java, adding it to .NET.

So on .NET, it's best to look to the native .NET libraries first, but it's nice to know that older Java references may still work. The beauty of BlueDragon is that we make your CFML work effectively on either platform.




1. Spike left...
Monday, 7 November 2005 2:51 pm :: http://www.yellowbadger.com

I would imagine that approach has some performance implications if you were doing it often.

I prefer this:

<cfset workdir = getCurrentTemplatePath() />

<cfset pathArray = listToArray(workdir,"/\") />

<cfset arrayDeleteAt(pathArray,arrayLen(pathArray)) />

<cfset updir = arrayToList(dirArray,"/") />

<cfoutput>#updir#</cfoutput>

It's reliable, it works on all platforms and it's fast.


2. Charlie Arehart left...
Monday, 7 November 2005 11:12 pm

Fair enough, Spike. The real significance isn't whether the approach is the fastest way to accomplish a task but as much as about simply making people aware of the option to leverage .NET features directly. Time will tell whether one or another approach for a given specific task is best in particular circumstances.


3. Joseph Spaur left...
Wednesday, 7 December 2005 6:11 pm

System.IO.Path has a bunch of extremely handy static methods regarding getting file names, etc. Its one of those things that if you aren't paying attention, you'll end up duplicating in one of your Utils libs.