Two issue we ran into while building our first hefty application using Mach-II dealt with the config file. Every time we would commit our days' work into SVN, whoever committed second got to play conflict resolution with the config file, because it really is just one place that all work revolves around. The other issue was that the config file was getting larger by the day, with 18 listeners, 97 views, and over 170 event handlers. Every new module worked on brought the count up higher. While 1000+ lines of code isn't the biggest single page I've worked in, I think most of us can agree that it gets harder to navigate at that size.
We'd wondered before if there was some way to break up the config file some to help ease the size, navigatability (is that a word?), and help lower the conflicts during our commits. We kinda looked around when we first start working with Mach-II, but never found an answer, but its been in the back of our minds. This month, we started work on the second hefty app that will use Mach-II, and unlike number one, it will have three developers working simultaneously on it rather than just two. Yeah…conflict city!
So I did careful Google searching and finally stumbled on the answer: as of v1.6, Mach-II does indeed have a way to break up your config file: includes. With the includes, you can include any number of XML config files, and even better, they do not conflict with each other. So something like this would go in your main config file:
<includes>
<include file="/config/moduleOne.xml" override="false" />
<include file="/config/moduleTwo.xml" override="false" />
<include file="/config/moduleThree.xml" override="false" />
</includes>
Each of those XML config files can have their own listeners, event-handlers, views, etc, so you can break up your application by model/module, or if you want you can just break it up by item type (so all views in one config, etc). We decided on the former as it really made it easy to practically end the conficts when committing. When doing the individual config files, the most important thing to remember is that, regardless of what else you decide to include in it, it MUST have the basic wrapper for a Mach-II config file (and of course be valid XML overall):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mach-ii PUBLIC "-//Mach-II//DTD Mach-II Configuration 1.6.0//EN"
"http://www.mach-ii.com/dtds/mach-ii_1_6_0.dtd">
<mach-ii version="1.6"> <!-- your stuff here --> </mach-ii>
In our case, we decided to just do the event handlers and page views in our individual configs, and leave the listeners in the main file, since they were still a fairly small list and generally a one time deal – add a new module, you add its listener and done. It is the event handlers and page views that tend to change constantly while a module is being built. The only time we might have a conflict now is when we add a new config to the include list, or a new listener, but for our day to day work, it has practically ended the conflicts with the config. So if you too have found your config getting unwieldy and the conflicts growing at commit time, take a look at spending a few minutes to break it all down into nice, digestable XML chunks. I suspect you will agree, its worth it.