Experimenting With Composed Javascript UI Controllers

In the past, when I've wanted to create complex UI interactions with a collection of elements, I would have created a single Javascript controller that handled the interaction logic for all of the elements. As my user interfaces have gotten more robust, however, this single point of processing has become somewhat unwieldy to program and maintain. As such, I wanted to start experimenting with using composed Javascript UI controllers in which there is a single high-level controller for the entire collection as well as a low-level controller for each item within the target collection.

To experiment with this composed controller architecture, I wanted to start with a simple unordered list (UL). As the user interacts with the list, a few things can happen:

• If the user hovers over and out of an inactive list item, the list item enters and exits a "hover" state respectively.
• If the user hovers over and out of an active list item, no action is taken.
• If the user clicks on a list item, the current list item is activated. Any previously active list item is automatically deactivated.
• If the list is flagged as being inactive, none of the user interactions will have any effect.

Based on these rules of interaction, it quickly becomes clear that neither the root controller nor any of the individual list item controllers know enough on their own to be able to handle events entirely by themselves. The root controller doesn't store the state of each list item controller; and, the list item controllers don't know enough about the greater list (interactivity, existing active items) to be able to handle state transition.

What this means is that as the user interacts with the list, there necessarily must be bi-directional communication between the root controller and its composed list item controllers. As the user interacts with the individual list items, the associated list item controller must defer action to the root controller where the business logic and bigger picture are maintained. The root controller can then get targeted list item controllers to perform the necessary actions.

In the following demo, try to follow the user interactions. Notice that as the mouse activity is captured at the list item level, the list item controller asks the root controller to perform an action, which, in turn, can trigger actions on zero or more of the composed list items.

As you can see, the individual list item controllers don't carry out user interactions on their own; rather, they capture user interactions and then ask the root controller to act on them. At first, I was afraid that this was making my list item controller class very anemic; I was worried that the list item controller class should be more independent. But, then I realized that the list item controller needed to defer to the root controller because the root controller was the only place that knew enough about the environment at large to be able to control the UI's response.

As I was building this, the hardest part was trying to figure out what the list item controller could do on its own. At first, I thought it could do a lot independently; but, then as I added features like the ability to change the interactivity of the list and the ability to maintain an "active" item after click, I realized that the low-level list item controllers simply didn't have enough information to do things unmoderated. That's when I moved to more of a model where the list item controllers knew how to modify themselves, but not necessarily when to carry out those modifications.

Part of the reason that I always liked a single, root UI controller was because it both reduced the number of event handlers that needed to be bound and it made the augmenting of composed UI elements rather easy; since no event handling was done at the composed-element level, new items didn't have to be initialized in any way - they were plug-n-play. As my human-computer interactions become more robust, however, this single point of delegation is becoming unmanageable. Using both a root UI controller and composed item controllers seems to bring the situation back under control. This is, of course, at the cost of increased event binding and configuration. The benefits, however, might very quickly come to outweigh the cost.

I would love to hear about FLEX and how ActionScript developers handle this kind of stuff; you guys have years of UI-intense experience that, I am sure, would offer a tremendous amount of insight.

You Might Also Be Interested In: