Brian Kotek: Inversion of Control - ColdSpring

Iterator on RIAForge, and Updates to FormUtils and ColdSpring Utils

Wed, 16 Dec 2009 09:49:00 -0700

The blog has been quiet lately, but that should be changing now that I'm finally doing some real work with ColdFusion 9! In the meantime, I've committed a few minor updates to some RIAForge projects, and added a new one. The new project is Collection Iterator. This is simply a CFC that allows you to iterate the same way over queries, lists, structures, or arrays. The syntax is simple:


var array = ['foo', 'boo', 'zoo'];
var iterator = new Iterator( array );
var counter = 0;

while( iterator.hasNext() )
{
    counter++;
    var thisRow = iterator.next();
    assertTrue( array[counter] == thisRow, "Array element not found." );    
}

assertTrue( counter == 3, "Iterator did not loop the correct number of times." );

The obvious benefit is that it lets you handle all four collection types in a standard way. This is a CF9-only component, as it is written using the new script-only CFC syntax (which I LOVE, but will be talking about further in future entries). As for updates, I fixed a bug in the DynamicXMLBeanFactory, which is part of the ColdSpring Bean Utilities library. There was an issue when using ColdSpring configuration files that imported multiple other config files. The CFC was also modified to only attempt to do an ExpandPath() on the configuration file location if a file doesn't exist using the value supplied by the developer. I also updated the FormUtils CFC to make the constructor arguments optional, to make it easier to configure and use. So, that's all for now, but look for some entries on CF9 ORM tips and techniques, as well as a full reboot of my earlier series on the Swiz framework for Flex. Swiz 1.0 alpha was just released, and as the finishing touches are added I plan to be blogging about all the excellent new capabilities that have been added by the Swiz team!

ColdSpring on TheServerSide.com

Tue, 06 Jan 2009 17:08:00 -0700

Just a quick note that an article on ColdSpring that I wrote for TheServerSide is now online.

What's New In ColdSpring 1.2?

Mon, 22 Sep 2008 11:52:00 -0700

Some folks on the list asked (understandably) for a "what's new" list for ColdSpring 1.2, so I put this together. We should get it up on the site shortly as well:

Bean Aliases: Allows you to define additional bean IDs for existing beans. i.e.:
Abstract / Parent Beans: Allows you to reduce XML duplication by defining common properties and settings in a parent bean that can be used by multiple child beans. See Quickstart Guide for full details and examples.
Collection Factory Beans (ListFactoryBean and MapFactoryBean): Factory beans that will create collections. ListFactoryBean creates an Array, MapFactoryBean creates a structure. Array Element 1 Array Element 2 Array Element 3 keyA value keyB value keyC value
Import XML directive: Allows you to include the contents of a separate ColdSpring XML file into another ColdSpring XML file:
Bean Factory Postprocessors: Allows you to specify a component that will run after all beans have been processed and apply additional processing on the bean definitions. ColdSpring will call postProcessBeanFactory() on each postprocessor, and you can then run any additional processing you would like to. For an example, look at /beans/factory/config/PropertyPlaceholderConfigurer.cfc.
coldspring.cfcunit.AbstractAutowireTests and coldspring.cfcunit.AbstractAutowireTransactionalTests: Both of these allow you to provide the location of your applications bean config file and then simply define setters for any beans you want to test. The transactional version automatically rolls back database transactions. You can read Chris Scott's blog entry about both of these.
Numerous bug fixes and improvements: Over 30 bug or enhancement tickets have been resolved, with critical improvements in thread safety, having ColdSpring call inherited methods and constructors during autowiring and bean creation, automatic support for creating any beans marked with lazy-init="false" at bean factory creation, and many others.

ColdSpring 1.2 Gold, and New ColdSpring Site

Fri, 12 Sep 2008 09:05:00 -0700

After a long wait, version 1.2 of the ColdSpring dependency injection framework has been released. This includes a large number of bug fixes and enhancements since the last official release. Along with 1.2 is a new ColdSpring web site. Rachel Lehman did a great job with the new design. And of course, hats off to the others on the team (Chris Scott, Dave Ross, Adam Lehman, Kurt Wiersma, and others) for all the work on ColdSpring over the months and years! To toot my own horn a little, in addition to fixes and enhancements, I added a new example to the ColdSpring codebase called the ColdSpring Quickstart Guide which you can see at the live site, but can also run locally if you'd like to look at the code (it's all live ColdSpring code). Since our next task is a full update of the documentation, I thought adding this would be a good interim step while we get that in place. Anyway, what are you waiting for?! Go check out the new site and grab the latest release if you don't have it already. :-)

BeanInjector Patch from Paul Marcotte

Mon, 04 Aug 2008 09:59:00 -0700

Paul Marcotte sent me over a small test case that demonstrated an issue with the BeanInjector CFC. I went through his test and discovered a bug in the BeanInjector that stopped recursion up the inheritance hierarchy in certain cases. This has been fixed and pushed out to the ColdSpring Bean Utilities RIAForge project. Thanks to Paul for helping me to spot this, as well as sending over a very small test case to help me reproduce the problem. I can't overstate how valuable this sort of thing is. Removing any extraneous code and just including the files that are involved in the problem really makes it easier to track down bugs.

My IECFUG Presentation Recording and Files

Tue, 15 Jul 2008 13:44:00 -0700

Last Friday I gave a presentation to the Inland Empire ColdFusion User Group. It covered a range of topics: MXUnit, ColdMock, and elements of my RIAForge FormUtilities and ColdSpring Bean Utilities projects. The presentation went well, I think. There are a few technical issues towards the end when they were trying to set up a microphone to get a Q&A going, but they are minor. I've linked to the files and the recording below in case anyone is interested in having a look. Thanks again to Sami, Luis, and the IECFUG for allowing me to present!

DynamicXMLBeanFactory and Custom FactoryBeans added to ColdSpring Utils Project

Thu, 10 Jul 2008 08:23:00 -0700

Late last night I updated the ColdSpring Bean Utilities RIAForge project. The updates include:

Added DynamicXMLBeanFactory: This extends the standard DefaultXMLBeanFactory but allows the ability to replace dynamic properties anywhere in the XML file, as well as in imported XML files.
Added MetadataAwareProxyFactoryBean: This extends the ColdSpring ProxyFactoryBean and automatically injects metadata information into any Advices that extend AbstractMetadataAwareAdvice after the AOP proxy is created.
Added MetadataAwareRemoteFactoryBean: This extends the ColdSpring RemoteFactoryBean and automatically injects metadata information into any Advices that extend AbstractMetadataAwareAdvice after the remote proxy is created.
Updated the AbstractMetadataAwareAdvice and the VOConverterAdvice for better integration with the new custom FactoryBeans.
Added an Examples subfolder to show these components working. A readme file is include to explain how to set it up.

The CFCs themselves all contain fairly thorough documentation in their header comments, but I'll talk briefly about some of the new components. The new custom FactoryBeans (MetadataAwareProxyFactoryBean and MetadataAwareRemoteFactoryBean) are something of uncharted territory for me, and I'll be interested to hear what some other ColdSpring users think of how I am doing this. Basically, these extend the base ColdSpring ProxyFactoryBean and RemoteFactoryBean and contain logic to loop over the advice chain and inject metadata information into any advices that extend AbstractMetadataAwareAdvice. Back when I first started talking about making metadata available to Advices by having ColdSpring pass the beanID of the proxied bean into the Advice, there was a lot of concern about increased coupling between the Advices and ColdSpring. I believe that the way I am using this sidesteps the issue. My Advices are still extremely generic. All the metadata does is allow them to behave more flexibly. For example, I could create some security metadata that specifies different rules for different method calls, and a SecurityAdvice could would be able to process the correct rules for the current method call without a lot of conditional logic or actual dependence on the name of the bean or the name of the method. All it knows is that the metadata it was handed says "apply these rules now", and it does. The same could be true for a LoggingAdvice. All it would know is that the metadata being passed to it says "log these variables", and it does. The fact that you can specify different logging settings for different beans or methods is totally hidden from the Advice. Overall I've found these new components to be very useful. I hope others agree! As always, please reply with any questions or comments. Thanks.

