The Grade Schooler's Guide To ColdSpring - Part 3 Providing Default Values To ColdSpring
Introduction
In this part of our grade school ColdSpring primer, let's discuss providing default values that ColdSpring may use when creating the CFC objects it will manage for us. In the example code for this entry I've added a new CFC - UserGateway. This CFC contains functions that work with more than one user. However, this CFC, like the UserDAO CFC, must know (is depending on) a value for the datasource that connects ColdFusion with the database. I need to use the same datasource name for the UserGateway CFC as is provided for the UserDAO CFC (in my example this is justCSdbMySQL).
It is a good practice to not write the same datasource name more than once in the services.xml file (where we provide ColdSpring the information to resolve the CFC dependencies, see part 1, Naked ColdSpring). Writing the datasource name in more than one place could lead to code maintenance problems if we later change it. In large applications, we could easily have many CFCs that need to know the datasource name and then we could easily forget to update all of the datasource names in our services.xml file.
Fortunately, ColdSpring provides a simple way to pass a set of variables and their values that we can refer to in our services.xml file. So one of the variables we can set up is for the datasource name. In our services.xml file we can refer to that variables by using the notation ${variableName}.
Before I go too far in this blog post, I want to give a shout out to Daniel Vega. His blog entry (see reference 1 below) clearly explains this technique with a good example. His blog is chock-full of great ColdFusion code examples and well worth reading.
Example Code:
Download the example code zip file. If you made any changes to the part 1 or 2's example code, be sure to back those folders up before unzipping these files. Unzip all the files to coldspring/examples folder.
UserGateway CFC
In the model folder is a new UserGateway CFC. If you check out the init function note that it has a required argument with a name of dsn, which is used to set the value of variables.dsn (the datasource name). Variables.dsn can then be used through out the UserGateway CFC to gain access to the database.
application.cfm
<cfif not structKeyExists(application,"beanFactory") or structKeyExists(url,"reloadApp")>
<!---create a struct containing property values we want to supply to ColdSpring.
These property values can be referred to inside the ColdSpring services.xml file--->
<cfset defaultProperties = structNew()/>
<cfset defaultProperties.dsn = 'justCSdbMySQL'/>
<!---create the beanFactory object in application scope by calling the
DefaultXMLBeanFactory CFC's init method--->
<cfset application.beanFactory =
createObject('component',
'coldspring.beans.DefaultXmlBeanFactory').init( defaultProperties=defaultProperties ) />
Inside the if statement I created a structure named defaultProperties and set the dsn key of this structure to the value of "justCSdbMySQL". Next we pass this defaultProperties structure as the value for the defaultProperties argument of the DefaultXMLBeanFactory's init method. This gives ColdSpring access to the defaultProperties structure I created. We can refer to this structure's keys and their values in the services.xml file.
services.xml
In the services.xml file I added a new bean definition. See part 1, Naked ColdSpring for an explanation of the services.xml file and bean definitions.
<!--ColdSpring will create a userGateway object and pass it to the UserService CFC's
setUserGateway method (see code above for bead id="userService")-->
<bean id="userGateway"
class="coldspring.examples.justcoldspring.model.UserGateway">
<!-- We'll pass the datasource name value to
the init function's dsn argument. The ${dsn} tells ColdSpring
to find the property value for the dsn key in the ColdSpring's
defaultproperties structure. See application.cfm where
we create the defaultproperties structure and pass it to
ColdSpring -->
<constructor-arg name="dsn">
<value>${dsn}</value>
</constructor-arg>
</bean>
Note the value tag now has ${dsn}. The ${dsn} tells ColdSpring to look for a dsn key in the ColdSpring defaultproperties structure and replace the ${dsn} with that key's value. I can use this same ${key} in all the other places in the services.xml file where I need ColdSpring to provide the datasource name to a CFC.
Later if I need to change the datasource name, I just need to make the change in the application.cfm, make sure I use reloadApp as a URL variable in loading the index.cfm file, and all my CFCs that are being managed by ColdSpring will be setup with the new datasource name.
Summary
As you build larger web applications, you'll find more default values you'll want to provide to ColdSpring. Also as you progress in your ColdSpring education, you'll learn techniques for placing these default values in their own separate property file that can be parsed and used to create a ColdFusion structure (see reference 4).
References:
- Daniel Vega Blog, Passing Properties to ColdSpring
- ColdSpring Reference Guide, Installing ColdSpring and creating the BeanFactory
- Example Code For This Blog Entry
- ColdFusion Jedi Blog, ColdFusion 101: Config Files A-Go-Go
There are no comments for this entry.
[Add Comment]