I'm going to outline five things, and would really appreciate comments:

<ol>
<li>Why I've decided to make the change to ColdSpring dependency</li>
<li>What it means on a technical level</li>
<li>What benefits it brings</li>
<li>What the tradeoffs are</li>
<li>Backwards-compatibility issues</li>
</ol>

<strong>1.  Why I've decided to make the change to ColdSpring dependency</strong>

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 &lt;controllers&gt; and &lt;event-handlers&gt;.

<strong>2.  What it means on a technical level</strong>

A "pure" Model-Glue 2.0 application (one that wasn't upgraded from 1.x), will have no &lt;config&gt; block in its ModelGlue.xml file.  Instead, there will be two .xml files:  

<dl>
  <dt>ModelGlue.xml</dt>
  <dd>Contains &lt;controllers&gt; and &lt;event-handlers&gt; blocks</dd>
  <dt>Configuration.xml</dt>
  <dd>A ColdSpring file containing what used to be in the &lt;config&gt; 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</dd>
</dl>

<strong>3.  What benefits it brings</strong>

I wouldn't implement another layer of complexity unless I felt there were some very strong benefits.

<ol>
<li>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.</li>
<li>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.</li>
<li>Begrudgingly, your ModelGlue.xml file can be split up thanks to a new root-level &lt;include&gt; tag.  Too many people have asked for this for me to ignore it.  You can now have a structure that looks like this:

<div class="code"><FONT COLOR=GRAY><I>&lt;!-- ModelGlue.xml --&gt;</I></FONT><br>
<FONT COLOR=NAVY>&lt;modelglue&gt;</FONT><br>
  <FONT COLOR=NAVY><FONT COLOR=FF8000>&lt;include template=<FONT COLOR=BLUE>"ContactManagerModule.xml"</FONT> /&gt;</FONT></FONT><br>
  <FONT COLOR=NAVY><FONT COLOR=FF8000>&lt;include template=<FONT COLOR=BLUE>"MessageBoardModule.xml"</FONT> /&gt;</FONT></FONT><br>
<FONT COLOR=NAVY>&lt;/modelglue&gt;</FONT><br>
<br>
<FONT COLOR=GRAY><I>&lt;!-- ContactManagerModule.xml --&gt;</I></FONT><br>
<FONT COLOR=NAVY>&lt;modelglue&gt;</FONT><br>
  &lt;controllers&gt;<br>
    <FONT COLOR=GRAY><I>&lt;!-- ContactManager Controllers --&gt;</I></FONT><br>
  &lt;/controller&gt;<br>
  <FONT COLOR=NAVY>&lt;event-handlers&gt;</FONT><br>
    <FONT COLOR=GRAY><I>&lt;!-- ContactManager Event Handlers --&gt;</I></FONT><br>
  <FONT COLOR=NAVY>&lt;/event-handlers&gt;</FONT><br>
<FONT COLOR=NAVY>&lt;/modelglue&gt;</FONT><br>
<br>
<FONT COLOR=GRAY><I>&lt;!-- MessageBoardModule.xml --&gt;</I></FONT><br>
<FONT COLOR=NAVY>&lt;modelglue&gt;</FONT><br>
  &lt;controllers&gt;<br>
    <FONT COLOR=GRAY><I>&lt;!-- MessageBoard Controllers --&gt;</I></FONT><br>
  &lt;/controller&gt;<br>
  <FONT COLOR=NAVY>&lt;event-handlers&gt;</FONT><br>
    <FONT COLOR=GRAY><I>&lt;!-- MessageBoard Event Handlers --&gt;</I></FONT><br>
  <FONT COLOR=NAVY>&lt;/event-handlers&gt;</FONT><br>
<FONT COLOR=NAVY>&lt;/modelglue&gt;</FONT></div>
</ol>

<strong>4.  What the tradeoffs are</strong>

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:

<div class="code">&lt;config&gt;<br>
  <FONT COLOR=NAVY><FONT COLOR=FF8000>&lt;setting name=<FONT COLOR=BLUE>"viewMappings"</FONT> value=<FONT COLOR=BLUE>"/unitysamples/contactmanager/views"</FONT> /&gt;</FONT></FONT><br>
&lt;/config&gt;</div>

You edit this in Configuration.xml:

<div class="code"><FONT COLOR=NAVY>&lt;bean id=<FONT COLOR=BLUE>"modelGlueConfiguration"</FONT> class=<FONT COLOR=BLUE>"modelglue.unity.framework.ModelGlueConfiguration"</FONT>&gt;</FONT><br>
    <FONT COLOR=NAVY>&lt;property name=<FONT COLOR=BLUE>"viewMappings"</FONT>&gt;</FONT><FONT COLOR=NAVY>&lt;value&gt;</FONT>/unityapplicationtemplate/views<FONT COLOR=NAVY>&lt;/value&gt;</FONT><FONT COLOR=NAVY>&lt;/property&gt;</FONT><br>
<FONT COLOR=NAVY>&lt;/bean&gt;</FONT></div>

I figured this was a fair trade for the additional power it brings.

<strong>5.  Backwards-compatibility issues</strong>

To maintain backwards compatibility, I've left support for the &lt;config&gt; 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 &lt;config&gt; block.



Thoughts, opinions?