yet another coldfusion blog

It's been about a week since I attended the Mura CMS training seminars, and my brain is still numb from all the new stuff packed into it.  I only managed to catch the "Back-End Developer" portion of the series (there is also an admin/user and front end development seminar), but after my experience I'll definitely be following up with those two sessions as well.  The developer session was presented by Matt Levine, chief architect and developer of the Mura CMS.

I consider myself a pretty experienced Mura developer, so I wasn't expecting too many huge revelations.  I was pleasantly surprised to find a few, as I was at the constant flow of "ah ha" and "so that's how" insights the sessions provided.  The fact that it combined both lecture and lab material really sank home the material and left plenty of examples in my Mura test site to play with.

Matt starts by stepping through the file tree of Mura, then leads into an introduction of the Mura Event model.  This is something that has matured greatly over the past few years, evolving from simple architecture into an integral and fantastically important part of Mura development.

Next up was the 'life-cycle' tour of the front end.  This was a sort of hand-held walk through by Matt of the process from page request to content display.  There are a fair number of stops along the way, with many 'handler' and 'renderer' events fired in sequence.  This was always a bit 'black box' for me, but the tour gave a good impression of how these events not only work but can be used, intercepted and added to when developing applications on top of Mura.  The fact that I wrote "Rethink, Rewrite" on the page opposite the flow diagram (and circled it several times) is an indication of how big an impact this tour made.

This was followed by an introduction to the Mura Scope.  Wow.  The Mura Scope is the Swiss Army Knife of Mura development, providing instant and contextual access to many of the most important API and data components of the CMS.  Being able to simply call $.currentUser('userID') or $.currentUser.isSuperUser() gives devs a huge boost to productivity, and centralizes all of the calls that in the olden days were made to application-scope managers or manually instantiated beans.  The Mura Scope includes among its arsenal the user, content, site, feed, and iterators ... plus a lot more.

Next on the agenda was some of the lower-level access points for Mura development.  This included an exploration of the contentRender, eventHandler, and resource bundles.

That was Day 1.  

Day 2 started with the Class Extension Manager.  I've always felt the CEM was a tool that's easy to both under- and over-utilize.  Under-utilization means that a developer creates a lot more work for themselves by coding in functionality (i.e. extending pages or users) that already exists, while over-utilization comes where functionality would be a lot more easily managed in a controlled and more readily available interface.  I also feel the CEM is also *not* a tool for end users, at least not as far as managing the framework is concerned. One very revealing tidbit of information was that you can use the [mura] tag in the drop down option/value boxes to dynamically populate the values.  Huge!  Some day I (and I think even Matt) hope to replace this with our GUI Form Builder tool, but that's a ways off yet.

Finally came the bit I was waiting (im)patiently for: plugins!  I love Mura plugins; they are just so darn fun to write, fantastically flexible/powerful, and integrate so well into the Mura API playground.  Barely a year old in the Mura CMS ecosystem, the plugin infrastructure has matured into a very sophisticated hook into the Mura life cycle, especially with the latest developments (Mura Scope, Events and the FW/1 connector).  The looser bolts (i.e. request scope usage) have all been tightened, and some more sophisticated API tools (i.e. auto-wiring via pluginApplication) have really improved the performance and reliability of plugins.  Matt's session on this topic covered everything from installation process to the finer points of Event interception and display objects. My favorite bit (if only because I hounded him for months to build it into Mura) was the fact that display objects can now act not only as flat renderers but act as object containers for dynamic lists of displays.  I've promised him a blog on this topic, and I'll try and get to that as soon as possible (hopefully before but likely after cfUnited).

Regardless of your skill level, if you are developing Mura extensions these courses are a must.  BRI has put a lot of work into the documentation of Mura recently, and their training course is a fantastic evolution of that effort. The insights on the API, life cycle, Mura Scope and event flow it offers are invaluable, and will translate directly into better code, tighter integration and far greater development efficiency. As my colleague Colin pointed out, we can now put away the flashlights. As always, I highly recommend that you read the Mura development document before beginning any Mura development project.

In closing, let me say that as always I was really impressed with the Blue River Interactive team (aka the company that created Mura).  They are a group of genuine and hard working guys, very approachable, and sincere in their effort to help people of all skill levels improve their Mura experience.  Matt, Sean, Ryan and Malcolm: thanks for a great experience (and to Eddie, Will and the rest of the Mura team ... good job guys!).