The slides have been uploaded to SlideSix.com or you can view them below. A PDF version of the slides is also available for download.

Thanks to all those folks that attended my session. Also a huge thanks and a job well done to the conference committee and volunteers that made the conference happen.

I’ll be presenting an introduction to dependency injection using the ColdSpring framework titled “Intro to ColdSpring: A solution to a problem you may not know you have”.

I’m also looking forward to meeting face-to-face with a bunch of folks I’ve interacted with digitally over the last few years. Hope to see a bunch of you there!

cfUniform is a ColdFusion custom tag library that makes adding validation to your forms a snap. The fact that it writes (most) validation for you based on attributes you put in the tag makes it worth using for that feature alone in my mind. However, the benefits don’t stop with validation. It also styles your form fields, labels, hints and error messages for you. Since you can configure a link to a CSS stylesheet in the configuration for the custom tag, you can skin the output generated by cfUniform to match your site’s look and feel.

Best of all, its REALLY easy to get started with. The example below assumes that you’ve put /tags and /commonassets folders from the distribution file in the root of your web site.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

<cfimport taglib="/tags/forms/cfUniForm" prefix="uform" />
 
<div class="cfUniForm-form-container">
	<uform:form action="someFile.cfm" 
		id="loginForm" 
		submitValue=" Log In " 
		loadjQuery="true" 
		loadValidation="true" 
		loadMaskUI="true" 
		loadDateUI="false" 
		loadTimeUI="false">
 
		<uform:fieldset legend="">
 
			<uform:field label="User Name" 
			       name="username" 
			       isRequired="true" 
			       type="text"  
			       hint="Enter your user name." />
 
			<uform:field label="Password" 
				name="password" 
				isRequired="true" 
				type="password"  
				hint="Enter your password." />	
 
		</uform:fieldset>		
	</uform:form>
</div>

That simple example gets you a login form that has javascript validation requiring a value in both fields as well as Javascript-driven error message feedback to the user when they don’t fill out one of the fields. Obviously this is a very simple use case and cfUniform supports a whole range of things you typically want to do on a form. If you have a very specific validation case, you can even specify your own custom javascript to use as the validation when the form is submited.

If you’re like me, you’ve probably got a “pet” folder structure that you use for your projects and they typically don’t have the folders /tags and /commonassets hanging off the root. The developers foresaw this quandary and included the facility to pass in a structure containing configuration keys that point the library to the location of various files in the web structure. This is one of my favorite features because it allows me to compartmentalize the library into whatever part of my folder structure I want and then pass in the configuration values. It also makes it very easy to configure a config object in ColdSpring using a MapFactoryBean (remember talking about those a couple weeks ago in this post?) so that you reuse the same configuration object every time you use the library throughout your application.

I’ve not gone into a great amount of detail here on how to use the many features of the library because the developers have a well-rounded set of examples already published. There you’ll see the directions for how to set up a MapFactoryBean config object in ColdSpring as well as all the other form field options that you have in the framework.

Thanks to Matt and the other developers for removing a great portion of the mundane Javascript validation stuff and giving us an easy-to-use library to standardize the look and feel of our forms.

To be fair, the “problem” isn’t with ColdSpring at all. The problem is with us developers–we’re lazy and we hate redundant typing. In a large application with dozens or more objects, we don’t want to constantly have to type ${dsn} every time we want to inject the DSN property into a bean. Multiply dozens of objects by potentially several properties needed by each object and you can set yourself up for quite a bit of typing, just to get the beans configured (and that doesn’t even take into account that most of us are bad typists and can’t spell DSN the same way a dozen times in a row).Luckily for us, the brilliant folks that gave us ColdSpring built in a couple of beans that we can use to solve the “problem”. Those beans are called the MapFactoryBean and the ListFactoryBean. Don’t be scared off by their names. Their functions actually mimic a couple of ColdFusion data types that you already use every day anyway.

What’s a MapFactoryBean anyway?

A MapFactoryBean is ColdSpring’s method of storing any number of key/value pairs so they can be inserted easily together into your components. What’s that? You say that ColdFusion has something built in that does key/value pairs in a single variable? You’d be correct Grasshopper. MapFactoryBeans are ColdSpring’s way to configure a ColdFusion structure that will be passed in as an argument to your other beans.

Before MapFactoryBeans, using just properties, we might have something similar to the code below in dozens of objects in our config file:

1
2
3
4
5
6

<bean id="MySuperService" 
    class="components.services.MySuperService"> 
    <property name="key1"><value>${value1}</value></property>
    <property name="key2"><value>${value2}</value></property>
    <property name="key3"><value>${value3}</value></property>
</bean>

Now, we can set those properties into a MapFactoryBean once.

1
2
3
4
5
6
7
8
9
10

