Why CF8 Application Specific Mapping won't solve all of our woes

I have seen some comments around the interwebs about ColdFusion 8 application specific mappings solving the problem of using frameworks in shared hosting environments and in environments where global mapping is discouraged. I know that I have come across at least one situation where this is not the case, and I though I would share.

Don't get me wrong, I think application specific mappings are wonderful, and the commenters are mostly right in what they say, in MOST cases, application specific mappings will make hosting in a shared environment much easier.

Firstly, one caveat to having Application Specific Mapping on your shared host is for them to allow it. Of course, the advice here is, if they won't allow it, go elsewhere. There are plenty of other hosts out there that will allow it.

The second issue can be seen in this little snippet from Application.cfc on a standard Mach-II site.

 

 

 


<cfcomponent displayname="Application" extends="MachII.mach-ii" output="false">
<cfset this.name="AppName">
<cfset this.loginstorage="session">
<cfset this.sessionmanagement="true">
<cfset THIS.mappings["/MachII"]="c:\MyFrameworks\MachII">
...
</cfcomponent>

If you see the problem, raise your hand.

Of course, the problem is, the Application.cfc is Extending MachII.mach-ii before we are able to declare the mapping for MachII. This means that any existing mapping would override our and it would mean that if the MachII folder was not at the root level of the site, that the application would not be able to find it at all.

There are two solutions to this, the first being to move MachII to the webroot. The second option is to create a server side mapping. Now to be a good Shared Hosting Neighbor, you do not want to create a global mapping called MachII, since others on the server are probably using a different version of MachII than you. So you should create a server-side mapping with a unique name. For example, I would place my MachII folder in c:\wwwroot\MyFrameworks\Robot\. Then I would have my host create a mapping called "/robot".

Now, I can extend robot.MachII.mach-ii and then create my application specific mapping to "/MachII", using the same copy of MachII, for the rest of the app to use.

Comments
ike's Gravatar

imo the notion of having the application.cfc extend any kind of framework component is poor convention. I'd much rather see the framework either instantiated within the application.cfc or have the Application.cfc as part of the framework itself. The problem with the latter is that I always want to give people a way to change the application without editing my files -- my core files should be treated as "read only". Fortunately I've found lots of ways to accomplish that, so the application can still take advantage of onApplicationStart, onRequestStart, etc. without making any edits to the Application.cfc.

# Posted By ike | 4/29/08 3:11 PM
Peter J. Farrell's Gravatar Jason, I did find a simple workaround. Create an application specific mapping to MachII but instead of extending MachII.mach-ii in your Application.cfc copy the mach-ii.cfc into the same directory as your Application.cfc. Application specific mappings are available once ColdFusion has begun processing application events (i.e. onApplicationStart, onRequestStart, etc.) so by the time onApplicationStart is hit, the mapping is available for use.

You can see the FAQ I wrote here:
http://greatbiztoolsllc-trac.cvsdude.com/mach-ii/w...

@Ike, your solution doesn't work if MachII is in a completely separate directory. I tried your solution, but it doesn't work. I think you were fooled because you have MachII in yoru webroot and that is one of the locations that ColdFusion checks when it tries to locate a CFC.
# Posted By Peter J. Farrell | 6/11/08 9:33 PM
ike's Gravatar It took me a minute to get my bearings because when I got the email about your comment being added, I thought you were replying to a comment I left on your blog rather than on Jason's, that I'd left actually before I started working on the Galleon ports.

For anyone else reading this who might be confused about what my solution was, here's mine: http://ontap.riaforge.org/blog/index.cfm/2008/5/27...

Anyway I'm not sure why it would be failing in your environment, but it's working in mine. I have a lot of things in my c:\apache\htdocs\ directory, but a MachII directory isn't one of them. I do however have a MachII directory at c:\apache\htdocs\galleon\MachII\ and that copy appears to be adequately handling my copy of the Galleon port in c:\apache\htdocs\galleon\mii\ .

I actually just now double-checked all these things to be certain since you said it wasn't working for you. I don't have MachII mapped in the admin, the mach-ii.cfc I have in my /galleon/mii/ directory just contains the cfinclude tag, and if I comment out the mapping in my Application.cfc, then I get the error "Could not find the ColdFusion Component or Interface MachII.util.Utils." -- So it's very definitely working to support MachII in an alternate directory in my environment. Not sure why it wouldn't be working for you though.
# Posted By ike | 6/11/08 10:02 PM
Jason Dean's Gravatar I thought mine was a pretty simple solution :(

But really, thanks for the tip Peter. I think i still like my solution for the situtation i was thinking of, which I doubt I mentioned.

I was thinking of a hypothetical large company with dozens of web apps. Over the year they have used 6 or 7 different versions of Mach-II or xxx framework. Instead of trying to upgrade the old apps, they just create a new server mapping with each new version of Mach-II. /Mach-II-1.1 /Mach-II-1.5, /Mach-II-1.6, /Mach-II-2.0, etc.

Then which ever version the app developer wants to user, they just extend their App.cfc to that mapping and then create a app specifc mapping to the same directory but call it /Mach-II.

Then if they want to try upgrading to a different version, there are no files to copy, they just change two settings in App.cfc and reinitialize. If it doesn't work, CTRL-Z

It would also be more clear to the developer that was looking at the App.cfc which version of the framework was being used.

My line of reasoning comes out of theory only. I have never actually set up something like this. I may be missing something.
# Posted By Jason Dean | 6/11/08 10:03 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner