My brother, Andrew, is the head of the IT department for a firm that sells books and other supplies to school libraries all over the country. When he took over the position, he inherited a web site built on Java using the Struts framework. The original site had been in place for quite some time and the ownership decided it was time to refresh the site. The main issue (besides the outdated design) with the site was that it was so difficult to update. I’m not a Java developer by any stretch of the imagination, but from what I understand, even the simplest update required the site to be recompiled. The actual implementation of the site was fairly brittle as well, so new features were generally not even considered for fear of breaking something that was currently working.

Andrew had previously done some ColdFusion work with me on some of my other projects. He approached his management about contracting with me to help them replace their java web site with one built on CFML. During the initial requirements gathering and planning phases, the decision was made to use Railo as the CFML engine for the site. The site was launched a few months after Railo released their first open source version which appealed to them as they have several systems within the company that are open source. Cost was not a major concern (Railo being free vs the cost of a standard license of Adobe ColdFusion) but it was a consideration as this project did have a fixed budget. When we started the project, Adobe ColdFusion 8 was the most current release. Budgetary constraints probably a few more factors I wasn’t privy to led to the decision to use Railo as the CFML engine for the site.

Our experience developing with Railo was very positive. We built the site using Mach-II, Transfer, ColdSpring using a PostgreSQL database backend. We had one little issue with Mach-II when we plugged in the Mach-II Dashboard module into our main config. Peter Farrell and I traced it down and found that it was due to a difference in how Railo parsed XML vs how Adobe ColdFusion did. I worked with the folks at Railo and they got the problem sorted out in one of the next releases.

The site went live the first of August, 2009. Between January 1 and August 1 of 2010, the site experienced a 562% increase in revenue generated when compared to the same time period of 2009 (the YTD time frame leading up to the new site going live). They’ve also seen a dramatic increase in the amount of traffic to the site since the new version went live (although I don’t have exact percentages at my fingertips to share). Just as importantly, in the months sice the new site went live, they have been able to add dozens of new features to the site–both publicly-available features as well as features for administrators and sales people that just would have been too difficult to try to weave into the previous java struts based application.

Finally, while this “success story” has Railo as one of its key components, the bigger issue in my mind is the fact that a formerly java-centric shop has converted to using CFML successfully to run their business and provide a better experience for their customers and employees.

Disclaimer: I’m not on either side of the Railo/OpenBD/Adobe CF argument. I’ve not had a client since that project that’s given me the option to use Railo so all of my work since then has been in Adobe CF but I certainly wouldn’t dismiss Railo straight away if there were an option to use it on a future project. The intent behind this blog post is simply to provide one real-world example of Railo being an entry point into CFML development, not to take either side of the Twitter discussions that have been going on today.

**Update: Corrected the incorrect timeline of when Adobe ColdFusion 8 came out and removed some inaccurate statements about speed of Railo vs the Adobe CF version out at the time (which was mistakenly stated to be MX7). Thank you Adam for pointing out the error.

The latest example came this week as we were moving more heavily into coding from the planning stages we’d been in for the most part up to now when I had an occasion to use the decorator feature built into Transfer.

If you’ve done any object-oriented development you’re familiar with the concept of building methods inside your objects to contain calculations or logic specific to that particular object. That’s easy enough to do when you are writing your own bean objects, but becomes somewhat of a problem when your bean objects are auto generated by Transfer. This is the exact situation that decorators are designed to solve. The decorator pattern “allows new/additional behaviour to be added to an existing class dynamically” (Wikipedia).

<object name="Product" table="products" 
    decorator="components.decorators.ProductDecorator">
    <id name="productID" type="numeric" generate="true" />
    <!-- more properties -->
</object>

Using the code above, we can create a ProductDecorator.cfc in the /components/decorators folder and put any custom properties and methods that we need for the Product bean there. The really sweet part is that, when Transfer instantiates a Product object, it automatically merges any properties and methods that you create in the ProductDecorator into the generated object. So, you as the developer don’t have to do anything extra in order to access your custom methods than you would if you were accessing the methods generated by Transfer. Simply get your object as normal (via the new(), read(), getByProperty() methods etc) and the resulting object returned to you will have your methods and properties included as well.

Simple, elegant, and really slick.