Sunday, February 15, 2004

Mach-II in Shared Hosting Environments

It was bound to happen sooner or later--my next side project with Mach-II is going to live in a shared hosting environment, so I decided to do some preliminary work getting things up and running before the project really gets rolling. Up until this point I've been doing Mach-II work for i2 on dedicated servers, so I haven't had to worry about how CFMX finds the CFCs.


I personally felt that my hosting account with HostMySite was a little limiting (no ability to create my own mappings, for example, although they're happy to do it for you), so since my account with them was coming up for renewal anyway, I decided to try CrystalTech since I'd heard so many other CF developers say they were happy with them.

Please note that I'm a big fan of HostMySite in general--they have great tech support and I will continue to heartily recommend them to clients; I personally just wanted to try something different and liked the idea that CrystalTech let me set up my own mappings at will, and I also get more database space and have both SQL Server and MySQL databases for less money.

Just one quick complaint about CrystalTech: when I called in with some general problems with CFCs and my mappings working initially, I got a .NET developer on the phone with an extremely large .CHIP on his .SHOULDER. Some actual quotes from this guy:

  • "Sir, I'm a .NET developer. I'm not a newbie programmer so I know what I'm talking about."

  • "ColdFusion doesn't start looking for objects in your docroot, it starts at the System32 directory. I know because I'm a .NET developer."

  • Nevermind the fact that A) I wasn't calling about .NET, and B) that second statement isn't even TRUE in .NET (at least not in my experience on the two .NET projects I've done); my main issue with this guy is that he's supposed to answer my questions, not tell me how he's so much smarter than I am. Minor complaint but if you're on CrystalTech and get this guy on the phone, hang up and call back later. Extremely rude, extremely unhelpful, and just an out-and-out .JERK.

    Back to the topic at hand: Since the server I got put on at CrystalTech already had the mapping "MachII" taken, I had to set up a different mapping, which means you also have to alter all the Mach-II core framework files to reflect this mapping. This isn't anything a global search-and-replace can't handle, and once I got my bearings and had my mapping set up, I had Mach-II running fine with a different mapping.

    After taking an initial stab at this, since I recalled that MVCF used a variable as a prefix to all the CFC locations, I thought maybe I could save *some* of the work by setting up a variable for my mapping and using that variable where possible in the Mach-II core files. I say "where possible" because of course the type parameter in cfargument won't accept a variable, and neither will extends in your cfcomponent tag, so basically all that using a variable really gains you is a dynamic setting for your CreateObject methods and a few other minor things. After trying this approach I decided consistency was probably a better idea so I reverted back to using my mapping name in place of "MachII." in the core framework files.

    The only other thing I noticed that I had to do was set the MACHII_APP_KEY variable in my mach-ii.cfm file to the name of my mapping as opposed to letting it do GetFileFromPath(ExpandPath(".")). Again, this isn't a big deal, but since I've been on dedicated servers to this point I'm a little unclear as to exactly what the MACHII_APP_KEY variable does.

    I posted a message to the Mach-II forum on to get some other thoughts on this situation in general. Since building Mach-II apps on shared servers is probably something I'll be doing a lot of in the future I just want to make sure I'm doing it in the best way possible.

    The bottom line is getting Mach-II up and running in a shared hosting environment didn't take much time at all, and at least from what I can tell thus far, is working great. As I figure out more and more about using Mach-II in shared environments I'll be sure and pass along any tips, tricks, and "gotchas" I happen to experience.

    1 comment:

    Summer S Wilson said...

    Thanks for this post, it just saved me from a lot of headaches! Doing my first Mach-II install in a hosted environment and was getting all kinds of funky errors because someone else already had the MachII path. Followed your advice and its working like a charm :-)