Introducing Surfing Stats

I have finished coding my application for my hands-on session at 360:Flex Atlanta. The goal of the session is to walk attendees through building a simple application. You may download the source code for Surfing Stats using the download link.

The Flex framework is very powerful and offers lots of powerful functionality. I had trouble limiting myself in scope. I only have 4 hours to teach so I want to make sure I leave the students with a functional and instructive application.

Without futher ado, I want to introduce Surfing Stats. This application consumes XML data from my BlogCFC installation at and displays the data in table, bar chart and pie chart format. Each dataset is represented as a tab. Clicking on the tab enables the relevant display options.

In the next few weeks I'll wrap up the course materials of the session. I'll probably blog some to finalize my thinking on the session. I do not expect to trim any base functionality of Surfing Stats, though there are several fancy add-ons in the current version we will cover should the class progress at a quick pace.

As a reminder, 360:Flex Atlanta will be held February 25-27, 2008 in Atlanta, GA. If you would like to learn how to build an XML fed charting application with the Flex Platform, attend my hands on session.

Download Download

My Tutorials are now on is a great resource for developer related content. As a clever way to share interesting links, anyone can submit content to be voted up or down. I've recently added all my tutorials to date on

Feel free to vote them up or down as you see fit. Dan Wilson's ( Tutorials On DZone

Nice post on The Model-Glue Event Lifecycle

ModelGlue Users and especially my MG series users, have a read on Doug Boude's Blog about the The Model-Glue Event Lifecycle.

Doug has a lot of other interesting Model Glue related content as well. Here are three of my favourites:

Model Glue Views Demystified

Basic Event Security in ModelGlue

Dynamic Data Stores a ModelGlue Case Study

So you want to use Transfer ORM in your ModelGlue:Unity application (Part 1)

Previously, we connected Transfer ORM into our ContactOMatic application. Now, we will use it to get some things done! The completed files for this exercise are included at the bottom of the post, just click on the 'Download' link.

Using Transfer with MG:U is quite different than hand coding all the data access instructions so I separated out the new Transfer enabled code from the old hand coded bits to help compare similar operations between the two styles. This means the ContactOMatic is not an example of Architectural Purity! Shock! Horror! Gasp!

To make the separation, I added another ModelGlue configuration file, named ContactAction.xml, to the main ModelGlue.xml file through the use of the include tag as follows:


Download Download

Installing Transfer in ModelGlue:Unity

Today we will install the Transfer ORM inside our Contact-O-Matic application. To complete this tutorial, you should have the Contact-O-Matic installed and running. If you have not completed this step, please create the database described at the bottom of Series 6 and install the files at Series 10 download link. Test the application by manually adding several ContactTypes to the ContactType table in your database (I chose Co-Worker, Enemy, Friend). Then use the Contact Form in the ContactOMatic application to enter a few contacts.


So you want more tutorials?

I am going to continue the 'So You Wanna Create a Model Glue Application series. (Thanks Lola ;) For those just tuning in, the Contact-O-Matic is a simple example of a mini-application using ModelGlue and ColdSpring. The tutorials on the Contact-O-Matic go through the code line by line showing how to perform such tasks as:

  1. Set up the frameworks
  2. Build a View
  3. Place your CSS and JS files
  4. Create a form
  5. Validate a submitted form and persist the data
  6. Return success/error messages
  7. Resolve CFC dependancies with ColdSpring
  8. Create Instance Objects with factories
  9. Refactor, as needed

The Contact-O-Matic is not an example of a Best Practices- Enterprise application. This is due to the simple nature of the program. We simply have a list of contacts, a mechanism to add and edit contacts, and a way to remove contacts. As Object Models grow complex in complex applications, it is important to note that there is no perfect Object Model, only the least annoying set of tradeoffs. I want the code in the Contact-O-Matic to remain simple, and so it shall.

Our next move is to integrate Transfer ORM into our application. The next set of posts will cover installation and testing of the Transfer ORM Framework, the inclusion of another 'Contact-O-Feature' in our application as well as some Architectural Techniques.

So you want to create a ModelGlue:Unity application? ( Part 10 )

Sean Corfield pointed out that using ColdSpring to make instance (throwaway) components is quite a heavyweight approach for a simple form bean. He is, of course, correct. Our ContactFormBean is currently created by ColdSpring. In this series, we will add a factory object that will make our instance beans for us. The factory itself will be configured through ColdSpring as well as the configuration for our objects.

This is a very simple factory. It has three methods, GetConfig, SetConfig and getBean. In turn:

  1. getConfig() returns a struct with keys = objectnames, and values = paths
  2. setConfig() provides an interface for ColdSpring to set the configuration struct.
  3. getBean() gets the path for a specific object from the configuration struct and returns a created object.
Note: the getBean() method runs an init() method on the newly created object. This is considered a convention in CFCs.
view plain print about
3    <!---     Author: dwilson Date: 3/14/2007 Usage: I return an instance object     --->
4    <cffunction name="getBean" output="false" access="public" returntype="any" hint="I return an instance object">
5        <cfargument name="ObjectName" type="string" required="true"/>
6        <cftry>
8             <cfreturn createObject( "component", structFind(getConfig(), arguments.ObjectName ) ).init() />
10             <cfcatch type="any">
12                <cfthrow message="BAD_OBJECT_CONFIG_IN_INSTANCEFACTORY" detail="You provided [ #arguments.ObjectName # ] and I can't create it. Go check the config." />
14            </cfcatch>
16        </cftry>
18    </cffunction>
20    <!--- Usage: GetConfig / SetConfig methods for Config value --->
21    <cffunction name="
getConfig" access="public" output="false" returntype="any">
22        <cfreturn variables.instance.Config />
23    </cffunction>
25    <cffunction name="
setConfig" access="public" output="false" returntype="void">
26        <cfargument name="
Config" type="any" required="true" />
27        <cfset variables.instance.Config = arguments.Config />

28    </cffunction>

To use this instance factory, add the following ColdSpring xml snippet to the ColdSpring.xml file.

view plain print about
1<bean id="instanceFactory" class="ContactManagerMG.model.InstanceFactory">
2     <property name="Config">
3     <map>
4     <entry key="ContactFormBean"><value>ContactManagerMG.model.ContactFormBean</value></entry>
5     </map>
6    </property>

Now remove the original ContactFormBean configuration.

Next, open the Controller.cfc file and change each instance (getContactForm, handleContactForm and removeContact) of getModelGlue().getBean("ContactFormBean") to getModelGlue().getBean("InstanceFactory").getBean("ContactFormBean") .

Finally, reinitialize your application and click on the ContactForm tab. You should see your form as before.

A factory might seem like overkill right now, since this is a simple application. However, Factory objects are a good pattern to learn. Our motivation for the factory in this case was to reduce the amount of unnecessary processing incurred by using ColdSpring to make a simple form bean. We could however, expand our factory to take additional parameters and create all sorts of dynamic objects for us.

In a later series, we'll do just that.

Download Download

So you want to create a ModelGlue:Unity application? ( Part 9 )

In our last segment we built the functionality to store our contacts to the database. Now we need a way to edit the information because after all, friends can become enemies, and enemies can become co-workers. We have a good structure in place and these changes will be simple.


Download Download

So you want to create a ModelGlue:Unity application? ( Part 8 )

In our last series, we moved the ContactTypes from a ColdSpring configured struct, to a database table. This set the stage to move the rest of our persisted data to the database.

As we begin this series our main goal is to have our contacts and lists of contacts stored in our database. Originally, we used in-memory storage as it allowed us a functional application without a database.

In this series, we will introduce two new files, ContactDAO and ContactGW (GW = Gateway). Both components will reside in the *ContactManagerMG.model directory. The ContactDAO will handle the DB work for Creating, Reading, Updating and Deleting our Contacts. Incidentally, this group of functionality is commonly referred to as C.R.U.D. The ContactGW will handle the database work for pulling queries of Contacts. We'll have a function called getContactQuery().