Ask Brian: How to Handle Object Composition?

Thu, 12 Jun 2008 11:11:00 -0700

Christopher R contacted me through my contact form to ask about object composition. I thought I would answer it here in case it helps other folks as well. I'm also planning on answering questions like this going forward, so if anyone has questions that you think I can help with, feel free to contact me through the blog and I'll do my best to answer!

greetings...i recently came across a great article you wrote called "Write efficient code with the Composition object pattern and CFCs". it greatly assisted in my initial dilemma involving how to relate distinct but related classes. the current article works for related classes (PhoneNumber) into which you pass a final piece of data (e.g. the phone number). however, whats the best approach when that data is merely a reference or pointer (e.g. PhoneID) that requires further querying / creation of data access objects? as an example, several customers may share the same phone number (PhoneID). in this case - bear in mind that we still want to stick to OOP + not introduce db queries into the related class (e.g. PhoneID.cfc) - we might use a DAO to communicate with the related class (e.g. PhoneDAO.cfc) into which we would need to pass a database ref along with the PhoneID(s) in order to find the proper record. i would like to return a reference to the Phone object that the main class (e.g.Customer) could then utilize. to better elucidate the approach, im following a series of articles at iknowkingfoo. hopefully this makes some sense - difficult to encapsulate in writing succintly. im getting up in arms as far as these objects, accessing their data as well as trying to access application variables. any help greatly appreciated.

thanks in advance.

To reiterate, composition models a "has-a" relationship between objects, as opposed to an "is-a" relationship which is typically done through inheritance or interface implementation. However, Christopher seems to be working with two different kinds of objects here: Singletons and business objects. How you handle the composition can depend on the kind of object you are dealing with and what they are meant to do. For example, a PhoneDAO would almost certainly be a Singleton object, meaning that only one instance of the PhoneDAO exists in the application. However, a PhoneNumber object would be a business object, meaning that there could be many instances of PhoneNumber, each with their own data, modeling many different actual phone numbers. The same goes for Customer. Customer is a business object. The question seems to be how to build up composite object relationships in your business objects. The answer is usually to use a Factory to build your business object. The Factory would also be a Singleton since you only need one. So Christopher might consider creating a CustomerFactory which he would call "getCustomer(13)" on to create an instance of that Customer and return it. The factory would then be responsible for also creating and setting any composite objects. As a result, the factory may itself have other singletons composed within it such as a CustomerDAO, PhoneNumberDAO, etc. The factory would use these objects and know what to do with the results (in this case, setting the resulting PhoneNumber into the resulting Customer before returning it). The idea with factories is not only that they create objects. It has to do with the primary OO design principle of encapsulation. What the factory encapsulates is knowledge of how to create and relate a Customer and a PhoneNumber. This is crucial to understand, because it means that you become free to change how the Customer and PhoneNumber are created and related at any time. Nothing outside the factory would ever know that you made any changes. Consider the Transfer ORM framework. Transfer handles making queries to the database as well as building object relationships for you. It is very handy, and I would recommend that Christopher have a look at it when he has the time to evaluate it. But lets say that he creates a CustomerFactory and any code that needs a user calls customerFactory.createCustomer(id). If he later decides to use Transfer, he can easily make that change because he only has to change one thing: the CustomerFactory. He can remove his own DAOs and rip out the logic that relates these objects, and replace it with calls to Transfer. Nothing outside his factory needs to know that the way these objects are being created has changed. That is the beauty and power of encapsulation, and why factories are so useful. For building composite relationships in your Singletons, there is another option to consider: the ColdSpring framework. This framework is designed primarily to "wire up" or relate your Singleton objects. That means things like Services, DAOs, Gateways, etc. It is a really powerful tool but does have a learning curve to wrap your head around. I have a number of blog entries on ColdSpring and there are numerous other blogs and mailing lists that can help with this as well. If you give ColdSpring a look and I can offer any additional help please let me know. Hopefully that helps, Christopher? I'd look at using a factory to handle creating and relating your objects. The factories can get rather complex if you have a lot of object relationships to manage, but again, the logic is all kept in the factories. It's certainly possible for one factory to use another factory as well, so don't feel like you have to create a single uber-factory that does everything. And if or when you decide to try out another approach such as Transfer, you'll be happy you went the factory route. Good luck!

