In my last post, I discussed some of the mistakes that can be made when using ColdSpring as our factory. It became evident that using ColdSpring to inject transient objects—that is, objects that have a state for a momentary use and then are discarded—into our service objects or other related singletons is problematic. This is largely due to the concurrency issue with reusing that injected bean in the service object's methods, and mistakes that can be made if we forget about objects being passed by reference. Ray Camden also discussed this recently in ColdFusion and Pass by Reference versus Value.

The answer is to build a transient factory for those beans. We can do it without losing the benefits of ColdSpring's dependency and configuration management. And it doesn't take much to make a factory. Take a look at this sample that works with my previous post's code.

The factory has a setConfig() method, just like the Bean does, and can be used to conveniently inject all configuration information with ColdSpring. Now, let's look at the createBean() method where the action is. It performs 3 key actions: (a) Create a fresh object. (b) Pass in configuration. (c) Call the init() method and return the object.

Our ColdSpring file can now be rewritten like this:

See, we use the same XML for injecting configuration, it's just injected it into BeanFactory. We then inject BeanFactory into BeanService, instead of the Bean itself. It can use the factory to get a fresh bean whenever it needs one—properly instantiated and configured.

An example of BeanService tweaked to accept and use the factory:

Let's make the factory better. First, your app probably has more than one type of transient object. You don't need a separate transient factory for each type of object. Just have a different createBeanName() method for each object type, with creation code specific for each object. And if your objects are all essentially created with the same conventions, you can handle create methods for all of them with a single onMissingMethod handler. Something like this:

See how the first if statement checks to make sure the method is a valid method name: One that starts with "create" and ends with an acceptable class name as we define in our classList variable. So this onMissingMethod handler will work with createMyBean(), createDiffBean(), and createAnotherBean(). Note how it also checks for the existence of a setFactory() method in the object it creates. If it is there, it will use the method to inject itself into the new object! This is a simple example of how autowiring is accomplished.

Take it even further! Head over to Paul Marcotte's blog post, A Coldfusion Transient Factory Example, which shows how to make a very generic transient factory that receives configuration on which classes it should create through ColdSpring. Very cool stuff.

Review. Transient factories don't require a lot of code, and are a vital step to simplifying and centralizing our instantiation and configuration of transient objects, or objects that have a state. Doing so doesn't negate the need for ColdSpring, in fact it complements it as it was intended, since ColdSpring works well with instantiation of singletons, and transient factories as described here are used as singletons. By utilizing ColdSpring and a transient factory, we can be well on our way to cleaner and more organized development.

Get the files. Download sample code to play with: ColdSpring Bean Test. It walks us through the issues discussed in the previous post as well as using transient factories like we just discussed.

This post has gotten pretty long, so I'll save the race condition demonstration for "Part 3".

As ColdFusion developers progress in the use of object oriented programming concepts with CFCs, our applications become more flexible and able to support additional interfaces such as Ajax or Flex through web services. We also potentially benefit just from overall code maintainability, extensibility, and reusability by using best practices and design patterns common in OOP.

The benefits are many, but there are certainly pitfalls along the way. Perhaps we're ready to begin using service objects. And we'd like to create and pass in our transient objects with ColdSpring as a factory for all objects.

Let's cover the groundwork of our example, and then consider a pitfall. Here's our transient object:

Bean.cfc

This is an overly-simplified example of a bean. It just has 3 properties (X, Y, Z) and corresponding setter methods. It also has a typical init() method, a setConfig() method to pass in configuration, and a getter method so we can quickly dump the state of the object. It'll be enough for our samples.

Perhaps we might write a ColdSpring configuration like this:

This seems like it should work, eh? We're instantiating a service object, instantiating and configuring a bean, and passing the bean into the service object. Here's a really simple example of the bean service object:

BeanService.cfc

This BeanService object has a constructor that receives the bean and stores it in its variables scope. It then has a the getBean() method so we can see the bean, and a workWithBean() method that simulates doing some work with the bean.

And now, the pitfall: ColdSpring singletons and objects passed by reference.

This code technically runs, and appears fine: The Bean instance that we pass into the service is not a singleton, so each BeanService we instantiate (if we were to instantiate multiple) would have a separate Bean instance. And workWithBean() appears to use a local var copy of Bean.

Wrong.

First, the Singleton vs. Transient Objects With ColdSpring page explains that ColdSpring isn't ideal for generating transient components. Its overhead is more appropriate for less frequent creation of components that typically go in a shared scope, such as in the Application scope. Performance aside, though, the approach of injecting a transient bean into a singleton like BeanService does technically work.