Here is a look at the ContactDAO. Note: we reference the AppConfig inside our ContactDAO so we can use the Application Configuration defined in ColdSpring. While we mostly care about the DSN for now, the flexibility to pull other configuration parameters will come in handy later.

view plain print about
3    <cffunction name="Create" access="public" output="false">
4        <cfargument name="Contact" required="yes" />
5        <cfset var CreateQuery = "" />
7            <cfquery name="CreateQuery" datasource="#getAppConfig().getConfig().dsn#">
9                INSERT INTO Contact
10                ( ContactName, ContactTypeID )
11                VALUES
12                (
13                    <cfqueryparam value="#arguments.Contact.getContactName()#" cfsqltype="cf_sql_varchar">,
14                    <cfqueryparam value="#val( arguments.Contact.getContactTypeID() )#" cfsqltype="cf_sql_numeric">                    
15                )            
17            </cfquery>
19    </cffunction>
21    <cffunction name="Read" access="public" output="false">
22        <cfargument name="Contact" required="yes" />
23        <cfset var ReadQuery = "" />
25        <cfquery name="ReadQuery" datasource="#getAppConfig().getConfig().dsn#">
27            SELECT ContactID, ContactName, ContactTypeID
28            FROM Contact
29            WHERE ContactID = <cfqueryparam value="#val( arguments.Contact.getContactID() )#" cfsqltype="cf_sql_numeric">
31        </cfquery>
33        <cfset arguments.Contact.setContactID( ReadQuery.ContactID ) />
34        <cfset arguments.Contact.setContactName( ReadQuery.ContactName ) />
35        <cfset arguments.Contact.setContactTypeID( ReadQuery.ContactTypeID ) />
37    </cffunction>
39    <cffunction name="Update" access="public" output="false">
40        <cfargument name="Contact" required="yes" />
41        <cfset var UpdateQuery = "" />
43        <cfquery name="UpdateQuery" datasource="#getAppConfig().getConfig().dsn#">
45            UPDATE Contact
46                SET
47                    ContactName = <cfqueryparam value="#arguments.Contact.getContactName()#" cfsqltype="cf_sql_varchar">,
48                    ContactTypeID = <cfqueryparam value="#arguments.Contact.getContactTypeID()#" cfsqltype="cf_sql_numeric">
49            WHERE ContactID = <cfqueryparam value="#arguments.Contact.getContactID()#" cfsqltype="cf_sql_numeric">
51        </cfquery>        
53    </cffunction>
55    <cffunction name="Delete" access="public" output="false">
56        <cfargument name="Contact" required="yes" />
57        <cfset var DeleteQuery = "" />
59        <cfquery name="DeleteQuery" datasource="#getAppConfig().getConfig().dsn#">
61            DELETE FROM Contact
62            WHERE contactID = <cfqueryparam value="#arguments.Contact.getContactID()#" cfsqltype="cf_sql_numeric">
64        </cfquery>
66    </cffunction>
69    <cffunction name="getAppConfig" access="public" output="false" returntype="any">
70        <cfreturn variables.instance.AppConfig />
71    </cffunction>
73    <cffunction name="setAppConfig" access="public" output="false" returntype="void">
74        <cfargument name="AppConfig" type="any" required="true" />
75        <cfset variables.instance.AppConfig = arguments.AppConfig />
76    </cffunction>

Here is a look at the ContactGW. Once again we reference the AppConfig.

view plain print about
4 <cffunction name="getContactQuery" access="public" output="false" returntype="query">
5 <cfset var ContactQuery = "" />
7 <cfquery name="ContactQuery" datasource="#getAppConfig().getConfig().dsn#">
8 SELECT C.ContactID, c.ContactName, c.ContactTypeID, ct.ContactType
9 FROM Contact c LEFT JOIN ContactType ct ON c.ContactTypeID = ct.ContactTypeID
10 </cfquery>
12 <cfreturn ContactQuery />
14 </cffunction>
16 <cffunction name="getAppConfig" access="public" output="false" returntype="any">
17 <cfreturn variables.instance.AppConfig />
18 </cffunction>
20 <cffunction name="setAppConfig" access="public" output="false" returntype="void">
21 <cfargument name="AppConfig" type="any" required="true" />
22 <cfset variables.instance.AppConfig = arguments.AppConfig />
23 </cffunction>

