Preface

When brought into existing projects in a consulting role, there will often be the perception the project is “mostly done”, or “90% there”.  Opening up the hood, you sigh.  You marvel at the wonders of modern programming technology, how they’ve empowered even the shoddiest, hastily thrown together, duct taped to work and work well, fooling many into a sense of functional complacency.  You also wonder when, not if, it’ll explode in someone’s face.

This is a great series about how to be not just a good software developer consultant but also how to manage exceptions and prevent disaster as a regular software developer.

Ah, ColdSpring. In my opinion, you're the bees' knees. You're what makes managing object dependencies a breeze. You simplify and enable the development of object-oriented ColdFusion apps so much that you're core to most large-scale ColdFusion applications written in the last couple of years. The teams behind Mach-II, Model-Glue and ColdBox like you so much that they made you a key player in their framework stacks. I'm not going to sell you on the virtues of ColdSpring any longer, so if you're not using it already, start please.

We are luckily to have such a great community around Mach II. In this series Brian Klass talks about module support, one of Mach II's unique features. If you are building large applications or applications that have parts that need to be shared with other applications take a look at the modules feature.

In the above article Brian goes into detail on how you can configure ColdSpring's hierarchal bean factories to work well with Mach II's module support. This is great for situations where you have some shared services you want to make available across all your applications. Then you can have each Mach II app pull in those shared services via the application scope. This also works well when you have a base Mach II module that needs to share is services with their child modules as Brian describes.