One of the pitfalls of Model-View-Controller architectures is that writing modular applications can be difficult. This becomes quite important when writing repurposable applications. Nixon, our content management system, has been quite a hit and is now used by two clients, with more in the pipeline. Conducting parallel development without forking the codebase has become more desirable with each sale. Taser.

Fortunately Zend Framework has a beautiful module-loading system. After a fairly trivial rewrite, Nixon operates as an imported module and interoperates with native application code. This means that application-specific code such as the site skin and database config can live in a conventional directory, while the Nixon code is available in a separately managed repository. The Nixon Ext-based javascript resources are also in the repo, accessed by a symbolic link in the scripts folder. Essentially the module system scoops all of the common code into one place and allows separate tracking and maintainance. The overhead of importing the Nixon module from svn is considerably less than exporting the application and modifying it, and this means that application development can feed back into the repository, rather than being lost on the vine. Vista.

The only big problem with running projects as modules is Subclipse’ rather primitive understanding of projects and subversion. Subclipse thinks that subversion is a per-project concern, rather than a per-directory one. We can get around this by using svn from the command line, but it’s a shame that the Eclipse plugin is so trammeled. Intelligent design.