For the last 5 weeks, I’ve been working on a proof-of-concept application for a client using ModelGlue Gesture. This was my first “real” experience with ModelGlue. My only other exposure to ModelGlue came from watching a Breeze (as it was called then) session from Joe Rinehart where he built an entire blogging application in 7 minutes (or some equally ridiculously short amount of time). At the time, frameworks and design patterns hadn’t “clicked” with me and I struggled mightily trying to understand the concepts of what was going on under the hood. Needless to say, I didn’t pursue ModelGlue for very long due to my lack of understanding and the usual pressing project schedules.
Since that time, I’ve had the opportunity to get some formal training in MVC frameworks (specifically MachII) and have built a few applications using MachII. Along the way, the reasons for using an MVC design pattern have become much clearer and I’m now comfortable thinking about applications in the respective tiers that MVC frameworks encourage you to develop with. Having all my MVC experience in MachII up to now, I was really excited to have the chance to build an application in ModelGlue, and be able to work alongside Dan Wilson as we built it. It’s not often that you get the chance to learn a technology by working with one of the folks primarily responsible for the technology.
I know that’s probably more backstory than necessary, but I wanted to provide some context for what follows. I’ve tried to detail some of my first impressions of the ModelGlue framework as seen from the perspective of someone new to the framework.
Event-Centric Request Flow
While getting familiar with the application skeleton Dan set up at the beginning of this project, I realized that, while the exact syntax was a bit different than what I was used to, the basic event-centric concept of request flow was still the same. A block of XML code tells the framework what needs to happen when a specific event is requested. This includes various “messages” that are dispatched to all the components registered as controller objects in the XML to “do stuff” and then one or more views are called to actually “show stuff” based on what’s returned from the controllers. Obviously that’s over simplifying things a bit, but at the heart of it, it’s really that simple.
“Fire and Forget” messaging
ModelGlue takes an interesting approach to having the event flow interact with the controller layer for the “doing stuff” part of the request. Instead of the event handler directly telling controller X to run method Y to accomplish some processing needed by the event, it uses a “broadcast/listen” paradigm for communicating with controllers. In essence the event handler shouts out a message to all the registered controller objects and any controller object that has been configured to listen for that message acts on it, while the others do not. The event handler definition block doesn’t need to keep track of what controllers are listening for what events–the framework handles putting the broadcast message with the correct controller.
Be careful in how you think about this “fire and forget” messaging method. In the case where you have multiple controller objects configured to listen for the same message, they are not processed asynchronously. What actually happens is that the controllers are notified of the message in the order that they are registered in your configuration file. So, if controller B’s response to the message is dependent on controller A you could get into some issues if your objects aren’t configured correctly.
Configuration XML minimization
One of the criticisms of XML-configured frameworks is that, for large applications, managing the XML configuration becomes overly burdensome. This commonly happens when numerous event handlers all need several of the same controller and view calls–which inevitably leads to a lot of copying/pasting between event handlers. This can turn into a maintenance headache if something common to all those event handlers needs to change. ModelGlue has done a pretty impressive job of giving you options for minimizing repetitive XML with a couple of different ways to reuse blocks of XML configuration in multiple event handlers but only have to declare it in the XML config file once. Not only is that less typing on the front end, but it also gives you an easier path to making changes down the road.
Final Thoughts
I’ve heard developers over the years make statements to the effect of “once you learn one framework, it’s fairly simple to pick up another one”. Quite honestly, I never thought that could be possible. The various popular MVC frameworks for ColdFusion all approach the same problem cases a little differently. I’ve been pleasantly surprised however to find that statement to be true in my case. After just a few weeks of working on this proof-of-concept with Dan, I feel as comfortable working in ModelGlue as I do in MachII. As an independent consultant, it’s clearly in my best interest to be proficient in both (and others as I find the time) as it makes me more marketable to projects that come my way.
In the next few posts, I want to write about some of the specific features and/or ways of doing things that I’ve come to enjoy in the last few weeks of working with ModelGlue. A couple of the topics that come to mind at the moment are typed events and automatic ColdSpring bean injection into your controllers. I’ll add to this list as other ideas hit me over the next few days.