IgniteImage.com is a website for my web design company Ignite Image, which specialises in creating stylish, modern, accessible, functional, professional, exciting and standards compliant websites for bands and musicians. I’m extremely proud of both the aims and objectives of this website and company and the website itself.

We are a small team of four at the moment; there is me, responsible for design & development, another excellent developer, a designer & marketeer and an artists relationship manager.

All four of us are closely involved in the independent music scene, with us all being active musicians and regular gig attendants; on a personal note almost every one of my closest friends are members of active bands. Being us so closely involved with unsigned and independent artists as well as being web developers we have had constant requests to create stylish and functional websites for our friends, on a shoe-string of course.

This has given us lots of experience in the common requirements and problems faced by independent artists wanting to create their first online presence and we want to share this knowledge and expertise with other artists outside our circle of musician associates.

We aim to offer the most competitive pricing and feature set without compromising on quality to artists and musicians who wish to create an exciting and modern web site for themselves.

So why not head over to Ignite Image now to learn more, if you think we could help you out or you just want to learn more then don’t hesitate to contact us.

There have been a few responses over time ranging from "you don't need to" to split it into sub-applications, but just now on the Mach-II Coldfusion Topica list Jon Gunnip has posted an interesting solution to the problem.

The main reason the question of splitting the config file arises seems to be the problems with managing a single config file which is 1000's of lines long. Although this can be a pain, especially if multiple developers share the same code-base without any version control (which we were guilty of until recently), this is not the reason I have been looking for a solution to have a more modularised config file.

What we currently have is about 8 applications which are basically variations on a single application, each will have certain "modules" removed or slightly tweaked for its particular needs, it's not perfect but it is 10,000 times better than the pre-Mach-II "application(s)". On a day to day basis, this works quite well as we don't have to change these that much, however once you start adding or changing features which affect the config file in more than a couple of places, and need to affect every application, it can quickly become messy.

Jon Gunnip's solution, which is derived from a post about entities with model-glue, is basically to use XML entities which can then reference smaller XML files, which will make it act like a single config file, like so:

I think this could be quite useful and for our needs seems to be the best solution suggested so far. It is definitely something to add to my list of things to do at work.

However I still dream of a real module based solution, this something which I've mentioned in a couple of places before. For example, such a solution could allow you to specify a module like so:

You would package a module with all it's requirements, listeners, event-handlers and views (I don't feel that plugins would apply to modules). If you were include two modules which register the same listeners or views then they are only included once. The modules could have some sort of CSS-like cascade where you could then include application specific modules which override certain settings (such as page-views or single event-handlers).

I know that this would be a little complex to instigate, I keep threatening to setup a proof of concept using something like a directory event gateway in Coldfusion to do this, but its an idea that could be worth a further look down the line.

• Fixed spelling mistake that caused PHP notice to be thrown when constants file has no common block.
• Fixed bug whereby absolute paths for constants file would throw "file not found" exception.
• Fixed bug in exception handling which would cause Mach-II to die.

View the Application Constants Mach-II PHP code page for the download and instructions on it’s implementation.

I've not had time to look at it properly yet, but I'm definitely going to make time over the next couple of weeks to begin implementing it in our applications at work. This basically means cleaning up some of the cruft, but I want to implement it because of the following features:

Specifying invokers for listeners is now optional.

Recently I've started using a custom invoker which works like the new EventInvoker, placing the result into event-args. But having a default will remove some weight from the configs and standardise the best practice of using the EventInvoker.

The new EventInvoker and resultArg argument.

As I said, I've started using a custom invoker to avoid using the request scope as a data bus. The new EventInvoker will result in a cleaner leaner config file.

The new contentArg argument.

I have not tried to use event args for content, but I can see that it will be cleaner than using the request scope.

There are of course other bug fixes, tweaks and additions which make the upgrade more than worthwhile. For a look behind the scenes see Matt Woodward's post The making of a Framework, which gives a little insight as to what went on in the build up to the release of 1.1.0.

One thing I'm a little confused about is the "White Screen of Death" bug fix, in the release notes it states:

Mach-II now throws an exception report if the view does not exists instead of showing the "White Screen of Death"

But you in practice I have found it more common that you get the "White Screen of Death" when the view, for example in your site wrapper or the exception view itself, throws an exception, I'll probably post this question on the Mach-II mailing list and find out I'm wrong.

So today I spent a couple of hours re-writing it from scratch to bring it inline with the latest version of Martins. View the Application Constants Mach-II PHP code page for the download and instructions on it's implementation.

As a little side note I hope that the code section of my site will allow me to release other little useful things like this I have kicking around. I've got at least one more Mach-II PHP plugin that I'm going to try and tidy up and release sometime soon.