So now the second point, how BeanService is working with Bean in our example workWithBean() method. The key misunderstanding is that CFCs like the Bean object are passed by reference when being assigned to variables. So when we do var myBean=variables.Bean, the local myBean variable is pointing to the same copy of Bean that variables.Bean points to. When it executes methods that change the bean's state, the one copy of Bean is being altered. Whoah, that wasn't an intended behavior. This could have very negative consequences, with Bean not being in the state you might expect it to be in.

So, how to fix it? Hmm. I don't want to use CreateObject() because that would become a dependency we'd have to manage, and we'd have to handle properly configuring the bean. This was the whole point of injecting the bean with ColdSpring in the first place.

Well, a quick solution could be to just use Duplicate() to make a copy of the injected bean before working on it! So, we could replace our workWithBean() method with this:

Now, variables.Bean will always be the pristine, original bean injected by ColdSpring, and the local myBean variable will perform its work with a duplicate of that bean. Our code will now be working the way we intended; disaster has been averted.

Well, this does work. But it is neither graceful nor efficient, and it is not recommended. Consider Sean Corfield's blog post, Duplicate() is Bad For Your (Object's) Health. In an informal test, he clocked Duplicate() as being drastically slower—we're talking 50 to 1—than using CreateObject().

Ugh. If we're back to using CreateObject(), what good is using ColdSpring for managing these component relationships, and what about dealing with configuration? Enter the world of factories. Yes, ColdSpring itself is a factory, but it is a factory oriented around creating and configuring our singletons, which can include other factories whose purpose is to properly create transient objects like Bean.

So instead of having ColdSpring inject Bean into BeanService, we can make a BeanFactory and inject that into BeanService, giving BeanService the ability to create Beans to work with any time it needs to. This may seem like a lot of effort, but we'll come to see that creating transient factories is easy and will clean up the mess of an architecture in this sample to something graceful and maintainable.

In this post, I described a few of the mistakes that can be made as we start to utilize ColdSpring. Hopefully these mistakes point to the importance of factories—not just ColdSpring, but our own transient factories as well. In the next blog post, we'll rework the sample to use a factory and review the benefits the factory provides and how it doesn't duplicate the purpose of ColdSpring. We'll review one more scenario that underscores the importance of factories: the dreaded race condition. And I'll provide source code that has executable demonstrations of these undesirable mistakes in action.

I have another blog that I use entirely for my own note-taking and reference, and I very frequently refer to my notes on my iPhone. Safari on the iPhone renders the pages wonderfully, but it is a bit of a pain to have to zoom in on the text of the page. This is when I realized an iPhone-optimized version of the blog would be so nifty.

WPtouch is the best solution for WordPress blogs. It's as simple as a plugin installation, and it is very decently polished.

It renders in "mobile" mode only for iPhone/iPod/Android clients. It has an option for those clients to still view the site in "normal" mode. It uses JQuery for various AJAX and visual effects. It just works and looks good while doing it, and I've recently installed it on this blog as well.

In some environments and scenarios, I used to use initialization (*.ini) files for storing simple configuration settings. Now I typically store this kind of information in a ColdSpring configuration file, or at least in an XML file of some sort. But at times I have to live (and work) with the apps I wrote that use *.ini configuration files.

The nice thing about *.ini files. Not that they're all bad. It's ridiculously easy to extract settings from these files with ColdFusion. For instance:

To retrieve the mysetting configuration setting, I just make one call:

It can't get much easier than that to retrieve a value from a configuration file!

The bad thing about *.ini files. The only problem is that these files are restricted to name=value pairs of simple values. You may go into a project with no need for configuration settings that are any more complicated than simple numbers or strings, but what about 3 years from now when the business logic now could use some structs or arrays in the configuration?

Of course, you could change your whole configuration methodology when--and if--that time comes, but ugh. Using XML (especially in conjunction with IoC such as ColdSpring) is so much more scalable. The future you will thank you.

But it's too late. You and I already have complex app XYZ that is using *.ini config files, and you need to add feature X without rebuilding the configuration logic of the app. What to do?

Embed a string representation of your struct or array in the config file! After all, ColdFusion 8 allows implicit struct and array creation, right? Well, half-right. Doing something like x=Evaluate(myStructString) just isn't allowed by ColdFusion.

However, we can effectively do the same thing with JSON representations of structs and arrays. So, try this:

Now, retrieving mysetting with GetProfileString() will still get you a string, but using JSON functions built into ColdFusion 8 will get you a struct:

Your myStruct variable will be a struct with two keys ("one" and "two") just as you would expect from the JSON.

You could achieve similar results using XmlParse(), but in a case like this, the less verbose, the better. And JSON is less verbose than XML.