Convention over Configuration - ColdBox Series Part 5

In my next post, I promise we will get back to coding. But first, I just wanted to make a quick post about "Convention over Configuration" with the ColdBox Framework.

Last time I checked, this was unique to ColdBox, this may have changed for FuseBox though, but ColdBox does not use an XML file to define event handlers, plugins, interceptors, views or anything other than where the framework should look for these things. It is all done through conventions (or standards).

Handlers are stored in a specific place (the /handlers directory). Any CFC found in there that extends coldbox.system.eventhandler is examined for public methods, and any public methods found are automatically registered with the framework as an event handler.

The same is true for Plugins, Interceptors, Layouts and Views. Therefore, there is no need for the XML config file to define each of these items. The framework already knows where and how to find them.

Additionally, you can change the conventions if you like, by modifying the coldbox.xml file that we talked about yesterday.

So if you wanted to change the location of your handlers directory from /handlers to /myhandlers you could do it in lines 127-132 (approx) of the coldbox.xml file.


<!-- Custom Conventions : You can override the framework wide conventions of the locations of the needed objects -->
    <Conventions>
        <handlersLocation>myhandlers</handlersLocation>
        <!-- <pluginsLocation></pluginsLocation> -->
        <!-- <layoutsLocation></layoutsLocation> -->
        <!-- <viewsLocation></viewsLocation> -->
        <!-- <eventAction></eventAction>         -->
    </Conventions>    

And you could do the same for plugins, layouts, views and event actions (whatever those are) simply by uncommenting the tags and entering the path you would like.

Comments
ike's Gravatar You're gonna get a ton of comments about "implicit fusebox" in the 5.5 release. Several different methods that Fusebox supports for creating circuits without XML.
# Posted By ike | 10/7/08 8:43 PM
Jason Dean's Gravatar @ike, Like I said, I suspected that it had changed with Fusebox. I believe it will change even more with Fusebox 6. I sat in on a presentation about it at cf.Objective() but I had a hard time following since I was not familiar with the framework, so I did not want to say for certain.

I welcome any comments that point out similarities between this and the functionality of Fusebox.
# Posted By Jason Dean | 10/7/08 8:49 PM
ike's Gravatar I know some folks may see this as "poaching". It's really not intended that way. I did want to give some information for comparison, mostly because of your comment about feeling CoC was currently unique to ColdBox.

The onTap framework has always been a CoC-style framework. The latest version uses a config.cfc which is more like Application.cfc (as opposed to an XML file). And although it doesn't include declarations for directories like this, you could make those kinds of modifications if you wanted to by overriding the methods it inherits from tap.cfc. For that matter you could basically rewrite the entire framework if you had some compelling reason to simply by modifying your config.cfc to support whatever it is you need.
# Posted By ike | 10/7/08 8:52 PM
Justin Carter's Gravatar I know you're not really comparing ColdBox to the FarCry framework, but FarCry also uses Convention over Configuration heavily :) You just put your CFC's (which inherit from a particular FarCry type, depending on what you're implementing) in a certain folder within the package path, or put your webskins (views) in a certain folder within the webskin path, and the framework immediately knows how to instantiate your objects and use your views.
# Posted By Justin Carter | 10/8/08 5:56 AM
BlogCFC was created by Raymond Camden. This blog is running version 5.9.1. Contact Blog Owner