IoC Update

I spent most of my weekend working on the new IoC Manager and tweaking some issues with the new lazy libraries, mostly with regard to the xhtml libraries, although there was some time in there spent cleaning up the docs because I created a <cf_doc> tag to make documenting the libraries easier and then I realized that I had a bunch of escaped hashes that didn't need escaping, so the docs were all full of ## instead of # for default values. I had already removed the jso library because for the most part the only functions in it that were ever really used were jso.location and jso.object. And for the docs for all three of the custom tags, function libraries and CFCs I tweaked the documentation info so that it's based on an extremely simple xml packet.

None of those things were really necessary, I just figured as long as I was doing another overhaul I may as well clean up some of these things that were "laying around" so to speak.

The latest version is coming along quite nicely. The new config.cfc that replaces the previous _appsettings.cfm I think is a really good idea. You can think of config.cfc as being sort of a replacement for Application.cfc, since it gives you the ability to tweak any given part of the framework core which includes handling for many of the CF Application framework features like adding mappings.

The way it works will also eliminate even the *possibility* of running into the pain-in-the-neck situation that all 3 of the ColdFusion community's most popular frameworks run into with regard to wanting multiple copies of the framework on a given server. Fusebox, Mach-II and Model-Glue all want you to write an Application.cfc they include in their app skeletons that extends a component in their core libraries. That's always struck me as a poor convention and it causes problems any time you want multiple copies of one of those frameworks on your server. The onTap framework gives you the same kind of control, but because it doesn't use the convention of deriving Application.cfc from an external source, you never run into that problem. :)

I also discovered a way, using my method for dynamically extending components (which is impossible by the way), to set up the application so that you can use webservices in the root directory with the same Application.cfc in spite of the fact that it has an onRequest() method (which is also impossible by the way). :)

But getting back to the IoC Manager... I haven't released it yet of course because although I think the Manager itself is ready, I'm still updating the Members onTap plugin. I'm redrafting some of the internals of that plugin to use its own IoC Container and to reference an IoC container from the DataFaucet plugin to get its datasource. And configuring IoC containers is pretty simple. You just create a tiny little cfc in the /_ioc directory like this:

The loadAfter() method lets you specify that your particular IoC config needs info from another IoC config before it can load. I'm not sure if I actually needed the DataFaucet container loaded before my container since they both lazy-load their objects, but knowing that my app uses DataFaucet, I figured it would be "better safe than sorry" to do it that way.