Finally, something I feel is worth blogging... I've started reading mailing lists again and I realized that most of my good blog posts came as responses to questions on lists!!! Who knew? Maybe I'll start doing a regular Best of Lists Roundup or something... who knows. For now, I want to address a question that came up recently on the ModelGlue main mailing list:
"Should I go with MG 1.x to start with because it's stable, or should I dive right in and start using Unity right off the bat?"
I want to start my answer by saying that Unity actually simplifies things in some places, alters a couple things here and there, but functionally speaking it's virtually no different than 1.x, so if you're thinking you're going to see much difference from going with Unity vs. 1.x, you might be disappointed. ;) To my way of thinking, Unity's best features are mostly small changes that speed it up and make development even easier than before...
A significant addition is the availability of "actionpack" extensions, which are basically <include />-able sets of XML configs, templates and controllers that give you the ability to built portable application components or even subcomponents. Think of being able to <include /> your whole security system into an application with one tag. Yeah, that's an incredible change... you can write your own or download ones that others have written (more on that sometimes soon!) Unity also (obviously) introduces the <include /> tag in this new context (outside the result tag) as part of this addition... which is awesome for sharing common event-handlers, view templates, and controller setups between applications.
Combined with the fact that the application config and the controller/event-handler sections are now broken into separate XML files (which can make handling your XML files much easier), you can suddenly solve a large number of deployment issues. Think of it this way: you slightly modify index.cfm to first detect the server platform, then grab the appropriate config file (so paths and so on are correct), but you never have to change out the file containing your controller and event-handler tags... where before you actually had to maintain separate versions of the whole config file for this to work... that might be an edge case, but it's a very, very nice change for someone who works on OSX but provides CF services to people running Windows.
The Really Big News Nobody Told You
Next up, one of Unity's biggest and most important additions (and one of the least talked about so far) is the addition of extendable built-in events... like onRequestStart, End, and QueueComplete broadcasts, Unity adds ModelGlue.onRequestNnnn events as well, so you can automate some of the things that need to happen at the beginning and end of requests without having to rely on the order in which controller broadcasts fire. It's an important distinction because things like authentication, role checking, some validation, etc., all have to happen in a fairly controlled order. By adding something like the following to your modelglue.xml file, you can replace all that tiered event handling I tutorialized about last year with about 8 lines of XML:
So as you add broadcasts to the above extended version of the built-in ModelGlue.onRequestStart event, you can add various tasks and be guaranteed that your results will be handled appropriately, your broadcasts will happen in the expected order, etc.
That's huge, because instead of 3 tiers of events you have one, with conditional preproccessing that can redirect flow based on results... this lightens your XML in a big way and makes your app much more manageable.
Full-Stack or Not To Stack?
Also, MG:U should be very close to 100% backward compatible with MG 1.x, though I strongly recommend MG:U over 1.x because Unity introduces some things (like the global preprocess event I talk about above) that dramatically simplify life and your XML (and, frankly, the way you create and use your controllers)... if you really want input, I really recommend Unity.
But How Fast Is It?
Unity has also been stripped of all the returntype and type attributes on the appropriate ColdFusion tags... while that's not always recommended for code you're writing that NEEDS validation (it's not always bad, either... try it either way and see what YOU come up with), for a framework, where the code does NOT change and is rigorously tested against typing issues, it was a tremendous performance boost to MG. Think of a supercharged car, or afterburners on a jet. It pretty much tripled the speed of the framework AND cut down on CPU and memory usage... very big deal indeed. It's also sporting a new "resource pool" that keeps 20 or so pre-instantiated event objects on hand and actually tracks hits against the application to increase that if needed... which means that new event objects are only read from disk when needed. Another horsepower boost. So yeah, Unity has some significant advantages over 1.x, especially for high-availability enterprise applications.
Is it stable?
As far as stable vs 1.x vs unstable, Unity has pretty much reached a stable version... I haven't heard of any major bugs lately and I haven't seen any updates hit the SVN repo in quite a while... so there isn't really an unstable version of it. Yeah, it's pre-release and if you can't deploy in that case then you'll have to use 1.x for now, but I strongly recommend that you start with Unity if at all possible.
Laterz!