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.