While I can't imagine any non-trivial OO project that I wouldn't use dependency injection for, there are specific tasks within a project that don't necessarily need DI. Someone asked me a question earlier today which raised a good point when getting comfortable with DI - the difference between a dependency and a runtime bean request . . .

[More]

I just had a use case where I needed the ability to call a custom init() method after fully initializing a bean but before returning it from LightWire (I needed a config method for my #BusinessObjectName#Metadata config beans to automagically add any config properties I hadn't explicitly set for an object). In the past I'd just called super.config() at the end of the init() method, but that didn't allow for metadata inheritance (if you called MyUserMetadata that extended UserMetadata config would get called twice and it'd get nasty). So, I have officially added support for an InitMethod property to the addSingleton(), addTransient() and addBean() config methods. This has not been added to the ColdSpring XML reader, but I'll have a word with Paul and wouldn't be surprised if this got done soon. For now I've just updated the LightWire svn repo for anyone in a rush to use the feature :->

To the few, the trusty who sat through almost 40 minutes of technical issues, many thanks for hanging in there :->

After resolving sound, screen sharing and connectivity issues, we finally gave up the ghost when my Internet went down hard for almost 10 minutes.

The preso will be rescheduled, and the preso will be fully debugged so it should be nice and smooth next time. I'll post the new time when I get confirmation from Nick.

Here is a link to the connect room for the LightWire Preso at 2pm EST today: https://admin.adobe.acrobat.com/_a200985228/pbonlightwire/.

If you want to review the benefits of Dependency Injection or see how programmatic configuration, mixin injection and perhaps even "ghetto annotations" can hep you to develop quicker, more agile OO apps, come along and check it out.

Thanks Nick!

More information . . .

If you're interested in finding out more about how LightWire works, check out the Preso tomorrow at 2pm EST put together by the CF Frameworks crew.

I'll provide a brief overview of DI/IoC, but this will really be focused on how LightWire works (including ColdSpring XML support) and the use cases I've found for programmatic config files, Mixin injection and "Ghetto annotations". If you'd like to learn more about alternative approaches to Dependency Injection in the ColdFusion world and how they can support more rapid development for certain use cases, it should be an hour well spent.

Paul Marcotte found a subtle bug in LightWire (thanks Paul!) which would cause problems if you were lazy loading transients as constructor arguments for other beans. Please upgrade to 0.66. No API or functionality changes from previous version - just the bug fix.

ZIP file and svn repo both updated.

I was looking at Google Guice a little while back but for my use case I preferred having a central config file so I could see all of the key object relationships in one place and use the programmatic config features in LightWire so if I needed to include a DAO in every business object I could easily do that without having to change my config file when I added a few new business object.

However, I started to come across a few cases where the central config file felt like a hack. I have a set of "feature" controllers and each needs to speak to some (but not all) of the object controllers. The Catalog controller needs to speak to ProductController and CategoryController. The Administrator controller needs to speak to all of the controllers. The PageDisplay feature doesn't need to speak to ANY object controllers and so on.

The problem is that for different projects I'll have a different set of "feature" controllers so I need to gen a snippet of my bean config file with all of the custom dependencies that are feature dependent. I started down that road, but it really felt a little hacky. While I want a central bean config to associate every business object and business object service method with its DAO programmatically, I really didn't need the "unique" stuff like the fact that this feature depends on those object controllers to be in that config file.

So, a while ago I added a simple hack to implement the core intent of Guice annotations (that beans be self describing in terms of their dependencies). The implementation was much less powerful and sophisticated than Guices approach, but the basic concept of a bean being able to say "don't forget I depend on X and Y" without using auto-wiring (which I don't love for a number of reasons) worked really well. Now my feature controllers tend to say what object controllers they require and I find the combination of in-bean definitions and a central programmatic config really gives a lot of power for RAD.

Shows how locked I was that I didn't even blog about my own preso :-<

Nick and Kola were good enough to invite me to do a preso on LightWire, so if you want to find an alternative way to manage manage the relationships between your beans, check it out (call for questions only - the preso is next week).

Paul just put together a great post on LightWire Configuration Using ColdSpring XML based on the code and sample he contributed to LightWire to allow it to read a ColdSpring XML file.

If you're interested in playing with this, you should definitely check his posting out!

Want to see what it is like to let your bean dictate some of its dependency injections? Try out LightWire 0.62. For now it is just for mixin injections and requires you to add a simple cfset in your init() methos rather than adding true annotations and reading them via getmetadata.

The bottom line is that if you'd like to move some (or all) of your bean definitions into your beans a la Google Guice, 0.62 lets you give it a shot.

I'm looking for feedback on how this should work before I implement it in a more elegant manner, but it's tested and working on my sites, so check it out and let me know what you think!

To add mixin injections (in addition to those described in your central bean config) add the following to your init() method (MUST be in the init() method):

Replacing "UserService,ProductService" with a comma delimited list of bean names you want to inject.