Slogging

If you've been reading my blog the past month, you've probably figured out that I've been working with ColdBox recently. I got myself a new full time job now in Boston (I was in Portland last year). The lead developer at my new job is a big fan of ColdBox (and cfscript -- different story). And I've been looking through the documentation and the code for it and I find myself frequently coming across things that seem to me like they ought to be "intuitive" or "transparent", i.e. "common sense"... but they're not.

For example: why is there a name attribute in the <Layout> tags in the ColdBox xml? I can find no reason for it. My initial thought when I saw it was that they decided to name the layouts so that when you declare Event.setLayout("mylayout") you're referencing a pointer to a specific layout file, rather than the file itself. So for example:

And then in the event handler:

The wiki says that the folder sub-node automatically includes all the views in that folder... What "automatic inclusion" is going on, I can't tell... there doesn't seem to be any. But I gathered from that description that, by declaring Event.setLayout("Console") the framework would then automatically load up all the sub-views that would be displayed in the layout file, so that they would be available when the layout file declared renderView("blah").

Not so much.

Instead, View and Folder sub-nodes allow you to find the layout (the path to the layout template as a string) via the Event.getViewLayouts() and Event.getFolderLayouts() functions which return a structure from the event instance data. That structure is created from the xml... and presumably (I'm guessing here), when you use Event.setView("console/x") or event.setView("mainHeader") the framework works back the other way, automatically setting the Layout based on the path to the view you've just set. So if the layout contains a folder sub-node of "console" and the path to the view starts with "console/" then that's the view you get -- assuming you haven't accidentally used the same folder path twice in your config xml.

Okay, that makes a bit more sense...

So why the name? I've been all up and down the documentation and google and I can find no mention of there being a reason for a name attribute in the Layout tag.

And I have to say, I honestly find it odd that ColdBox has so much support. I've seen a bunch of people posting these blogs that talk about how wonderful ColdBox is and how it's saving them time and I read the articles about what it's doing for them, and I'm thinking to myself "it's saving you time by letting you not do something you only had to do because you were using ColdBox in the first place"...

In other words, it would be like some motivational guru saying "look how much time and money I'm saving you by allowing you to download my book online and not have to buy tickets to my seminar!" ... when you didn't need the seminar in the first place. As opposed to an architecture that would save you time by allowing you to end-run around things you actually have to do regardless (i.e. "look how much time and much money you save by buying food in bulk at Sam's Club"). Everyone has to eat.

I just don't see it... It's possible there's some magic going on here that I haven't seen yet, but I think it's unlikely. I think it's more likely I'll end up feeling about ColdBox the way I ultimately ended up feeling about Fusebox 3 - a lot of work for very little gain. On the project I'm working on right now, I ended up creating a code generator, and while I loathe the idea of code generators, I was able to create it in all of about 20 minutes, thanks to the tools already available in the onTap framework. And entirely irrespective of the learning curve, if I were using the onTap framework for this project, I would already be somewhere between half-way to nearly done with it, rather than just getting started still now a few days into it. There's just that much extra work involved in using ColdBox + ColdSpring and configuring them.

I'm giving some consideration to posting another blog entry a little bit later similar to Russ Johnson's articles about porting from FuseBox to ColdBox and showing how to port from either (and possibly Mach-II also) to onTap AND showing how the use of ColdBox and ColdSpring leads to certain deficits in flexibility that end up making people leap through all kinds of hoops to stay in the game. And why it is that onTap doesn't lead to those same inflexibilities but rather, allows you to do things that no other framework I've seen will allow.