So, I hope it's clear that even though I'm writing a series on Model-Glue, and even though I gush about it at every chance I get (it's the bee's knees, ya know), I still make a few mistakes here and there, and I'm still learning it as well.

Enayet (one of my readers) pointed out a bug in the sample application I'm using for the series. The error occurred when you clicked on the Galleries linked before logging on. You can try this now if you want. I'm leaving it broken until the next entry. Anyway, let's look at the event and I'll tell you what I did wrong.

<event-handler name="Galleries"> <broadcasts> <message name="getAuthenticated" /> <message name="getMyGalleries" /> </broadcasts> <views> <include name="body" template="dspGalleries.cfm" /> <include name="main" template="dspTemplate.cfm" /> </views> <results> <result name="notAuthenticated" do="Logon" /> </results> </event-handler>

So let me read this to you how I understood it.

  • First the message getAuthenticated
  • If I'm not logged in, getAuthenticated returns a result of notAuthenticated.
  • Immidiately run the event Logon
  • Do not do anything else.

However, an error was occurring because the view, dspGalleries.cfm, was running and not getting the data it expected. So, I posted a quick note on the Model-Glue listserv (sign up here: http://lists.topica.com/lists/modelglue). Turns out I was mistaken. Using the logic as I have above, the new event, Logon, was being appended to the current queue. In other words, the views still ran, but were lost when the next event was fired. I confirmed this by adding some simple logging.

So this didn't really seem to make sense to me now - but it's slowly sinking in. Luckily Model-Glue has a simple solution for that. You can add a redirect attribute to your result and this will cause it to run immediately. Here is the modified version.

<event-handler name="Galleries"> <broadcasts> <message name="getAuthenticated" /> <message name="getMyGalleries" /> </broadcasts> <views> <include name="body" template="dspGalleries.cfm" /> <include name="main" template="dspTemplate.cfm" /> </views> <results> <result name="notAuthenticated" do="Logon" redirect="yes" /> </results> </event-handler>

I had known about the redirect attribute before, but didn't include it in the series yet as I didn't think it was necessary. I didn't have a proper understanding of it (hope folks knew I wasn't perfect ;).

As I said - I'm leaving this bug in the sample for now. Those of you who download the application can confirm it and then try the fix above. (I added redirect="yes" to all of the events that needed to be secured, like Home.)