<bean id="PropertyMapBean" 
   class="coldspring.beans.factory.config.MapFactoryBean">
   <property name="SourceMap">
       <map>
          <entry key="key1"><value>${value1}</value></entry>
          <entry key="key2"><value>${value2}</value></entry>
          <entry key="key3"><value>${value3}</value></entry>
       </map>
    </property>
</bean>

Remember in my last post we talked about ColdSpring’s ability to inject other beans as arguments into your beans? Now that we have our properties consolidated into a MapFactoryBean, you can inject it into your other beans rather than passing in individual properties each time.

1
2
3
4
5
6

<bean id="MySuperService" 
    class="components.services.MySuperService"> 
    <constructor-arg name="configProperties">
          <ref bean="PropertyMapBean" />
    </constructor-arg>
</bean>

NOTE: Don’t forget to include the XML node <property name=”SourceMap”>. It’s important.

So then a ListFactoryBean must be…

…the equivalent of a ColdFusion list then right? Well, close but no cigar for you on that one. ListFactoryBeans actually give you the ability to pass a ColdFusion array into your beans. You get partial credit though because at least you were thinking “outside the bean”.

Creating a ListFactoryBean is just as easy as creating a MapfactoryBean.

1
2
3
4
5
6
7
8
9
10

<bean id="PropertyListBean" 
    class="coldspring.beans.factory.config.ListFactoryBean">
    <property name="sourceList">
       <list>
          <value>${value1}</value>
          <value>${value2}</value>
          <value>${value3}</value>
       </list>
    </property>
</bean>

As before you can now pass this into your beans and use it in your objects as a native ColdFusion array.

Why use these two beans?

You may be asking yourself, “why can’t I just use ColdFusion structures and arrays instead of these fancy-schmancy beans”. That’s a great question. The answer lies in the fact that ColdSpring’s beans and attributes are configured via XML. Ever tried to create a ColdFusion variable inside an XML file? Nah, didn’t think you had. I’m being a bit flippant there I realize, but the bottom line is that ColdSpring uses these two beans to give us a way to create ColdFusion native data types from within our XML configuration.

So, as you can see from the above, simplified examples, the ColdSpring crew has done a fantastic job of not only giving us a tool (ColdSpring) to make our lives easier, they’ve also given tools (MapFactoryBeans and ListFactoryBeans) to the tool to help us with our redundant typing phobia.

Along the way I naturally heard about various frameworks related to ColdFusion (Fusebox, Model-Glue, Mach-II, ColdSpring etc etc) but never gave them more than a passing glance as I was trying to cram a bunch of new concepts into my brain as it was and I just didn’t have the mental bandwidth to take on frameworks at the same time (however that has since changed and I’ve had a chance to work with Mach-II and Model-Glue). Eventually I got to the point where my applications used numerous objects and some of those objects required the services of other objects to do their jobs. That’s the point that I really began struggling with the effort involved in writing a good OO application. It took lots of lines of code to create an object, configure it simply to pass it into another object. Sound familiar? Maybe you’re at that point with your ColdFusion OO trek. If so, read on and I’ll introduce you to ColdSpring, a free dependency-injection framework (whoa there, stay with me, don’t let the buzzwords turn you off) that will make your life much easier.

What is ColdSpring?

The simplest way to describe what ColdSpring does for us (for dependency injection at least) is to think of it as an centralized place where we can go to retrieve fully-configured, ready-to-use objects within our code. We ask the ColdSpring object for a particular ?bean? (every object in ColdSpring is referred to as a bean…don?t get that confused with a bean in the Gateway/DAO/bean design pattern) and ColdSpring creates the object, runs the init methods with any arguments and hands it back to us ready to use. If one of the arguments happens to be another object, ColdSpring creates that object, inserts it into the init function automatically. Sounds great right? Trust me, it gets better.

There are two main benefits of using ColdSpring this way.

1. The configuration for a specific ?bean? is confined to one place (the coldspring.xml file) so if something changes with the object, you don?t have to go searching all over your code base to update all the places where you?ve manually created the object.
2. Object creation and configuration is the same every time meaning that you don?t have to remember all the configuration parameters every place in your code where you need to use that object.

There?s a third, less obvious advantage to using ColdSpring to manage your objects. When you define an object in ColdSpring, you can elect to tell ColdSpring to make it a singleton (meaning that only one instance of this object will ever exist in your entire application). Any time after application init that you ask for that object, ColdSpring will hand you the copy of it that already exists, eliminating the time required to create and configure a new instance.

This benefit comes with a bit of a caution however. You should never create any objects as singletons that store session-specific data (such as a Product, User, etc). DAOs, Gateways, Config objects and the like are prime candidates for singleton status because, while they have attributes within them that they need to do their jobs, they simply move data around as requested, never storing that actual data within themselves.

How ColdSpring makes life easier

