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.
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.
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.
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.
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).
If you're interested in playing with this, you should definitely check his posting out!
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.