Months Archive March 2007

 
 

Coldfusion Community on Fire

I really could of had a future in writing cheesy headlines for newspapers. Although this blog tends to be more for new ideas so much has been happening in the past week related to Coldfusion, it seems proper to give an update post on a few very interesting developments which I can see being extremely useful for developers and anyone considering Coldfusion alike.

The first of which you’ve probably heard about by now — Coldfire. There are a few tools when developing at home I use constantly — Firefox, Eclipse/CfEclipse, Firebug (and a few other extensions to a lesser degree) and now Coldfire; that’s how big a deal it is. So what is it? Well if you use Firebug pull it up and follow along. You’ll notice in Firebug there’s a tab based setup with the first few being console, HTML, CSS, script, etc. Coldfire adds another ones to this list — ColdFusion. In order for this to work, you need to add a new “debug” file in your coldfusion folder on your dev site, and then set it up in CF Administrator, which only takes a click. What it shows includes query information, execution times and information from any cftrace calls you had during your page. If you’re unfamiliar with cftrace, you’re able to hit points in your ap you can check. One very cool thing about cftrace, Coldfire and specifically the custom debugger is that nothing at all is added to your application. If you’ve ever worked with Ajax and Coldfusion debugging you know how much of a pain it is to disable that each time you’re making an ajax request and need specific feedback. This should make dev with debugging easy as can be.

Another hot new addition (the puns just keep coming) is GotCFM.com. This is a very simple site with one purpose — show who’s using Coldfusion and just generally evangelize it. There’s already 727 sites listed on there, which is just amazing progress. Can’t wait to have some sites to add of my own.

The last item isn’t new exactly, but it is becoming important so I’ll admit it — I’m slowly falling for ColdBox. I’ve decided to give it a shot with a very simple ap I’m building that’ll use Coldbox/Coldspring/Reactor/Coldcourse/OpenID and, ideally, shouldn’t take too long. Due to the nature of some of it though I probably can’t do much with it until June. Either way Coldbox is definitely something you should look into when considering coldfusion frameworks. Although there’s not a huge developer community (yet), there’s amazing work out there as well as more documentation than I’ve had the chance to read. What’s been most amazing about Coldbox is just how easy it is to pick it up and get going. Yesterday after about an hour I had a simple login system using OpenID that saved users to a DB using a service layer generated by reactor/coldspring and with nice URLs from Coldcourse of course ;) . Definitely looking forward to digging into some of the meat of the framework suhc as caching, internationalization and plugins next. If you’re wanting to get a little hyped up about Coldbox, there’s an interview with Luis Majano over at CFFrameworks.com.

Playing to Strengths

The hardest thing to work is almost always your weakness. My weakness has historically been design where I end up wasting countless hours trying to do something relatively simple to have it come out looking, well, not so great. This is the kind of thing that I’d happily pay (reasonably) to come up with a solution I could live with. For site layouts that could mean finding a great layout on a free site such as Open Source Web Design, buying a coded layout from the millions of template sites like Template Monster, buying a unique layout from a forum, hiring a designer or having a design contest. To me any of these are better than doing it myself in the end. Although the technical knowledge isn’t incredibly hard to grasp the code of a layout, getting everything just right is a skill I just do not have, which is why I decided to go with an already coded template for the redesign of AdamFortuna.com.

It was finally time to upgrade to Wordpress 2.1.2 while at it as well. Since I host at Dreamhost, this was easier than easy. They have a growing set of “One Click Installers” in the revamped control panel, which also manage which version of each software you’re using. Upgrading was as easy as clicking here, jumping to the wordpress install script to do the database updates, and crossing my fingers. Although I had backups at hand, it worked without a glitch. My themes were transferred, my plugins continued to work, it was shockingly easy. A few plugins didn’t work right off though, such as the coding markup when posting which disappeared, but the major plugins continued to function such as a tag warrior, MicroID, OpenID, Google Analytics and Feed Burner redirect. Hopefully that’s the last of the upgrade problems for now though.

ColdCourse: Search Engine Safe URLs for Fusebox, Mach-II, Model-Glue and ColdBox

One thing that’s always been left out of Coldfusion frameworks (with the exception of Coldfusion On Wheels) is URL handling. This is a big thing. It’s not essential for making an application, and it certainly can be a time drain to get URLs just right. Ruby on Rails started a trend in controlling URLs not through URL rewriting, but more tightly bundled into the framework. Coldfusion on Wheels did this too, although it didn’t get that much attention for what was one of the most amazing innovation of any CF framework I’d seen in a while.