More on Extending ColdSpring: A Custom BeanFactory

Fri, 06 Jun 2008 12:38:00 -0700

The more I dig into how ColdSpring works the more impressed I am with it (and I was already hella impressed). I'm realizing that a lot of the utility and helper CFCs I've created and released on RIAForge can actually be implemented directly within ColdSpring by extending it. [More]

Extending ColdSpring Through Custom Factory Beans

Tue, 03 Jun 2008 18:05:00 -0700

Before I jumped across the pond to London and Paris last week, I had posted a blog entry about ColdSpring Remote Proxies. In response to some of the comments and IM messages, I wanted to expand on my mention of extending ColdSpring with your own Factory Beans. The ability to create your own extensions to ColdSpring is an extremely powerful technique. Unfortunately, it's also an extremely unexplained technique! I hope to change that a bit, so let's get to it. If you aren't familiar with ColdSpring's ability to automatically generate Remote Proxy components, I'll refer you to a few blog entries:

In a nutshell, ColdSpring can create remote proxy CFCs for your actual underlying CFCs, typically service layer components. Which is pretty darn sweet. Unfortunately, the configuration XML to do this can get rather verbose, especially if you want to create numerous proxies. Consider:



	
		
	
	
		application
	        
	
		beanFactory
	    
	
	
		RemoteUserService
	
	
	
		/remote
	
	
	
		*

It seems like a lot, and I suppose it is. The good news is that you only have to do it one time, at the start of your project. Still, my previous blog entry showed that you can trim this down a bit, especially if you are creating more than one remote proxy:




	
		application
	
	
		beanFactory
	
	
	
		/remote
	




	
		
	
	
	
		RemoteUserService
	
	
	
		*

Better, but I still think we can improve on it. But this is where we go into potentially scary territory: we're going to extend ColdSpring to make our lives easier. In this case, I'm going to create my own custom Remote Factory Bean that extends ColdSpring's RemoteFactoryBean and sets up some default values that I tend to use over and over in my applications. This reduces the XML configuration even further, but still allows me to override the defaults if I need to. Here is the XML:



	
		/remote
	



	
		UserService
	
	
		*

Hmm, that's quite a bit shorter! You'll notice that my RemoteUserService is specifying it's class as "CustomRemoteFactoryBean". That's the first change. You may also notice that many of the properties are gone, but a new one has appeared: "targetBeanID". By passing the targetBeanID to my custom factory bean, I can set up a series of default property values due to the fact that my remote proxies tend to follow a fairly standard setup. Here is the code for the CustomRemoteFactoryBean to demonstrate what it is doing:

The CustomRemoteFactoryBean extends the ColdSpring RemoteFactoryBean and adds additional behavior. If you weren't aware, under the hood ColdSpring calls getObject() on the RemoteFactoryBean when it needs to create an instance of your remote proxy. You can see that my getObject() method is automatically setting up default values for the service name, target, bean factory name, and bean factory scope if these are not defined. Then it simply calls the superclass's getObject() method to actually create the remote proxy. This is how I can get away with specifying so little in the XML. Your first reaction might be "OK that's kind of cool because I hate typing XML, but is that really it?" Yes, that is it! For this blog entry anyway, since it's gotten rather long. But if people want me to keep going I can expand further. In the meantime, you might start thinking about what sort of behavior you can add to your own custom getObject() method that adds behavior beyond defining simple default values. And please fire away with thoughts or comments!