Now we add each component to our ColdSpring configuration. Each component takes one Property, the AppConfig object. Add both beans as new property tags to the existing ContactService bean definition. We will also remove the references to the old Array based ContactList. Let's do a little housecleaning on our ColdSpring file shall we?

Add the definitions for the components

view plain print about
1<bean id="ContactDAO" class="ContactManagerMG.model.ContactDAO">
2 <property name="AppConfig"><ref bean="AppConfig" /></property>
3 </bean>
5 <bean id="ContactGW" class="ContactManagerMG.model.ContactGW">
6 <property name="AppConfig"><ref bean="AppConfig" /></property>
7 </bean>

Remove the following lines from the existing ContactService definition:

view plain print about
1<property name="ContactList">
2    <list></list>

Add in the property tags for our new components.

view plain print about
1<bean id="ContactService" class="ContactManagerMG.model.ContactService">
2        <property name="ContactTypeGW"><ref bean="ContactTypeGW" /></property>
3        <property name="ContactDAO"><ref bean="ContactDAO" /></property>
4        <property name="ContactGW"><ref bean="ContactGW" /></property>        
5    </bean>

Once complete, ColdSpring will run setContactDAO() and setContactGW() on the ContactService component and stuff the proper object in our service for us. We need to change the service a little now to account for this new functionality. Open up the ContactService and make the following changes:

Remove the getContactList() and setContactList() functions. These functions used to manage our Array based contact list from ColdSpring, with our new Database driven Contact-O-Matic, we won't need them any longer.


view plain print about
1<cffunction name="setContactList" access="public" returntype="void" output="false">
2        <cfargument name="ContactList" type="array" required="true" />
3        <cfset variables.instance.ContactList = arguments.ContactList />
4    </cffunction>
5    <cffunction name="getContactList" access="public" returntype="array" output="false">
6        <cfreturn variables.instance.ContactList />
7    </cffunction>

Now add in the get/set functions for each component. While we are in here, also add in a new function to get our ContactList from our new ContactGW. The function on the ContactGW is called getContactQuery(). When complete, you'll have removed two functions and added five. Examples of the new functions are below:

view plain print about
1<cffunction name="getContactList" output="false" access="public" returntype="query" hint="I return a list of contacts">
2        <cfreturn getContactGW().getContactQuery() />
3    </cffunction>
5    <cffunction name="getContactDAO" access="public" output="false" returntype="any">
6        <cfreturn variables.instance.ContactDAO />
7    </cffunction>
9    <cffunction name="setContactDAO" access="public" output="false" returntype="void">
10        <cfargument name="ContactDAO" type="any" required="true" />
11        <cfset variables.instance.ContactDAO = arguments.ContactDAO />
12    </cffunction>
14    <cffunction name="getContactGW" access="public" output="false" returntype="any">
15        <cfreturn variables.instance.ContactGW />
16    </cffunction>
18    <cffunction name="setContactGW" access="public" output="false" returntype="void">
19        <cfargument name="ContactGW" type="any" required="true" />
20        <cfset variables.instance.ContactGW = arguments.ContactGW />
21    </cffunction>

Now our service has references to the ContactDAO and the ContactGW, in turn both the ContactDAO and ContactGW have references to our AppConfig. All the plumbing for the database interaction is complete.

Previously, we stored the ContactType in our ContactFormBean. This was acceptable when referential integrity was not on our list. Now, we need to modify the Contact Form and the Contact Form Bean to refer to the ContactTypeID instead of simply the ContactType. In the form itself, all we need to do is switch the reference. Inside the Bean there is a tiny bit more to it. We will start with the form.

The select tag block should be changed as follows

