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.
I would imagine that approach has some performance implications if you were
doing it often.
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.
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.