When I realized my concept for a ServiceLocator fell in the category of "interesting patterns you'll never use", I decided instead to work in a <mixin/> tag for LightWire. The tag is a child of <bean/> like <constructor-arg/> or <property/>. Children of <mixin/> <value/>, <ref/>, <map/>, or <bean/> defined therein will be "mixed in" rather than constructor or setter injected.
Over the past month, I've worked on some projects that required special data handling and calculated values. I considered using Peter Bell's Iterating Business Object, but instead decided to build an Iterator that can be composed into my domain objects. I'm a big fan of using "composition over inheritance", so I saw this as a prefect opportunity to add iteration to my domain objects with a minimum impact.
As a follow-up to Peter Bell's "LightWire or ColdSpring?" entry, I'm happy to announce that LightWire now supports XML configuration using ColdSrping XML bean definitions.
With the current release (0.65), you can set your object dependencies with xml, programatically, or a mix of both. This feature supports recursion, factories and optional default settings...
I see a lot of discussions centered around application configuration and the merits of different implementations. Of these, XML cofiguraiton is the most pervasive. A suggested best practice when using xml config files is to keep them outside of the web root to prevent exposing key settings. After recently installing Raymond Camden's Lighthouse Pro, I learned that you can also obfuscate the xml inside a comment block. To try and understand this clever workaround, I openend the hood (a.k.a Appplicaiton.cfc) and noted that with a very small change in onApplicationStart I could introduce both an IoC/DI container and swap out the xml for a programatic config using Peter Bell's LightWire.
