Control(ler)

Published on In Programming Tags #architecture

I used to consider the controls as User Interface, so as "View" in the Model/View/Controller pattern. But in fact, as the name states, the control might be seen as the controller between the 5 following parts:
  1. model, containing the data to present
  2. behavior, managing user input
  3. renderer, to paint the visual
  4. visual state, to store the state the control itself is into
  5. layout, when the control is a container of other controls or simply to make specify client and non client area.

The framework 1.x was just very messy at this level. All these aspects were managed by properties and the only way to differentiate them was by their CategoryAttribute (Data + Format, Behavior + DragDrop + Key + Mouse, Appearance, Focus, Layout). The visual state is limited to the "Focus". For instance, you do not know when a button is pressed or hovered, unless you handle the events yourself.

Version 2.0 was much nicer on the layout and rendering part, but the legacy of version 1.x was unfortunately still there. The notion of behavior was introduce on the design level, along with the notion of adorner, that has implication on both behavior and rendering.

WPF looks pretty good from the start with the DataContext for the model, with the several templates and style for the rendering and with the layout controls. Version 4.0 is even better with the introduction of silverlight's visual state and Blend behaviors.

Leave a comment

Please note that we won't show your email to others, or use it for sending unwanted emails. We will only use it to render your Gravatar image and to validate you as a real person.