The title is a mouthful and accurately implies an alarmingly high jargon to code ration, but I just didn’t see anyway to write this post without straying into all of these different subjects. When you try to write an explanatory article you have to walk a tightrope between a sample problem that’s simple enough to work through in no more than a handful of pages and a sample problem that’s just too simplistic to be valuable. I’ll leave it up to you to decide which end of the spectrum this one falls on. I also had a rough time trying to decide on the best way to order the topics in the narrative. All I can do is ask you to scan the following headers if something seems to be missing or I’m lurching ahead.
Last week I had a flood of people follow Martin Fowler’s link into this series. I thought it was pretty cool because most of my UI patterns material and terminology is transparently based on Fowler’s work. I’m especially glad that Martin didn’t mention the fact that I volunteered to help with the UI patterns writing three years ago then disappeared…
If you missed something, here’s the Build your own CAB series in its entirety.
- The Humble Dialog Box
- Supervising Controller
- Passive View
- Presentation Model
- View to Presenter Communication
- Answering some questions
- What’s the Model?
- Assigning Responsibilities in a Model View Presenter Architecture
- Domain Centric Validation with the Notification Pattern
- Unit Testing the UI with NUnitForms
- Event Aggregator
- Rein in runaway events with the “Latch”
- Embedded Controllers with a Dash of DSL
- Managing Menu State with MicroController’s, Command’s, a Layer SuperType, some StructureMap Pixie Dust, and a Dollop of Fluent Interface (This Post)
- Replacing Data Binding with MicroControllers and the Window Driver Pattern – Forthcoming
- Subcutaneous Testing – Forthcoming
- Creating the Application Shell – probably a couple posts
- Wiring the Components with an IoC tool – Forthcoming, but I may push this off into late summer
- A Day in the Life of a Screen
The end is in sight. In traditional developer style I blew the estimate for how long “Build your own CAB” would take. I thought all I needed to do was copy n’paste a bunch of verbiage and code from my DevTeach talks into Live Writer and that would be that – but my usual wordiness kicked in and I ended up submitting a completely new talk to DevTeach Vancouver on this subject.
A couple years ago I remember reading Stephen King say that he always found the Dark Tower books difficult to write as a way of explaining why there was so much lag between new books, much to my exasperation at the time. I’m obviously not Stephen King, and there’s no line of folks wrapped around the corner of CodeBetter waiting for the next installment, but I know how Stephen King felt now. I do promise that the end of this series won’t be as shocking/disappointing/brilliant(?) as the end of the Dark Tower.*
Again, I am not a licensed namer of patterns, and some of the people I’ve shown this code to have commented that it’s reminiscent of Smalltalk UI’s, so it’s a good bet that some of you have already seen or used similar approaches. That said, I use the term “MicroController” to refer to a controller class that directs the behavior of a single UI widget. By itself, a MicroController isn’t really that powerful, but like an army of ants, a group of MicroController’s working cooperatively (with some external direction) can accomplish powerful feats.
Here’s a common scenario:
- You have a menu bar of some sort or another in the top strip of your composite WinForms application
- Each individual menu item needs to fire off a command of some sort (duh)
- The availability of some, but not all, menu items is dependent on user roles. In other words, some menu items will be disabled or hidden if a user does not have a necessary role.
- The availability of some menu items is dependent upon the screen that is currently active in an application with some sort of MDI or tabbed interface
- The menu bar frequently collects new additions as the application grows
There’s nothing in that list that’s particularly hard or even unusual, but I want to explore an alternative approach. Off the top of my head, I’ve got four goals in mind for the design of my menu state management:
- Quickly attach the proper commands and actions to each MenuItem. This can get tricky because each MenuItem potentially touches and interacts with very different pieces of the application.
- Eliminate duplicate grunge coding. I say you pursue any chance to eliminate the mechanical cost, and there’s quite a bit of repetitive functionality here.
- Make the code that specifies the menu behavior as expressive and readable as possible. This code is going to frequently change, so it’s worth our while to make this code readable.
- I want an easy way for each screen to configure the menu state, and I want this menu state calculation and manipulation to be as easy to understand, write, and test as possible.
Much like the screen state machine sample from my last post, I’m going to try to use a Domain Specific Language (DSL) / Fluent Interface to express and define the menu behavior. By hiding the mechanics of menu management behind an abstracted Fluent Interface I’m hoping to compress the code that governs the menu state to a smaller area of the code. I want to be able to understand the menu behavior by scanning a cohesive area of the code. It’s my firm contention that this type of readability simply cannot be accomplished by using the designer to attach bits and pieces of behavior. Leaning on the designer will scatter the behavior of the screen all over the place. One of the main reasons I don’t like to use the designer or wizards is because you often can’t “see” the code and the way it works.
Start with the End in Mind
Before zooming in one the individual components of the solution, let’s keep the man firmly behind the curtain and look at my intended end state. Inside some screen (probably the main Form) is a piece of code that expresses the behavior of the menu items like this fragment below:
private void configureMenus()
And in each individual screen presenter you might see some additional code to set screen-specific menu settings like this that would be called upon activating a different screen:
public class SomeScreenPresenter : IPresenter
public void ConfigureMenu(MenuState state)
So what’s going on here? There isn’t a single call in this code to MenuItem.Enabled or any definition of MenuItem.Click, so it’s safe to assume that there’s somebody behind the curtain. So, what is the man behind the curtain? Before I talk about each piece in detail, here’s a rundown of the various moving parts:
- A small MicroController object for each MenuItem that “knows” when to enable or disable its MenuItem and set up the MenuItem’s Click event.
- A controller class for the menu that aggregates all of the MenuItem controllers. Part of the responsibility of the Fluent Interface configuration code above is to associate a MenuItem with a CommandNames key so we can quickly reference the correct MenuItem’s when a different screen is activated.
- A series of Command pattern classes that all implement a common interface.
- StructureMap is lurking in the background as my IoC tool of choice to wire the various parts together.
- The Fluent Interface configuration API. For the most part, it’s job is to look pretty. All it’s doing is gathering in input values to set on the individual MenuItem controller classes that do the real work. What I’ve found so far is that Fluent Interface strategies seem to lend themselves best to situations like this where you’re really just configuring an object graph to do the real work.
- A MenuState object that is used to transmit the desired state of the menu from the individual screens to the main menu controller
- Each Presenter in the application implements a common interface that includes some sort of hook to configure the items on the main Menu.
- The whole application is stitched together with the combination of an ApplicationController and ApplicationShell. I’m going to be very brief on these two because I’m going to devote a couple posts later down the line to these classes.
NEXT, LET’S LOOK AT THE PRESENTER PIECE… …it’s all written, but Community Server wouldn’t let me post it all at one time for some reason.
* Come on, I’m not the only person that screamed and threw the book across the room when Roland ends up back at the very beginning. I’m going to swear off fantasy books permanently if Rand doesn’t win a clear cut victory in book 12 whenever that comes out. Almost 20 years worth of waiting better come with a really solid ending.