Orange is my favorite color

In my quest to figure out Model-glue and convert my application, I’ve been referring to a lot of community blog posts. One of the most helpful has been Doug Boude’s Model-Glue Event Lifecycle in Layman’s Terms post. Over the past two weeks I’ve learned a few subtleties to the lifecycle that I want to share:

addResult() executes the result immediately

My original understanding of the lifecycle from Doug’s post was: broadcasts, results, views, in that order. This is true in the general case but there are some finer details.

Let’s look at this event-handler:
<event-handler name="pay.do">
<broadcasts>
<message name="verifyPaymentOnline" />
<message name="processPayment" />
</broadcasts>
<results>
<result name="paymentOffline" do="pay.offline" redirect="true" />
<result name="doFail" do="pay.form" />
<result name="doSuccess" do="pay.ok" />
</results>
</event-handler>

verifyPaymentOnline checks to see if our payment service is currently enabled. I use this to disable payments during maintenance windows without taking down the entire site. Since the lifecycle is broadcasts-results-views, how would I stop processPayment from also running?

That’s my first finding: If you add a result to the event object via addResult(“resultName”), Model-Glue will immediately look for a named result that matches and execute it on the spot. If you have redirect=”true” then it will abort the current request via CFLOCATION and go to the new event.

So that’s how you stop processPayment from running – let Model-Glue handle the work. :)

Using <results> Like Includes

I’ve been working to build a series of stacked views to generate my UI from the piece of the page I’m working with “out” towards the page wrapper. Here’s two event-handlers I was trying to use:

<event-handler name="pay.form">
<broadcasts>
[generates a drawForm result]
<message name="needPayFormDetails" />
</broadcasts>
<results>
<result name="drawForm" do="pay.form.billingaddress" />
<result do="view.content-ma" />
</results>
<views>
<include name="main" template="payment/dsp.payform.cfm" />
</views>
</event-handler>
<event-handler name="pay.form.billingaddress">
<views>
[draws a snippet of form tags I want to include above]
<include name="memForm" template="payment/dsp.billingform.cfm" />
</views>
</event-handler>

My thought was that the <results> would run before the <views> and so they would be available in the viewCollection(). I wanted to do this so I could define this piece of the form once and then reuse it in various places. But my memForm view kept coming up empty. What was going on?

Sean helped me debug the steps of the lifecycle:

  1. Look at the current event-handler and queue the <views>
  2. Broadcasts execute, generate named results subject to execution as described above
  3. Execute any events from the results and append their views onto the end of the queue
  4. When finished, loop over the view queue and render each one in order
  5. Return to user the output of the final view

Note this is not a technical review of what happens, I haven’t cracked the MG core open.

So the catch is that views are queued before results are executed but rendered after they finish. Dan Wilson gave me a great piece of advice in response to my question:

Just remember, there are two kinds of applications, Perfect and Finished

In my quest to only define the memForm view a single time in the model-glue.xml, I was missing the forest from the trees: the XML is a configuration file. It’s perfectly OK to duplicate a couple lines of XML there. What we’re trying to avoid is duplicating code.

So here’s the event-handler now, with my Don’t-Repeat-Yourself reflex subdued:

<event-handler name="pay.form">
<broadcasts>
<message name="needPayFormDetails" />
</broadcasts>
<results>
<result do="view.content-ma" />
</results>
<views>
<include name="memForm" template="payment/dsp.billingform.cfm" />
<include name="main" template="payment/dsp.payform.cfm" />
</views>
</event-handler>

Now, of course, the memForm view is available in main. When I need that memForm widget again, I will just include the view template a second (or third…) time.

Hope that helps someone else jump start with Model-Glue a little easier!

1 Comment

  1. Doug Boude said:

    on January 18, 2008 at 9:12 pm

    Brian, I think this is some outstanding and very relevant information that is a good complement to the basic you referred to on my blog. I encourage you to keep sharing what you learn as you go along…every little bit helps when someone is taking their Model Glue/OO journey.

{ RSS feed for comments on this post}