So what is ColdCourse? ColdCourse is a framework agnostic routing system that will execute before the framework. You know that index.cfm file that you’re never supposed to touch? Well this is a modification to that. Before the request hits your framework, ColdCourse will translate the URL into the URL variables you’re expecting, and set them back to the URL scope. Here’s an example:

http://localhost/index.cfm?fuseaction=home.main

Would be the same as…

http://localhost/home/main

In the configuration file for ColdCourse you setup a few things to identify the framework you’re using, such as what the event variable should be (fuseaction, event), what the separator should be (it’s always a period for fusebox and coldbox, but you could be using anything for Mach-II or Model-Glue), what the default action should be if you don’t include an action and more.

You’re probably thinking that with Mach-II and Model-Glue you really don’t have to have URLs that are in the form “controller.action”. Well you’re right. In order to use ColdCourse though, you’ll need to follow a convention where every single event in your framework has exactly one controller and exactly one action. I think you could also make it work if you have all single world actions as well by setting the separator to “” and the action to “”, but I have not yet tested that out, and you would be unable to use ANY controller/action pairs.

Default Actions
Don’t let all this controller/action talk make you think that all URLs must contain both. There are quite a few ways to tweak the URLs to do what you want. The easiest way is through the FrameworkActionDefault set in the config file. Lets say you default this to “index”, then when you go a URL that only sets the controller, this will be automatically set as the action. For instance:
http://localhost/home/index would be the same as http://localhost/home.

Unique URLs
With all these different URLs flying around there’s a chance a search engine might pick up both those, or even worse — 3! You probably don’t want Google deciding which of these URLs is your REAL URL, so ColdCourse handles that. For instance, if someone goes to that initial URL we mentioned, http://localhost/index.cfm?fuseaction=home.main, ColdCourse will issue a 301, permanently moved header response and using a header location redirect them to http://localhost/home/main. Also, if a user goes to http://localhost/home/index they will get redirected to http://localhost/home in the same way.

Gotchas
Nothing is perfect! This is the first attempt at this, and although I know the CF On Wheels portion to be tested by quite a few people, my code has not been. As far as implementing this in your own project, there are a few things to watch out for. If you’re using any kind of “self” or “myself” variable, chances are it has the framework specific values in there. These can be updated in a prefuseaction or an onrequeststart method in your framework and set to “” in order to make things easier. If you want to test things out NOW without changing much code, you might want to change whatever variable contains “index.cfm” and change it to “/index.cfm”. Those paths really start to get hairy if you’re trying to do a little in both worlds though, so I’d recommend either going all out or none at all. You’re probably setting your XFAs as “controller.action” as well too, which may need to be refactored into “/controller/action/”. URL variables and FORM variables passed to non-Coldcourse URLs will be forwarded over to the Coldcourse URL. For forms this a VERY bad idea if you’re doing anything sensitive, and just a BAD idea if you’re not. It’ll also mess things up if you need to know what’s in the form scope and url scope. I think all frameworks covered will just squish these into a single scope though, so although the end result is the same, be sure to fix forms to go to the new URLs if you do nothing else.

What you need
Just like the routing in COW, you’ll need either a webhost that supports .htaccess files (apache), or access to IIS to install an Isapi filter. Other than that you really only need to be able to run CFCs. This hasn’t been tested on other versions besides CF7, but should work in theory on any 6.1+ style CFML processor.

Installation
Installation is a two second process if you’re on apache, but will be a little more trouble if you’re running IIS. For IIS, you’ll have to get Isapi Rewrite working and include the packaged ini file. For Apache you just drop the .htaccess file in your root dir. Other than that just place your config file, Coldcourse.cfc and coldcourse.cfm wherever you want. By default these will go in /config, /model and /, respectively, but can go anywhere if you change their paths in coldcourse.cfm. Next you can setup your framework specific settings and some courses in the config file.

Credits
To be honest, all the hard work for this came from the CF On Wheels guys, Rob Cameron & Per Djurner for making the routing system used there. This is just an adaptation of their code to work with other frameworks.

Download
You can grab it now on Riaforge at http://coldcourse.riaforge.org/.