More on ColdSpring and Remote Facades

Mon, 19 May 2008 09:14:00 -0700

Andy Jarrett posted a very nice overview of using ColdSpring to create Remote Proxies for your CFCs. I wanted to add a bit more to what he was saying and see if anyone has an interest in more details. The first bit is just a small change that makes life easier. In Andy's example, he defines the remote proxy in his ColdSpring XML file and then manually calls getBean() to create that remote proxy. You actually can do this in an easier way, using the lazy-init attribute and the constructNonLazyBeans argument. If you pass "constructNonLazyBeans=true" as an argument to loadBeansFromXML, ColdSpring will automatically create any beans that you have not explicitly marked as lazy. Which means you can avoid having to manually call getBean() for all of your remote proxies. You just need to execute one initial request to your application, and it will create the remote proxies automatically. This is handy if you start having numerous remote proxies being generated. Next is a small tip to make your configuration life a little easier. Andy shows the XML to define a remote proxy. It's fairly verbose XML, unfortunately. That's just how ColdSpring is. However, we could make life a bit easier on ourselves by defining a parent bean and setting common values there. Again, this makes life easier once you start getting into multiple remote proxies. You can do something like this:



	
		application
	      
	
		beanFactory
	   
	
	
		/remote_cs
	



	
		
	
	
	
		rUserServices
	
	
	
		*

As you can see, assuming you are OK with having the same bean factory name, having the remote proxies be created in one central folder, etc., you can cut down the amount of XML you have to write per-proxy by a lot. And one last time, don't forget that you can extend the base RemoteFactoryBean and ProxyFactoryBean components that ColdSpring uses to define your own custom behavior. This can reduce work even more by letting you skip a lot of the XML entirely and define settings or behavior directly in your custom Factory Bean. I can expand on this if anyone wants to hear more, I'm just not sure how many people are actually using these parts of ColdSpring so I thought I would ask before I launch into a blog entry that no one cares about. ;-)

Slides and Code from My Code Generation Presentation

Sat, 03 May 2008 14:48:00 -0700

As promised, here are the slides and code from my cf.Objective() 2008 presentation, "Leveraging Code Generation to Jumpstart Your Development". Check the bottom of this entry for the enclosure. So far the conference has been great. I've learned a lot at several sessions, including Andrew Powell's integration presentation on using Spring and Hibernate as the Java model for an app using CF for Controller and View. Chris Scott's ColdSpring presentation got my wheels turning with regard to custom Proxy Factories. And the announcement of the ColdFusion Open Initiative was most welcome, with a public bug base and more organized enhancement request system. I'll post more after the conference is over, but so far it's been as good as I expected it to be!

Meet ColdSpringXMLUtils, a New Addition to the ColdSpring Bean Utilities Family

Fri, 21 Mar 2008 08:36:00 -0700

One thing that I've heard people ask about in the ColdSpring mailing list over the years relates to properties. These are quite useful. If you didn't know, you can specify a dynamic property in certain places in your ColdSpring XML using the syntax ${myPropertyName}. You then pass a structure of property names and values into ColdSpring, and it will substitute your property names for the placeholder values. It's a nice feature, but it only works in specific places, like simple string values. People regularly discover this option, and then wonder why they can't put dynamic properties anywhere in the XML. Well, now you can! The ColdSpringXMLUtils component has joined the ColdSpring Bean Utilities RIAForge project. It will replace dynamic properties in a ColdSpring XML file with values specified in the passed structure. Using this CFC allows you to place dynamic properties anywhere in the XML. Note that because the ColdSpring XML file can be quite sizable in large applications, this component uses a Java StringBuilder to avoid using up large amounts of memory while doing the replacements. As a result, this component must be used on a server that is running Java 5 or later. Most installations of ColdFusion 7 or 8 should be running at least Java 5 so this should not affect many people. Usage of the ColdSpringXMLUtils is fairly straightforward. An original ColdSpring XML file might contain an element like this:

