I'm going to outline five things, and would really appreciate comments:
- Why I've decided to make the change to ColdSpring dependency
- What it means on a technical level
- What benefits it brings
- What the tradeoffs are
- Backwards-compatibility issues
1. Why I've decided to make the change to ColdSpring dependency
As Model-Glue grew, the framework became more and more focused on being a simple way to connect and control HTML views and their interaction with a CFC based business model. Managing configuration isn't something it's good at, but it's something that ColdSpring is very good at. In short, it separates configuration of your application from the Model-Glue system of <controllers> and <event-handlers>.
2. What it means on a technical level
A "pure" Model-Glue 2.0 application (one that wasn't upgraded from 1.x), will have no <config> block in its ModelGlue.xml file. Instead, there will be two .xml files:
- Contains <controllers> and <event-handlers> blocks
- A ColdSpring file containing what used to be in the <config> block, configuration of the framework itself (such as whether to use ColdSpring or ChiliBeans in your application or a custom statebuilder for SES purposes), and any other services you'd like to make available to your application or autowire to your controllers
3. What benefits it brings
I wouldn't implement another layer of complexity unless I felt there were some very strong benefits.
- One ModelGlue.xml can be used by many application instances. I've talked with people who are Application Service Providers using Model-Glue, and one need that sector has is the ability to re-deploy the same application to multiple clients. Separating configuration from ModelGlue.xml means that all they need to do are maintain which client's Configuration.xml file is being loaded, and upgrades/modifications involve changing one ModelGlue.xml file.
- A single point of application configuration. Application services / "Configured Beans" (configBeans) can simply be defined in the Configuration.xml file instead of in many separate files.
- Begrudgingly, your ModelGlue.xml file can be split up thanks to a new root-level <include> tag. Too many people have asked for this for me to ignore it. You can now have a structure that looks like this:<!-- ModelGlue.xml -->
<include template="ContactManagerModule.xml" />
<include template="MessageBoardModule.xml" />
<!-- ContactManagerModule.xml -->
<!-- ContactManager Controllers -->
<!-- ContactManager Event Handlers -->
<!-- MessageBoardModule.xml -->
<!-- MessageBoard Controllers -->
<!-- MessageBoard Event Handlers -->
4. What the tradeoffs are
It's more complicated. Not much, but you've got to edit two files that use two different XML schemas (ModelGlue and ColdSpring). The ColdSpring piece is easy, though. Instead of editing this in ModelGlue.xml:
<setting name="viewMappings" value="/unitysamples/contactmanager/views" />
You edit this in Configuration.xml:
I figured this was a fair trade for the additional power it brings.
5. Backwards-compatibility issues
To maintain backwards compatibility, I've left support for the <config> block in ModelGlue.xml intact (as of an early alpha of the Model-Glue 2.0 core). Basically, it overrides settings in Configuration.xml, so that you can literally drop a ModelGlue 1.x ModelGlue.xml file into a copy of the ModelGlue 2.0 application template and you'll be up and running.
I debated adding this; I'm not sure it's necessary, and I'd really like to encourage people to use ColdSpring instead of continuing to use the <config> block.