As you can tell from my last two posts, I am getting pretty deep into Coldbox used in conjunction with Coldspring. One of the things that Coldbox does for us is pass in our configuration settings to the Coldspring bean factory when it initially loads our beans (from Coldspring.xml), thus allowing us to use configuration variables, like so:
The only shortcoming with this is that because we're using Coldspring's DefaultXmlBeanFactory.cfc, it will only do variable replacements when they are found within <value> tags. Brian Kotek addressed this issue with a CFC found in his Coldspring Utilities collection (http://coldspringutils.riaforge.org/ ) , specifically with a CFC called "DynamicXMLBeanFactory.cfc". Using this instead of Coldspring's default bean factory allows you to place variables in other places within your Coldspring.xml. I've used this CFC before in another project, so now my challenge was to figure out how to implement it in Coldbox so that I could make my Coldspring.xml file more dynamic.
<constructor-arg name="datasourcePath">
<value>${TransferSettings.datasourcePath}</value>
</constructor-arg>
....
After a couple hours of tinkering around, AND having to make a minor modification to DynamicXMLBeanFactory.cfc to account for it being used in the Coldbox environment, here are the steps:
1. Place a copy of the modified version of DynamicXMLBeanFactory.cfc in the Coldbox/System/Extras/Coldspring folder. The Coldspring folder won't exist, so go ahead and create it;
2. Add a setting to your Coldbox.xml.cfm file like so: That's it! If you want to make sure it's working, create a Coldbox.xml setting such as this:
and then add that variable to your Coldspring.xml as part of a bean's class path, for instance:
If the app fires up without error, you're in business!
<Setting name="ColdspringBeanFactory" value="coldbox.system.extras.coldspring.DynamicXMLBeanFactory" />
....
Hope this helps someone. :0)
P.S.
If anybody is interested in the changes I made to DynamicXMLBeanFactory and why, they are as follows:
1. Since DynamicXMLBeanFactory extends Coldspring's DefaultXmlBeanFactory, and since Coldbox is hardwired in its "ioc" plugin to interact with DefaultXmlBeanFactory's interface (specifically calling the method "loadBeansFromXmlFile", which does not exist within DynamicXMLBeanFactory), I had to overload that method in DynamicXMLBeanFactory like so:
2. DynamicXMLBeanFactory was executing an "expandpath" on an already expanded path (Coldbox is already passing in the fully expanded path to the Coldspring.xml file ), resulting in an error of "file not found". Because of this, I had to comment out line 98 in the "getReplacedColdSpringXML" method.
<cfargument name="beanDefinitionFile" type="string" required="true" hint="I am the location of the bean definition xml file"/>
<cfset loadBeansFromDynamicXmlFile(arguments.beanDefinitionFile,getDefaultProperties()) />
</cffunction>
Perhaps there was a more elegant method for implementing Brian's CFC, but the only two choices I saw was to either modify the framework (NO! BAD MAN! NO!), or the CFC. I opted for the CFC. What I was thinking, though, is that perhaps it would be good if Coldbox allowed not only the path to the IOC's beanfactory class to be a setting, but also the name of the bean loader method that should be called (after init)? Just a thought.
Doug out
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
This functionality is now in SVN for both coldspring and embedded lightwire in ColdBox. THe new version also has this method exposed in the Utilities plugin: placeholderReplacer(), which can be used for ANY application you want to use ${} groupings. The difference on my approach is that you can use it for any string, struct and have nested structure evaluations, plus it is super tiny.
Enjoy.