view plain print about
1Type: <select name="ContactTypeID">
2    <cfloop query="ContactTypes">
3 <option value="#ContactTypeID#" <cfif ContactFormBean.getContactTypeID() IS ContactTypeID>selected</cfif>>#ContactTypes.ContactType#</option>
4 </cfloop>
5    </select>

Now open the ContactFormBean and change all the ContactType references to ContactTypeID. A find and replace would be nice here. A simply Find and Replace should make 11 changes...

There are two references in the Init() function, one in the validate function and also a get/set block at the bottom. Each of these should be changed to ContactTypeID.

The completed ContactFormBean is here:

view plain print about
2    displayname="ContactFormBean"
3    output="false"
4    hint="A bean which models the ContactFormBean form.">

7    <!---
9    --->

10    <cfset variables.instance = StructNew() />
12    <!---
14    --->

15    <cffunction name="init" access="public" returntype="ContactManagerMG.model.ContactFormBean" output="false">
16        <cfargument name="ContactID" type="string" required="false" default="" />
17        <cfargument name="ContactName" type="string" required="false" default="" />
18        <cfargument name="ContactTypeID" type="string" required="false" default="" />
20        <!--- run setters --->
21        <cfset setContactID(arguments.ContactID) />
22        <cfset setContactName(arguments.ContactName) />
23        <cfset setContactTypeID(arguments.ContactTypeID) />
25        <cfreturn this />
26     </cffunction>
28    <!---
30    --->
31    <cffunction name="getMemento" access="public"returntype="struct" output="false" >
32        <cfreturn variables.instance />
33    </cffunction>
35    <cffunction name="validate" access="public" returntype="boolean" output="false">
36        <cfargument name="Errors" type="struct" required="true" />
37        <cfset tempErrors = structNew() />
39        <cfif NOT len( trim( getContactName() ) ) >
40            <cfset tempErrors['ContactName'] = "Please enter a name for your contact" />
41        </cfif>
42        <cfif NOT len( trim( getContactTypeID() ) )>
43            <cfset tempErrors['ContactTypeID'] = "Please enter a contact type for your contact" />
44        </cfif>        
46        <cfif structCount( tempErrors ) >
47            <cfset structAppend( arguments.Errors, tempErrors ) />
48            <cfreturn false />
49        <cfelse>
50            <cfreturn true />        
51        </cfif>
53    </cffunction>
55    <!---
57    --->

58    <cffunction name="setContactID" access="public" returntype="void" output="false">
59        <cfargument name="ContactID" type="string" required="true" />
60        <cfset variables.instance.ContactID = arguments.ContactID />
61    </cffunction>
62    <cffunction name="getContactID" access="public" returntype="string" output="false">
63        <cfreturn variables.instance.ContactID />
64    </cffunction>
66    <cffunction name="setContactName" access="public" returntype="void" output="false">
67        <cfargument name="ContactName" type="string" required="true" />
68        <cfset variables.instance.ContactName = arguments.ContactName />
69    </cffunction>
70    <cffunction name="getContactName" access="public" returntype="string" output="false">
71        <cfreturn variables.instance.ContactName />
72    </cffunction>
74    <cffunction name="setContactTypeID" access="public" returntype="void" output="false">
75        <cfargument name="ContactTypeID" type="string" required="true" />
76        <cfset variables.instance.ContactTypeID = arguments.ContactTypeID />
77    </cffunction>
78    <cffunction name="getContactTypeID" access="public" returntype="string" output="false">
79        <cfreturn variables.instance.ContactTypeID />
80    </cffunction>

Finally, we need to change how the contacts are saved. In the beginning, we simply appended the ContactFormBean object into an Array of ContactFormBean object and iterated over the array for our ContactList. Now, we need to change the controller function to call the service. We will let the service decide how to handle the save. In the controller located at *ContactManagerMG.controller modify the isvalid branch to call a ContactService method called saveContact()

view plain print about
1<cfif isValid >
2         <cfset ContactService.saveContact( ContactFormBean ) />
3         <cfset arguments.event.addResult("Success") />
4     <cfelse>
5         <cfset arguments.event.setValue("ErrorStruct", ErrorStruct) />
6          <cfset arguments.event.addResult("Failure") />
7     </cfif>

