Another Galleon Update

Okay, so writing the report is taking a bit longer than I'd like it to take. ;)

And it's not just because I'm trying to make it more accessible by offering explanations of MVC terms like "what the heck is a controller?"

A lot of it boils down to the "cheat sheets" aspect of the report. What I know from experience is that ColdFusion frameworks in particular tend to have the same set of "features" or at least techniques for doing things. For example all these frameworks offer some method of redirecting the browser to a new page. The trick is that even though they might be doing exactly the same thing "under the hood", the syntax for it varies from one framework to the next -- and usually really only by name.

So for example in traditional Fusebox you've got the <relocate url="index.cfm"> verb - but if you transition to nuveau Fusebox (no xml) then this becomes a method call of myFusebox.relocate(url="index.cfm") in your controller CFC and moving to ColdBox changes the name again to Event.setNextEvent("eventName","query=string"). If on the other hand you transition to Mach-II, then you'll be sticking with XML and the tag becomes <redirect url="index.cfm"> (instead of relocate). Fusebox and Mach-II both offer their own custom features in those tags (Fusebox XFA - Mach-II module/event), but if all you want to do is redirect the browser you can easily translate your application back and forth between traditional XML-Fusebox and Mach-II just by changing the name of the tag from "relocate" to "redirect" and vice-versa.

And that really is the crux of it. Once you've learned a given framework (any framework), you should have a decent basic understanding of the fundamentals of how they work that will translate pretty well to most other frameworks. So much of this article is tied up in showing code samples across the different frameworks in such a fashion that you really could just read through the article and then have an understanding of how you could take what you have in one and with a few multi-file replacements reasonably have a mostly working copy of the same application in another framework. And that should be the end-of-the-line for anyone who's still indecisive about choosing a framework.

And that's even becoming more true over time. As I've been going through the documentation for these frameworks I'm finding that with Mach-II in particular several features have been added in 1.5 that, while named a little differently, provide functionality and/or syntax that is analogous of the features or syntax of either traditional Fusebox or Model-Glue. The "modules" feature added in 1.5 is a pretty decent analog to the "circuit" concept of Fusebox, which Mach-II didn't have before. And there's more planned for the future. In their Wiki right now, they have this to say about adding "broadcasts" in the upcoming Mach-II 1.6.

There has been discussions in the past that Mach-II does not allow for multiple listener notifications via a single "broadcast" command. Model-Glue's entire listener (aka controllers in Model-Glue) works on a broadcast system versus Mach-II somewhat more direct approach with the command. Any listeners that have a registered interest in a particular broadcasted message will receive the message for use. This allows you to invoke multiple listener methods by broadcasting a single message.

<snip>

..., message broadcasting lets you easily swap listeners by changing the messages it subscribes to and saves you from editing event handlers (and possibly introducing new errors). As a few people have pointed out in past discussions, these two reasons are a bigger maintenance issue than most developer realize.

That last sentence is somewhat telling also, because if you've read much of anything about cognitive science then you've probably come across an article or two about the overconfidence effect. But this talk of adding broadcasts in Mach-II just underscores this comment from the Fusebox FAQ.

Are Fusebox and Mach-II or Model-Glue competing frameworks?

Not really. They represent two different approaches to building an application. Both Mach-II and Model-Glue require an object-oriented approach to development. Fusebox does not require an object-oriented approach, but can support an OO approach if necessary.

ColdBox also requires an OO approach, although it is again a somewhat different approach than is prescribed by either of these other two. And there's my problem, the reason why it's taking me so long. The principles or fundamentals are mostly very similar, and the implementation details (code) may even be nearly identical, but the language changes between them. Each framework has to some extent invented a whole new lingo unto itself, describing the same thing (and my own is no exception).

So right now my article includes translations and code samples for the following concepts or tasks:

• Organizational Sub-applications: Circuit / Module / Controller (some analogies are better than others)
• Event (slightly different in each, but this has more linguistic similarity)
• Browser Redirection
• Nested / Chained Events (yeah, go figure)
• Application Events (onApplicationStart, onSessionEnd, etc)
• Pre / Post Events (ColdBox / Fusebox / onTap)
• Business Logic (just how it's connected in the controller)

What you might notice in this list is that there's no mention of the view... yet. I got through to that point last night and left it there. The next thing for me to tackle is comparisons of the view. I have to show for example how XFA / XE / XEH is named and/or handled in each framework.

It's really not that writing this article is difficult, it's just tedious because it's a lot of research to see how each set of framework developers named the same things a little differently. I guess it's no wonder that nobody else has (as far as I know) taken the time to do this yet. Guys who get into frameworks I imagine fall into one of two categories - either they've studied the fundamentals forever and they expect others to follow the same series of trials and errors they went through, or they just found something they like and got comfortable and they don't really spend much time thinking about the alternatives. And in either case they usually don't feel like they have the time to create something like this, even if they did have the inclination.

Now I don't think either group of guys are bad folks -- I myself have been in the latter category for quite some time in spite of the fact that my "comfort framework" is one I designed myself. And Sean Corfield I think is in the former category. I actually feel pretty lucky to consider Sean a good friend even outside of our work or the industry, and I'm pretty sure it just never really occurred to Sean to write something quite like this not because he doesn't know how (because I'm sure he already knew most of the things I've learned in the last few weeks), but rather because he simply expects other people to do their own research and for the most part fall into the second category.

Anyway, I'll wheedle Sean more later. :)

For now enjoy and I'll probably release an initial draft of this perpetual WIP (Work In Progress) over the weekend.