Credit Where Credit Is Due

A while back I commented that I've been working with ColdBox recently and "not seeing the magic"... but moreover, I made the comment that I'd been seeing a lot of articles where people were raving over how easy it had made their job when it had in reality done either nothing, next to nothing or in some cases less than nothing for them (i.e. busy work). Though I didn't actually explain what I meant by this comment... so here are a couple of examples:

Back in April, Matt Quackenbush posted this article where he talked about "mapped views" in ColdBox. By way of explanation, ColdBox uses these handler.cfc files where each function is an "event", so for example the url index.cfm?event=home.login executes /handlers/home.cfc->login(Event). Then within that login function, you have to set the "view" for the event, which is the name of a template in the /views directory. It looks like this:

So in Matt's description, he's talking about having some common forms that have to be built every time he creates a new site or application for someone. The login form actually is his example. And he doesn't like having to copy and paste those forms from one application to the next since they don't really change. I can appreciate where he's going with this...

He loses me however when he starts talking about how easy it was to create a RequestContextDecorator.cfc to wrap around the event, which then checks to see if the first character of the setView arguments is a / so that he can tell the framework to use the mapping... A whopping 43 lines of code later, in his own words, "That's all there is to it, folks. Yet another task made simple by the power of ColdBox!" ...

umm... Matt? 43 lines of code was easier than this?

ColdBox didn't actually make that job easier -- it made it harder. It added a learning curve where none was needed. And in the final analysis, there's no functional difference between his decorator and just using a local view template with an include -- except that the decorator will be less mechanically efficient.

Then just the other day Will Tomlinson posted on the cf-talk list a subject titled "MG is so cool!" So I had a look to see what marvelous new feature he was going on about... turns out, he was raving over the fact that Model-Glue can turn this:

Into this:

Which is then later retrieved via:

After having gone through two other methods of setting that same variable before finally settling on this.

umm... okay. I'm not seeing the magic.

Yes I understand encapsulation. That's not my point. The point here is that nobody's really benefited from the extra learning curve here, in spite of Will's enthusiasm for a central config file.

I can only imagine this is a result of endowment. I know that as a species we definitely view things differently once they've had time to "grow on us". I honestly get much the same feeling from people who rave about Eclipse. Others I know in the IT industry tend to describe it with the quirky phase "drinking the Kool-Aid", a reference to Jim Jones.

Have I done it? Probably. I am human and I'm pretty certain that means I'm endowed in a number of ways. As a matter of fact, I encourage you to let me know if you see me saying something like this that looks like it's inspired more by endowment than by the event itself. I'd be interested to know how this phenomenon affects me. :)

Anyway in both of these cases, large amounts of credit seem to be given to frameworks when any credit if deserved at all seems to belong to the ColdFusion server. And really, giving accolades like this to the framework authors imo even kind of cheapens them too. If you're going to give them accolades, give them accolades for things that actaully are spectacular like Mach-II's integration of multi-threading across several different CFML engines, ModelGlue's scaffolds (which I don't care for and so haven't used), etc.