How To Use Event Generation

So at this point, you have learned how to create a Model-Glue application and how to start wiring events, listeners, controlling the view logic and communicate to the model. This process can be very repetitive and tedious having to add entries into the ModelGlue.xml file and create the proper ColdFusion components (CFCs) and CFML view templates. A solid programming architecture (or design pattern) requires us to make these steps. We could add all these functions into one or two pages but it would not scale very well. We need to abstract these operations out.

However, there are always costs to any design pattern. In this case, there is a fair degree of setup to handle any single event. We would prefer to eliminate as much of this tedious setup as possible and yet keep flexibility. One of the best features in Model-Glue 3 is provided to do precisely that. It's called "Event Generation". By calling undefined events in the URL, we can tell Model-Glue to do all the needed setup and free us from having to modify the ModelGlue.xml file directly or create the files to handle the event. All of this is done by naming convention and makes the setup process very easy. It is also important to note that it doesn't overdo the work we are asking from it. It simply creates the stuff we would normally need to do manually within the Model-Glue MVC framework.

How to start Event Generation

First we need to make sure we are in development mode. In the Coldspring.xml file, verify that the "reload" property is set to "true". Like so:

<property name="reload"><value>true</value></property>

Next, we need to turn Event Generation on. In the Coldspring.xml file look for a property called "generationEnabled" and switch its value to "true". Again like so:

<property name="generationEnabled"><value>true</value></property>

VERY IMPORTANT NOTE: Make certain to turn Event Generation and development mode off when publishing your application to the outside world. Leaving event generation on for a publicly accessible site would create a high security risk. This feature is only meant to be a tool for your internal development work.

OK, so we are in development mode with event generation turned on, time to have some fun. In the browser, we can now treat the URL almost like a command line. Our calls to non-existent events will not call the missing event handler but instead will get intercepted by Model-Glue's event generator. With event generation turned on, Model-Glue will generate the needed items to handle the event. All that stuff you just learn to do manually.

So let's call a couple of events that currently do not exist in our application.

/index.cfm?event=news.view

/index.cfm?event=news.search

Each time you should see a default view page that Model-Glue created for the event. It should something like this:

I'm a generated view for the "news.view" event.

To edit me, open ../../views/news/view.cfm.

If we navigate to the "views" folder for our application, we should see a new folder called "news" and two pages contained therein called view.cfm and search.cfm. But as you have learned so far, creating the view pages is not enough, the event had to wired up in ModelGlue.xml to get us to actually see these pages. Let's open the ModelGlue.xml file. You should see two new event handler entries with their respective views included:

<event-handler name="news.view">
  <broadcasts>
    <message name="news.view" />
  </broadcasts>
  <results />
  <views>
    <include name="body" template="news/view.cfm" />
  </views>
</event-handler>

<event-handler name="news.search">
  <broadcasts>
    <message name="news.search" />
  </broadcasts>
  <results />
  <views>
    <include name="body" template="news/search.cfm" />
  </views>
</event-handler>

We can see that the events are being handled and a message is being broadcast. That would mean we need a controller to listen for those messages. The Event Generation took care of that as well. Near the top of the ModelGlue.xml file we should see a new entry for a "News" controller within the list of controllers currently defined for this application. The news controller also has a couple of listeners, one for "view" and the other for "search":

<controller id="NewsController" type="mg3example.controller.NewsController">
  <message-listener function="view" message="news.view" />
  <message-listener function="search" message="news.search" />
</controller>

Since the first part of our event call was called "news", Model-Glue used that same naming convention to generate a "News" Controller and its CFC. If we open that NewsController.cfc file which is now in our "controllers" folder, we have a good skeleton CFC to work from:

<cfcomponent output="false" extends="ModelGlue.gesture.controller.Controller">

  <cffunction name="init" access="public" output="false" hint="Constructor">
    <cfreturn this />
  </cffunction>
  
  <cffunction name="view" output="false">
    <cfargument name="event" />
    <!---
    Put "behind the scenes" query, form validation, and model interaction code here.
    Use event.getValue("name") to get variables from the FORM and URL scopes.
    --->
  </cffunction>

  <cffunction name="search" output="false">
    <cfargument name="event" />
    <!---
      Put "behind the scenes" query, form validation, and model interaction code here.
      Use event.getValue("name") to get variables from the FORM and URL scopes.
    --->
  </cffunction>
</cfcomponent>

The event generator did all the setup work for us. With a very simple URL call, we avoided all the tedious setup work. We didn't have to touch the ModelGlue.xml and we now have event handlers, a controller and listeners built and wired up.