This chapter is from the book
This chapter is from the book
This chapter is from the book
Summary
You have now seen how XAML fits in with the rest of an app’s code and, most importantly, you now have the information needed to translate most XAML examples into a language such as C# and vice versa. However, because type converters and markup extensions are “black boxes,” a straightforward translation is not always going to be obvious.
As you proceed further, you might find that some APIs can be a little clunky from procedural code because their design is often optimized for XAML use. For example, the XAML UI Framework exposes many small building blocks to help enable rich composition, so some scenarios can involve manually creating a lot of objects. Besides the fact the XAML excels at expressing deep hierarchies of objects concisely, Microsoft spent more time implementing features to effectively hide intermediate objects in XAML (such as type converters) rather than features to hide them from procedural code (such as constructors that create inner objects on your behalf).
Most people understand the benefit of XAML’s declarative model, but some lament XML as the choice of format. The primary complaint is that it’s verbose; too verbose to type. This is true: Almost nobody enjoys typing lots of XML, but that’s where tools come in. Tools such as IntelliSense and visual designers can spare you from typing a single angle bracket! The transparent and well-specified nature of XML enables you to easily integrate new tools into the development process (creating a XAML exporter for your favorite tool, for example) and also enables easy hand-tweaking or troubleshooting.
In some areas (such as complicated paths and shapes), typing XAML by hand isn’t even practical. In fact, the trend from when XAML was first introduced in beta form has been to remove some of the handy human-typeable shortcuts in favor of a more robust and extensible format that can be supported well by tools. But I still believe that being familiar with XAML and seeing the APIs through both procedural and declarative perspectives is the best way to learn the technology. It’s like understanding how HTML works without relying on a visual tool.
Classes in the XAML UI Framework have a deep inheritance hierarchy, so it can be hard to get your head wrapped around the significance of various classes and their relationships. A handful of fundamental classes are referenced often and deserve a quick explanation before we get any further in the book. The Page class, for example, derives from a UserControl class, which derives from all of the following classes, in order from most to least derived:
- Control—The base class for familiar controls such as Button and ListBox. Control adds many properties to its base class, such as Foreground, Background, and FontSize, as well as the capability to be given a completely new visual template. Part III, “Understanding Controls,” examines the built-in controls in depth.
- FrameworkElement—The base class that adds support for styles, data binding, XAML resources, and a few common mechanisms such as tooltips and context menus.
- UIElement—The base class for all visual objects with support for routed events, layout, and focus. These features are discussed in Chapter 4, “Layout,” and Chapter 5, “Interactivity.”
- DependencyObject—The base class for any object that can support dependency properties, also discussed in Chapter 5.
- Object—The base class for all .NET classes.
Throughout the book, the simple term element is used to refer to an object that derives from UIElement or FrameworkElement. The distinction between UIElement and FrameworkElement is not important because the framework doesn’t include any other public subclasses of UIElement.