In my last post, we went through a brief introduction of ColdSpring and how you can use it to make configuring your application’s objects much easier. We discussed how objects (beans) are declared in ColdSpring’s XML configuration file and how you can pass any number of values into ColdSpring to be used in configuring those beans using the defaultProperties argument when you create the ColdSpring obect. At the end of the post, we touched on a slight “problem” with using ColdSpring this way.
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:
<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.
<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.
<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.
<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.