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.
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.
- setAppConfig – this function provides the way for ColdSpring to stick the AppConfig component in the ContactTypeGW
- getAppConfig – this function provides a way for us to reference the AppConfig component inside the ContactTypeGW
- getContactTypeQuery – this function returns the ContactTypes from the database
Your ContactTypeGW should look like this:
SELECT ContactTypeID, ContactType
FROM ContactType
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:
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:
Finally, our contact form was expecting a struct, it will now get a query so adjust the ContactType section accordingly
selected>#ContactTypes.ContactType#
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 persistence and write our contacts to the database