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!

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.

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:

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.

I've had some good feedback about the TDOBeanInjectorObserver that I released earlier this week. However, I realized that with a small bit of further effort, I could make the idea even more useful. I had put quite a bit of work and thought into handling the dependency injection and the caching of the dependencies for maximum performance. With this all in place and working, it was only a small step to create a generic BeanInjector component that could be used to autowire any component at all, not just Transfer Decorators! So we now have TDOBeanInjectorObserver v1.1, and BeanInjector v1.0.

From the outside, the TDOBeanInjectorObserver has only changed slightly. The only difference is that you now must pass a BeanInjector property to the TDOBeanInjectorObserver in your ColdSpring XML, like this:

The main difference from the 1.0 version is that you must define a BeanInjector bean, and that you must pass this in as a property to the Observer. The only other change is that if you were using the optional constructor arguments for "suffixList" and "debugMode", these are now specified for the BeanInjector instead of the TDOBeanInjectorObserver.

The real benefit of this doesn't have much effect on the Observer. It is that anyone can now use the BeanInjector to autowire any component. Why is this useful? I'm glad you asked! ;-)

There has always been a performance penalty for managing non-Singleton (aka "transient" or "per-request") beans with ColdSpring. This is because ColdSpring goes through several phases of lookups and dependency resolution when it creates beans. With Singletons, this is never an issue because it only happens once, at application startup. However, the benefits of being able to manage non-Singleton beans with ColdSpring, such as autowiring of dependencies, were still great enough to outweigh the overhead.

Well now we can have the best of both worlds. Using the BeanInjector, you can still have any dependent beans that are managed by ColdSpring autowired into your transient object. But because of the way the BeanInjector caches the dependencies for a given component type, the overhead is virtually eliminated.

A second advantage of using the BeanInjector to autowire your transient objects is that you can maintain control over how your transient object is constructed. When you call getBean() on the ColdSpring BeanFactory, you get back a fully initialized and constructed object. This means that you have very minimal control over how the init() method of your component is called (via constructor arguments in the ColdSpring XML configuration). Using the BeanInjector, you are free to create and call the init() method on your transient objects however you want to, and then autowire them at whatever point in the process you want to.

So for example, consider the following ColdSpring XML:

My UserService may want to create and use a transient User object. That User object might have the following function defined in it:

So now, in my UserService, I can do something like this:

Which will create the User and then autowire it, so that the ValidatorFactory would be injected into it. So this means you could pass dynamic values to the init() method of user if you want to:

Or even that I could create the object, autowire it, and then call init() in cases where my constructor needs to perform logic that requires the bean to be autowired already:

Obviously you have to be careful with this approach since you are not creating and initializing the component in one chained method call, but in many cases where the transient object is local to a function, there is no real chance of the uninitialized object being used by something else before you call init() on it. The point is, the option is there.

In any event, I thought having a BeanInjector like this might be useful to people. Given that most of the work had already been done in the creation of the Transfer Observer, I decided to take the next step and just move that logic into a component that could autowire anything. I'm interested to hear any thoughts on this, so please comment and give your feedback. Thanks.