My journey into breaking my perceptions of frameworks as cumbersome, and my experience with the Ortus Solutions ColdBox training.
This is the final part of a three part series on my experience with ColdBox training from Ortus Solutions.
- In the first part of this series I discussed my history and thoughts on frameworks in general.
- The second part gave details on my experience in attending Ortus Solutions “ColdBox, Zero to Hero” training as instructed by Gavin Pickin.
- This final part of the series acts as a follow up to changes in my impressions of ColdBox and frameworks in general.
Back in October, I participated in Ortus Solutions’ “ColdBox, Zero to Hero” training as instructed by Gavin Pickin. Since then, I’ve had some time to process the training, do some more learning, and work with ColdBox in an existing application, as well as crafting a new application from scratch using ColdBox 6.
My usual disclaimer… and this time it shouldn’t be necessary because it’s right in the title. I am not a Coldbox expert. The information I am providing here is based on my own experience, and is mostly opinion. Take it for what it’s worth.
(Re-)Learning to let go
In the late 90’s, early 2000’s, a friend of mine named Jeff was investing heavily in ASP and .net. At the time, it was the hot new development language that many developers were excited about. One day, I was curious about the work he was doing so I asked him how ASP and .net worked. He talked about how he could use ASP and .net to connect to a database and how easy it was.
“First,” he said, “you create a variable. Then you create your query. Then you create an instance of a data object that talks to the database. Then you create a variable to hold the results… then you bind the results of the query to that data object and then you can use it.” I’m paraphrasing here… I don’t actually remember the specific steps it took to pull information from a database, but I seem to remember it being a very manual and multiple-step-based process. To perform a query, you had to invoke maybe 10 lines of assignments and bindings to get the thing to work.
“Wow,” I said, “that seems like a lot of steps just to get some information from a database.” This took him by surprise, so he asked me how to accomplish this using CFML. I’ve always been a huge proponent of ColdFusion, and at the time was running an Allaire ColdFusion User Group for Southern Nevada, so I took the opportunity to preach the gospel of rapid application development.
“Well, once you have your datasource set up in the ColdFusion Administrator, you use one tag; <cfquery>, with attributes for the datasource, and the variable the results should be and put your SQL statement inside of it.”
The whole “black box” idea of how ColdFusion simply did things for you was a problem Jeff has a hard time mentally compensating for. He felt that by taking those individual steps and combining them into one statement, you lost a lot of intrinsic control over how the application does what it does. It was something I had let go of long before… I don’t care how the underpinnings of ColdFusion work in order to connect to the database, query the data, bind the results to a variable and make it available to my application… maybe it’s magic. I didn’t care about how it worked. It just cared that it did.
I’m finding myself in Jeff’s situation when it comes to Coldbox. Coldbox does a lot of things for you, and I don’t quite understand how or why it does some things the way it does. I’m finding it difficult to let go of the way I build things in order to adopt the Coldbox way to build things.
And that’s okay! It’s a learning experience. It’s something I want to be able to do.
Some pros and cons of adjusting the way Coldbox works
Coldbox (as of the time of this writing) is the most popular CFML development framework and with good reason. It’s well supported, well documented, and well established by some of the best minds in software development. The conventions and standards in place are well thought-out, they’re reasonably easy to understand, and they’re robust enough for an application to scale to an enterprise level.
Coldbox (and moreso Commandbox) are amazing tools. They do a lot of the grunt work for you when it comes to building an application. Commandbox replaces setting up a new model, view, and controller in your application, with a single command line. Need a plug in similar to the way npm works for node.js? Forgebox has you covered. Want to add unit tests to your application so that you have fewer bugs? Textbox is baked right in. Once you get into the weeds of creating a Coldbox application you can tell that it’s polished and robust.
Now… there’s a lot to get used to when it comes to learning the “Ortus way” of doing things. Ortus has their own set of CFML Best Practices and Standards. Some of these you may agree with, some of these you may not.
Here’s the thing; ultimately, if you don’t like the way Coldbox does something, you can change it. That comes with some caveats, and to start I want to ask myself a basic question:
“Why do I want to use a common (not homegrown) framework for developing an application?”
- There are multiple developers on this project and I want to lessen the learning curve for understanding how the application is built.
- I want the application to be able to scale and I think creating my own application framework may not be as robust as one that has been battle-tested.
- I want to apply conventions and standards to development.
- I want to streamline development by leveraging code that has already been tried and tested.
Changes to the convention muddy the waters.
What effect does modifying the framework have on the application? Let me give you an example. Since its inception Coldbox used the convention “handlers” for all of their controllers. This was based on the event-driven development that was standard at the time Coldbox was created and evolving. Even today, if you execute the
coldbox create app command within Commandbox, the skeleton for the application uses “handlers” as the directory for the controllers.
If calling controllers handlers bothers you, this can be changed easily! Ortus has it built into the configuration. There is a built-in place to change the
handlersLocation to whatever you want it to be.
Let’s say that you change the
handlersLocation value to “controllers” instead of “handlers.” It’s easy enough to do, but it comes with a cost. Changing this adds a “gotcha” to the training when you’re bringing in a new developer. That developer, upon cloning the repository may ask “where is the handlers directory?” Someone then needs to explain (or worse, the developer needs to discover on their own) that the handlers directory is actually the controllers directory in this application. Furthermore, when a developer is using Coldbox to create new controllers, they need to remember to add an extra attribute when executing the
coldbox create handler command in Commandbox. Failing to do so will create the new controller in a handlers directory, and then you’re forced to move it to the correct directory.
This is minor, of course… but it’s an example of how making a change to the framework has a ripple effect, and deviates from the goals of why we were using a framework in the first place! I haven’t experienced it yet, but I can’t imagine what impact a major change to Coldbox would have.
Maybe the solution is to be a purist?
Maybe that minor change; using the directory
controllers instead of
handlers is enough of a nuisance that you don’t want to bother with it. I mean, the point of using a framework is to establish conventions and make knowledge transfer easier. Speaking hyperbolically, every change to the framework results in a more and more customized version of Coldbox. That’s more customization that needs to be communicated, more things to remember about how this application is developed that’s different from a pure Coldbox application. I very much appreciate the extensibility, flexibility, and modularity of Coldbox… but my instincts are telling me if I’m going to use it, I need to be on board with the “Ortus way” of doing things.
Code obfuscation is baked in
If you’re a developer who has primarily constructed or developed against monolithic applications, the separation of “what goes where” in Coldbox (or any MVC framework for that matter) may seem confusing.
A Coldbox application has an
index.cfm. It’s empty. Nothing goes in it and you don’t want to add anything to it. URLs can be confusing to someone who is used to looking at the URL in order to determine what page is being loaded. A URL of
http://mysite.com/about in Coldbox translates to:
- Look in the handlers directory for an
- Since there’s nothing else in the URL, the default method is called
mainso look for a
main()function in the
- Unless the
main()method overrides the layout being used, the
layouts/main.cfmfile will be used as a wrapper for the display of the page.
- This is going to look for an about directory in the views folder and use the
index.cfmtherein for the main content of the page.
- It’s possible that information will be pulled from a database as well, this would be back in the
main()method and might call on files in the models folder.
Again… a monolithic application developer is going to look at that and say “oh, what fresh hell is this? Why is it all separated out and ‘hidden’ in different places?” It takes a mental shift for some developers to understand the separation of interests and why these ultimately make sense. Be prepared for that.
Get used to there being system files in your website files
coldbox create app in Commandbox will download and create a Coldbox application for you, and all of a sudden you have around 7 megabytes of files in your website folder. And you haven’t even written anything yet!
If you’re a developer who is used to keeping your website files clean and tidy, knowing the purpose of every file, this may seem unnerving. I don’t actually have a paradigm to be able to relate this to, but I can imagine it would be like having your OS system files mixed in with all your project files. There’s things you don’t want to touch (the
coldbox folder) and there’s things you may want to customize.
The point is that it’s all there, in your application, possibly including many files you don’t need or use. For example, the default application automatically installs Ortus’s testing framework Textbox in your application. If you aren’t someone who develops with unit tests or subscribes to the test-driven-development approach, these files may be unnecessary cruft taking up space in your application.
Sandblasting a soup cracker
Creating a Coldbox application establishes a robust, enterprise ready framework for highly complex and detailed applications. It scaffolds a modern approach to CFML development using up-to-date methodologies and a separation of layers.
That said, it’s not the best solution for everyone. It’s not the best solution for every application. Maybe you’ve got a tiny application that is managed by a single person and may never have another set of eyes take a look at it. Maybe you’re creating spaghetti code in order to guarantee job security. Maybe you just can’t wrap your head around the concepts and accept the conventions that Coldbox establishes. Maybe this approach, to you, is like sandblasting a soup cracker; overkill for what you need.
My final thoughts
Learning Coldbox and adopting its practices has been a positive experience. I firmly believe that there will be applications I build in the future where Coldbox is the best approach to use. Maybe not 100% of them, but I assume more often than not. It’s possible to customize it to your liking, but that comes at a cost as well. Regardless, the tools that have been provided by Ortus along with the training and documentation that is available is a very valuable tool to keep in my CFML and application development toolbox.