Now add the saveContact() function into your ContactService. This function will accept a Contact object, being our ContactFormBean, and check to see if the ContactID has been assigned. If so, we will update the record, if not, we will create the record. Your saveContact() function should look like this:

view plain print about
1<cffunction name="saveContact" access="public" returntype="void" output="false">
2        <cfargument name="Contact" type="any" required="true"/>
4        <cfif val( Contact.getContactID() ) GT 0 ><!--- Update --->
5            <cfset getContactDAO().update( arguments.Contact ) />
6        <cfelse><!--- Insert --->
7            <cfset getContactDAO().create( arguments.Contact ) />
8        </cfif>
10 </cffunction>

After changing the save contact flow, we have closed the circle for adding / updating the individual contacts. Remaining, is the ContactList page.

We will now be returning a query and ourcontact list page used to operate on an array. Thus, we must adjust.

Change your dspContactList.cfm page to use a query. Your completed list page will look as follows:

view plain print about
1<cfset myself = viewstate.getValue("myself") />
2<cfset ContactList = viewstate.getValue("ContactList") />
5    <cfif ContactList.recordcount IS 0 >
6        -No Saved Contacts-<br />
7    <cfelse>
8        <table>
9            <tr>
10                <th>Name</th>
11                <th>Type</th>
12            </tr>    
13        <cfloop query="ContactList">
14            <tr>
15                <td>#ContactName#</td>
16                <td>#ContactType#</td>
17            </tr>
18        </cfloop>
19        </table>    
20    </cfif>

Reset your application and run your new Database Powered Contact-O-Matic. If you've followed all the steps, (and I haven't left any out) you now have a proper application.

We touched a good chunk of the application and I trust this has been a good refresher into the inner workings of our Contact-O-Matic. In our next series, we will include the mechanics to delete contacts from the database.

Download Download

So you want to create a ModelGlue:Unity application? ( Part 7 )

We are going to break this up into phases starting with the contact types. At the end of this series, our contact types will come from the database and we will have an even greater appreciation for ModelGlue and ColdSpring.

The last article gave the spec for your database tables, Contact and ContactType. Add in 3 dummy records to the ContactType table. I used Friend, Enemy and Co-worker.

Set up your datasource in the ColdFusion administrator. I used the data source name of 'ContactOMatic'. Test the connection and move on.

Now we will need this datasource name inside of our cfqueries. Can anyone guess where we will keep the DSN? Thats right, in ColdSpring. Give yourself a cookie if you got that one right.

Before we begin, change the ColdSpring.xml ModelGlueConfiguration reload setting to true.

ModelGlue has a standard component called a SimpleConfig. The purpose of the simple config is to hold on to a collection of values and this component is easily configured in ColdSpring. The path for SimpleConfig is ModelGlue.bean.CommonBeans.SimpleConfig, so add a configuration to ColdSpring for this. We will refer to this as AppConfig and it will hold our DSN and an AppTitle.

view plain print about
1<bean id="AppConfig" class="ModelGlue.Bean.CommonBeans.SimpleConfig">
2        <property name="Config">
3            <map>
4                <entry key="AppTitle"><value>Contact-O-Matic</value></entry>
5                <entry key="dsn"><value>ContactOMatic</value></entry>                
6            </map>
7        </property>
8    </bean>

Run your application. If you have an error at this point, check the exact path to the SimpleConfig component. No errors? Perfect!

Simple enough so far, right? Now we shall write our ContactTypeGW. This component will pull a query of ContactTypes from the database. There are three functions in the ContactTypeGW.

  1. setAppConfig - this function provides the way for ColdSpring to stick the AppConfig component in the ContactTypeGW
  2. getAppConfig - this function provides a way for us to reference the AppConfig component inside the ContactTypeGW
  3. getContactTypeQuery - this function returns the ContactTypes from the database

Your ContactTypeGW should look like this:

view plain print about
4 <cffunction name="getContactTypeQuery" access="public" output="false" returntype="query">
5 <cfset var ContactTypeQuery = "" />
7 <cfquery name="ContactTypeQuery" datasource="#getAppConfig().getConfig().dsn#">
8 SELECT ContactTypeID, ContactType
9 FROM ContactType
10 </cfquery>
12 <cfreturn ContactTypeQuery />
14 </cffunction>
19 <cffunction name="getAppConfig" access="public" output="false" returntype="any">
20 <cfreturn variables.instance.AppConfig />
21 </cffunction>
23 <cffunction name="setAppConfig" access="public" output="false" returntype="void">
24 <cfargument name="AppConfig" type="any" required="true" />
25 <cfset variables.instance.AppConfig = arguments.AppConfig />
26 </cffunction>

Note for the DSN we used 'getAppConfig().getConfig().dsn', when we want to access the AppTitle later, we'll use 'getAppConfig().getConfig().AppTitle'. (If you haven't seen this syntax before, getAppConfig() returns a reference to the AppConfig Object, which has a getConfig() function returning a struct. Then we access a property of the struct using dot notation.)

Now, adjust the ContactService to call ContactTypeGW. Remove the following functions: init, getContactTypes and setContactTypes. Add get and set functions for our ContactTypeGW. Then add the proper function for getContactTypes. It should return a query so be sure to adjust the returntype to 'query'

Your ContactManangerService should look like this:

view plain print about
4    <!---
6    --->

7    <cfset variables.instance = StructNew() />
10    <cffunction name="getContactTypes" access="public" returntype="query" output="false">
11 <cfset var ContactTypes = getContactTypeGW().getContactTypeQuery() />
12 <cfreturn ContactTypes />
13 </cffunction>
15 <cffunction name="getContactTypeGW" access="public" output="false" returntype="any">
16 <cfreturn variables.instance.ContactTypeGW />
17 </cffunction>
19 <cffunction name="setContactTypeGW" access="public" output="false" returntype="void">
20 <cfargument name="ContactTypeGW" type="any" required="true" />
21 <cfset variables.instance.ContactTypeGW = arguments.ContactTypeGW />
22 </cffunction>
24    <cffunction name="setContactList" access="public" returntype="void" output="false">
25        <cfargument name="ContactList" type="array" required="true" />
26        <cfset variables.instance.ContactList = arguments.ContactList />
27    </cffunction>
28    <cffunction name="getContactList" access="public" returntype="array" output="false">
29        <cfreturn variables.instance.ContactList />
30    </cffunction>

Now adjust ColdSpring to account for the new gateway functionality. Configure the bean definition for ContactTypeGW and add the AppConfig property. Replace the ContactType map with the ContactTypeGW bean The changed lines should look like this:

view plain print about
1<bean id="ContactService" class="ContactManagerMG.model.ContactService">
2        <property name="ContactList">
3            <list></list>
4        </property>
5        <property name="ContactTypeGW"><ref bean="ContactTypeGW" /></property>
6    </bean>
8 <bean id="ContactTypeGW" class="ContactManagerMG.model.ContactTypeGW">
9 <property name="AppConfig"><ref bean="AppConfig" /></property>
10 </bean>

Finally, our contact form was expecting a struct, it will now get a query so adjust the ContactType section accordingly

view plain print about
1<cfloop query="ContactTypes">
2 <option value="#ContactType#" <cfif ContactFormBean.getContactType() IS ContactType>selected</cfif>>#ContactTypes.ContactType#</option>

Remember to reinitialize your application and now run your code. You should now see the ContactTypes defined in your database

It seems like we touched a few files to make this change. We altered the ColdSpring.xml file to have an application configuration object, added in our ContactTypeGW and then stitched them together. We also had to adjust our form to account for a query in place of the struct. Note we did not touch our Controller nor our ModelGlue.xml file. Since the flow of the application did not change, those files remain the same and happily work with the new functionality of the application. This is an example of the benefits of compartmentalized, or encapsulated, code.

A zip of all files is included with this article.

Next, we will create the contact persistance and write our contacts to the database

Download Download