One of the interesting features of the CFWheels framework is the fact that the core application architecture leverages <cfinclude /> tags. I say interesting because in an environment that is essentially java under the hood, most frameworks use inheritance. Such is the case with FW/1 (“Framework One”), the awesomely simple to use framework from Sean Corield.
FW/1 implementation of Application.cfc
<cfcomponent extends="org.corfield.framework"> </cfcomponent>
CFWheels implementation of Application.cfc
<cfcomponent output="false"> <cfinclude template="wheels/functions.cfm"> </cfcomponent>
In many ways, how it is wired in doesnt really matter… and <cfinclude /> is lighting fast, much faster than inheritance. The challenging part becomes when you want to override (or extend) a method in the core application framework – you can’t just create the method and use super.method() as needed. Instead, wheels creates a way for you to piggyback onto the application events, but at that point you are at the mercy of the framework and whatever code it already ran – there is no obvious way to orchestrate the firing order. your custom code comes last, done deal.
But of course where there is a will, there is a way. while it would be a big no-no to hack the framework code itself (in the wheels directory) the answer is quite simple. simply rename your root Application.cfc file (coded above) and name it “Wheels-Application-Proxy.cfc” Then, just create the following Application.cfc in your root directory
<cfcomponent extends="Wheels-Application-Proxy"> </cfcomponent>
Now if you want to rewrite the OnRequestEnd event (say to modify that ugly debug information wheels gives you, or perhaps tweek it a bit) you are ready to go. In such a case you may want to be careful… if you aren’t going to call super.OnRequestEnd() at some point in your method, you may want to have a peak in the framework code and see what its doing and be sure you dont cut out any fundamental framework code… but that’s easy enough to do with a copy-and-paste