I make no secret that I like love Model-Glue. I will admit, if you do not have a decent grasp on Object-Oriented processes, Model-Glue might seem a bit over complicated, but sometimes it just saves so much time and effort.
One example of this happened yesterday. I am working on a project that uses Model-Glue. There was a requirements change for one part of the application. It wasn’t anything major. I needed to remove something that was appearing on one particular page, and move it to a different page. Now, if your application is well-architected, this will be an easy process, however, in this instance, I did not even need to move any ColdFusion code. All I had to do was move some XML blocks from one <event-handler> to another and re-initialize the application.
Here is what the original <event-handler> looked like, the snippets we are concerned about are in bold.
<event-handler name="DisplayEnd">
<broadcasts>
<message name="CheckIfLoggedIn">
<argument name="redirectToEvent" value="LoginForm"/>
</message>
<message name="NeedToGetPageManager"/>
<message name="NeedMessage">
<argument name="message" value="End"/>
</message>
<message name="NeedGraphicId">
<argument name="grahicId" value="End"/>
</message>
<message name="NeedAudioMessage">
<argument name="audioMessageType" value="ending"/>
</message>
</broadcasts>
<views>
<include name="topContent" template="display/dspMessageText.cfm"/>
<include name="bottomContent" template="display/dspMessageGraphic.cfm"/>
<span style="font-weight: bold;"><include name="audioMessage" template="display/dspAudioMsg.cfm"/>
</span>
</views>
<results>
<result do="DisplayLayout"/>
</results>
</event-handler>
What the highlighted bits of XML tell us is that when an event named ‘DisplayEnd’ is called, such as http://www.mysite.com?event=displayEnd, certain messages get broadcast, including ‘NeedAudioMessage’. When that message is broadcast, we are also passing along an argument with the name of ‘audioMessageType’ and a value of ‘ending’. (This is available inside of any Model-Glue controller by using arguments.event.getArgument(‘audioMessageType’). Lastly, it tells us that, among others, we are including a ColdFusion page named dspAudioMsg.cfm.
I will not get into the particulars of the code that exists inside of the controller, it merely checks certain conditions and then simply adds a value to the event if an audio message should be displayed.
The change was that instead of displaying this audio message on the DisplayEnd page, the client wanted it to be displayed on the GoalMet page. All I needed to do was remove the 2 highlighted XML blocks from the original <event-handler>, and move them into the new one. Since the logic that determined whether or not we needed an audio message had not changed, there was no need to change any of the ColdFusion code. The XML looked like this:
<event-handler name="GoalMet">
<broadcasts>
<message name="CheckIfLoggedIn">
<argument name="redirectToEvent" value="LoginForm"/>
</message>
<message name="NeedToGetPageManager"/>
<message name="NeedMessage">
<argument name="message" value="Congratulatory"/>
</message>
<message name="NeedGraphicId">
<argument name="grahicId" value="Congratulatory"/>
</message>
<message name="NeedAudioMessage">
<argument name="audioMessageType" value="ending"/>
</message>
</broadcasts>
<views>
<include name="topContent" template="display/dspMessageText.cfm"/>
<include name="bottomContent" template="display/dspMessageGraphic.cfm">
<value name="xeNext" value="index.cfm?event=DaisyEnd"/>
</include>
<span style="font-weight: bold;"><include name="audioMessage" template="display/dspAudioMsg.cfm"/></span>
</views>
<results>
<result do="DisplayLayout"/>
</results>
</event-handler>
<event-handler name="DisplayEnd">
<broadcasts>
<message name="CheckIfLoggedIn">
<argument name="redirectToEvent" value="LoginForm"/>
</message>
<message name="NeedToGetPageManager"/>
<message name="NeedMessage">
<argument name="message" value="End"/>
</message>
<message name="NeedGraphicId">
<argument name="grahicId" value="End"/>
</message>
</broadcasts>
<views>
<include name="topContent" template="display/dspMessageText.cfm"/>
<include name="bottomContent" template="display/dspMessageGraphic.cfm"/>
</views>
<results>
<result do="DisplayLayout"/>
</results>
</event-handler>
Now, as long as the same conditions are met, we will get an audio message in the GoalMet event rather than the DisplayEnd event, all without writing or changing one line of CF code.
