Pavan Podila's Blog

Designer - Developer workflow - Part 1

There is certainly lot of information and awareness floating around that Windows Presentation Foundation (WPF) creates a new style of collaboration between the Designer and the Developer. How is that possible? The holding glue is a new XML based language called XAML. There are certain key elements of XAML that make this workflow a possibility. In this series of posts I’ll expound more into the world of XAML and its tools.

A common theme found in XAML is a clear separation of concerns. The logical structure of the page is distinctly separate from its styling. Interface elements like Buttons, Textboxes, Listboxes, etc. can be made to look dramatically different from the classic appearances that we have always known. Animations can be intermixed with static elements like text and they can also be applied on a wide variety of elements. Interface elements are not just limited to 2D but extend to 3D as well. It is thus possible to have a page design that mixes 2D and 3D to create a very immersive experience.

Anatomy of a Control

Underneath all these are some specific XAML elements that make it all happen. If we dissect a single UI element like a Button we can start seeing many layers.

The look:

The topmost layer of course is the appearance or the look of the Button control. We can separate it out into a template and just switch the template to acquire a different look. This idea of templates is more formally called Control Templates. UI controls themselves are of different kinds. On one hand we have a control like a Button that does not contain any other children and on the other hand we have controls like the Listbox which host a list of items or children. In addition to these two types we also have a third type of control, like the Tree, which is a hierarchy of children. So it makes sense that the control template be also be different. Sure enough. We have a ContentTemplate for a Button-like control (aka singular control), an ItemTemplate for a Listbox-like control (plural control) and a HierachicalDataTemplate for a Tree-like control.

The interaction:

Once the look is established we would like to interact with the control and we have events just for that. These events are very similar to the ones in WinForms but with some extra capabilities. In most UI paradigms events always originate from the control and bubble-up to their parent. So if I had a Button inside a Panel and I clicked on the Button, the Button would see the click event first followed by the Panel. In WPF this event propagation strategy is made bottom-up as well as top-down. The top-down approach is where the Panel would see the event first. This is more formally called the tunneling strategy

Trigger the Animations:

In addition to plain events, the control becomes more lively with animations and the way to trigger animations are generally events or some state changes. The way to capture a state change is to use a Trigger. Simply put, a trigger says that when a property changes its value to something, just trigger an action. That action could be an animation or a simple change in the appearance of the control.

To play an animation we first create a Storyboard, which could have one or more animations. An animation is just a time-based, progressive change in the value of a property.

Encapsulating with <Style/>

All of these elements: templates, events, triggers, animations can be captured into a single structure called the Style. Style is a list of property-value pairs for an element which also be used to specify other properties of the control. Thus we can encapsulate the complete anatomy of the control inside a declaration.

The ResourceDictionary --- the mother load

Bundling up the look and feel of a single control is straightforward but how do you encapsulate this information for a 100 different controls, say. The next higher level of organization is the ResourceDictionary. It is a list of name-value pairs where the name stands for a uniquely identifiable resource and the value part of the pair is the resource itself. Resources are not just limited to styles but absolutely any object. So I could have a ResourceDictionary that has a bunch of styles, templates, data-objects, brushes, etc defined that could be used in other parts of the application. I can also nest ResourceDictionaries. In other words if you think your resource-dictionary is growing too long, just break it up into smaller resource-dicationaries and merge them together inside a top-level resource dictionary. That greatly improves the organization of all the resources or assets.

ResourceDictionaries can be then linked into a page and the contained resources can be used by referring to their unique names.

Summary

We have covered enough material to understand the structure of a Control. In the next post I’ll talk about how these concepts can help in the designer-developer collaboration.

posted by Pavan Podila @ 7:13 PM