My simple item management application started out with nothing more than these three regions on the screen:
Once this was in place, though, a new requirement came along… a complex search with search results. To implement this, I needed to modify the application’s interface to swap the grid and add/edit form out and put in a search results screen instead. The idea is that when the user does a search, the main content area will show the search results. The user can then go back to the location management aspect of the app whenever they need to. After a bit of searching, I found a high level pattern that made this easy, and also realized that I had previously implemented the core of this pattern without knowing it.
Microsoft Prism: Regions and Region Managers
Several years ago, Microsoft released a framework for it’s WPF and Silverlight runtimes, called Prism. This was essentially the big composite app framework that people used to build well structured and decoupled apps in XAML. I never had a chance to use this framework directly, but I worked with a team of developers that did use it.
One of the things that I liked about what I saw in Prism was the way it used the idea of “regions” and “region managers” to compose the user interface. The gist of it is that you could define a visible area of the screen and build out the most basic layout for it without knowing what content was going to be displayed in it at runtime. Then at runtime, your application modules could register themselves to have content displayed in the various regions of the screen.
A Simple Region Manager
- Represent an existing DOM node
- Change out the contents of that DOM node
- Call any required rendering and initialization for content views that will be displayed
- Call any required cleanup for content views when they are removed
What I came up with as an initial pass at handling these needs, is the following (hard coded specifically to use a “#mainregion” element from the DOM):
Does that look familiar? It certainly does to me. I’ve written this same code dozens of times and blogged about it in my Zombies! RUN! post. So, it turns out that I’ve been using what I’m now calling a “region manager” for a while – I just didn’t realize it, previously. Oh, happy day! I’m just formalizing a concept I had introduced somewhere else, instead of having to create something new and unknown. :)
Using The Region Manager
An in-depth use of the region manager has been covered in my Zombies post already. As a refresher, though, you only need to provide a Backbone view to the `show` method and the region manager will take over from there.
The usual `close` method exists so we can handle our zombie problems. I’ve also added a bit more to the API that the region manager can handle, making it more robust and allowing it to handle more complex UI needs. Specifically, an `onShow` method fires on your view if you’ve provided one, just after the view’s `el` has been added to the DOM. This method will let you call into code that expects the DOM elements to exist, to manipulate them.
But Wait! There’s More!
Well, maybe there isn’t anything more at this point in time. But there will be soon. As I’m traveling down the composite application path, I’m starting to extract the useful bits into a library so that I don’t have to rebuild the same things over and over again. If you’re interested in watching this grow over time, checkout my Backbone.Marionette repository on Github. It’s nearly empty at the time of writing this blog post, as it’s a work in progress. I plan on making a large announcement about it when I have more to share, sometime in the future.