Using this CFC, you could make part or all of the class name dynamic, like this:

You would then define a data structure to map the dynamic properties to the values that you want:



dynamicProperties = StructNew();
dynamicProperties.servicePackage = "myapp.components.services";

Then simply use this CFC to create the bean factory like this:

This component will replace any matching dynamic properties in the XML, create the bean factory, and return it for you to use! I've added this component to the zip file and SVN repository at RIAForge. I hope folks find it useful!

BeanInjector Update (now at RIAForge!) and ColdMock update

Wed, 12 Mar 2008 15:02:00 -0700

I've updated the BeanInjector component and have created an RIAForge project to host these until we can figure out where these will live in the ColdSpring repository. The ColdSpring Bean Utilities project is at http://coldspringutils.riaforge.org/. It includes the BeanInjector and TDOBeanInjectorObserver, as well as the AbstractMetadataAwareAdvice, VOConverterAdvice, and GenericVOConverter. A zip file and Subversion access are available at RIAForge. There is an update to the BeanInjector specifically. Bob Silverberg noticed a non-var-scoped variable during the initial caching of the metadata for the target object. This shouldn't actually affect anyone since the code lives in an exclusive lock, but better safe than sorry. Thanks Bob! There's also a small update to ColdMock. You can now pass an optional argument named "isVirtualMethod" when you define a mock method. By default this is false, but if you specify true, ColdMock will skip all checks for the existence of the method, as well as argument and return type checks. This is useful if you want to mock a method that is injected dynamically into the component, since the metadata for the object will have no information on the dynamic method. So basically, you can define what the method will return, but you're on your own as far as making sure it is accepting and returning the proper types. I hope folks find these useful!

Unit Testing Transfer Decorators with CFCUnit, BeanInjector, and ColdMock

Mon, 28 Jan 2008 12:18:00 -0700

Paul Marcotte asked me to post about how one might unit test a Transfer Decorator. So here you go Paul (and anyone else who might be interested) :-) . To start with, basic testing of a Transfer Decorator is really no different than testing any other component. First, I set up a ColdSpring file to use for the test. Note that, depending on how many things you need to test and what you're testing, you can use the same ColdSpring file to test numerous things. In other words, you don't necessarily have to have a separate ColdSpring XML file for every test.



	
	
	   /tests/transfer/testing/datasource.xml
	   /tests/transfer/testing/transfer.xml
	   /tests/transfer/testing/definitions

From here, the unit test might look like this (I'm using CFCUnit but the approach in CFUnit would be similar):

As you can see, you grab the Decorator from Transfer, and then are free to test the methods in the Decorator the same way you would test any other CFC method. To take this further, you can actually mix a number of the techniques that I've talked about to handle more complex tests. In this example, I'm using the TDOBeanInjectorObserver to wire in a ValidatorFactory to my Decorator. However, to keep the test isolated to the Decorator, I'm using ColdMock to create a mock of the ValidatorFactory and injecting that into the Decorator:



	
	
	   /tests/transfer/testing/datasource.xml
	   /tests/transfer/testing/transfer.xml
	   /tests/transfer/testing/definitions
	
	
	

	
	
	
		
			tests.transfer.testing.ValidatorFactory
		
	
	
	
	
		false

This way, I can test any methods in the Decorator that actually rely on the ValidatorFactory by mocking the results from the ValidatorFactory method calls:

Just for reference, the Decorator I'm using in these test examples looks like this:

Hopefully that helps clear up how one might go about testing a Transfer Decorator. It also shows how you can use unit testing, ColdMock, and the Transfer Bean Injector together. Please let me know what you think or if you have any questions or comments about how I'm doing this.