Using ColdSpring increases modularity within our code base. Essentially, each CFC should be as ?dumb? to the world outside itself as possible. Code within a CFC should not reach out to shared scopes to pull values (eg Application, Session, Server scopes, etc). It should not be responsible for knowing the dot-notated path to a particular object that it needs to use to do its work. This is sometimes referred to as the ?Law of Demeter? or ?Principle of Least Knowledge?. Essentially, this principle states that an object should be provided everything it needs (called dependencies) to do its job and should not have to have knowledge of anything outside itself and the objects that are given to it in order to perform its work.

For example, consider a DAO component that requires a datasource to run its queries. If you hard code #application.dsn# into the datasource attribute of every <cfquery> tag and someone comes along and decides that a more verbose variable name (say application.datasource) is preferable, you have to manually update every <cfquery> tag in your application.

However, if you?ve created a private variables.datasource property inside your DAO component and included a <cfargument> in your init function that takes the name of a datasource which is then stored in your private property, your <cfquery> tags have no need to know that, outside your DAO component, you?ve changed the name of the variable storing that string. This is, admittedly, a simple example, but the same holds true whether it?s a simple value or another object that is required to be passed in so your component can do its job.

ColdSpring makes adhering to this principle much easier than if you were doing all the dependency creation by hand before passing it into the object. By specifying in your datasource as a default property when you create the ColdSpring object, you can reuse that in all your objects. Consider the following example to create the ColdSpring object:

1
2
3
4
5
6

<!--- Create ColdSpring defaultProperties --->
<cfscript>
	defaultProperties = structNew();
	defaultProperties.dsn = "myHighPoweredDatasource";
	defaultProperties.mailServer = "mail.mydomain.com";
</cfscript>

When you create the ColdSpring object and pass in the “defaultProperties” structure, you can then reference these values in your object creation. For example:

1
2
3
4
5
6

<bean id="CustomerDAO" 
        class="model.customers.CustomerDAO" singleton="true">
	<constructor-arg name="datasource">
		<value>${dsn}</value>
	</constructor-arg>
</bean>

The code above tells ColdSpring to create an object named CustomerDAO using the component located at model.customers.CustomerDAO. Once it?s created ColdSpring will run the init method (ColdFusion?s constructor method) and pass in the value of the default property “dsn” as an argument named datasource. What this is accomplishing is effectively removing any link between your DAO component and the application.dsn variable. Your component doesn?t know (and frankly doesn?t care) that there?s a value stored in the application scope—you?ve explicitly given the DAO object all it needs to do its job.

Notice if you will the last attribute on the <bean….> line above. See that? Setting singleton=”true” means that there will only ever be one CustomerDAO object created in your application—a big plus if you?re constantly getting and putting customer records to/from the database through this object.

Constructor args to ColdSpring bean definitions need not be simple values. Consider the following bean configuration entry from that same example:

1
2
3
4
5
6
7
8
9

<bean id="CustomerGateway" 
	class="model.customers.CustomerGateway" singleton="true">
	<constructor-arg name="datasource">
		<value>${dsn}</value>
	</constructor-arg>
	<constructor-arg name="dao">
		<ref bean="CustomerDAO" />
	</constructor-arg>
</bean>

Our CustomerGateway object needs a datasource and a DAO object to be able to do its job. Here we’re creating a CustomerGateway object much the same way that we created the DAO. The first constructor argument is the same datasource that we used in the DAO (hey, they need to talk to the same database right?). However, notice the content of the second <constructor-arg>. Here we?re not passing in a simple variable using the <value> tag. We?re telling ColdSpring that it should pass the “bean” named “CustomerDAO” that we previously created to the init function of the CustomerGateway as an argument named DAO.

So, that?s a little different than passing in a simple string, right. Not according to ColdSpring. The beauty of this is, Coldspring will create and configure the CustomerDAO “bean” first and then pass that fully-configured, ready-to-use (don’t forget singleton) object into the CustomerGateway bean (even if in your XML config file you have the DAO config AFTER the Gateway config).

If you were doing this by hand, you?d have to manually create the DAO object, run the init function passing in the DSN. Then manually create the Gateway object, run the init function and pass in the DSN and the DAO object you just created….every time you needed a Gateway object. That?s a fair amount of work right? ColdSpring does this all for you with a few simple lines on XML configuration and you can get on to more important parts of building the application.

But what about….

Aha Grasshopper, I can see that you’ve realized something. We’re continually having to manually type ${dsn} (and other string variables you need to give to your objects). That’s a lot of work right? Patience, Grasshopper, next time we’ll talk about two tools that the brilliant developers of ColdSpring gave us to solve that very (redundant) issue—the MapFactoryBean and the ListFactoryBean. Until then…..

**Special thanks to my good friend Dan Wilson for his insight into object-oriented principles, ColdSpring and a bunch of other cool stuff.