Original URL: https://www.theregister.com/2008/09/01/understand_xaml/

Shine on Silverlight and Windows with XAML

Learn now, pays later

By Tim Anderson

Posted in Software, 1st September 2008 13:02 GMT

Web bling tone Extensible Application Markup Language, or XAML, lies at the heart of Microsoft's rich-client strategy. The user interface for both Windows Presentation Foundation (WPF) and Silverlight, which is mostly a subset of WPF, is typically defined in XAML.

It is, therefore, something Windows developers will have to get to grips with if they want to stay in tune with Microsoft's latest and - arguably - most ambitious technology roadmap. Even if WPF itself never really takes off, Silverlight is almost certainly going to be big in Microsoft circles.

But what is XAML? It is easy to call it an XML language for defining a graphical user interface (GUI), but that is not quite right. Microsoft calls it "a system for representing structured information," which is about as generic as you can get, and reveals in its document XAML Object Mapping Specification 2006, here, that although XML is "a common format for XAML... any physical representation may be used."

Editing XAML in Visual Studio 2008

Visual Studio 2008 brings IntelliSense to editing XAML

It is also important to distinguish the XAML system from specific XAML vocabularies, such as WPF. Microsoft also uses XAML for Windows Workflow Foundation (WWF), using a different vocabulary that has nothing to do with GUIs. A better stab at defining XAML is to call it a declarative programming language for .NET, or a means of representing a graph of .NET objects.

It turns out that XAML has an uneasy relationship with XML. All the XAML documents you are likely to see are valid XML, but validating them as XAML is not easy. Microsoft explained back in 2006 why it could not develop a satisfactory XML schema for WPF.

The problem is not the core XAML, usually the namespace with an "X" prefix in a XAML document, but the WPF vocabulary, usually the default namespace. Visual Studio 2005 used a huge XamlPresentation2006.xsd that worked mostly but not always. Visual Studio 2008 replaced this with a language service like that used to support IntelliSense for C# and Visual Basic. While this works better, it is unfortunate for anyone wishing to use other XML tools for XAML editing.

XAML has features that simplify the way it maps to the .NET API. Several of these relate to setting property values. Typically XML does this with attributes, but this is awkward when a property is a complex object. XAML supports property elements, which use dot syntax to define objects that are properties of the containing object. Here is an example:

<Rectangle Height="20" Width="50" >
  <Rectangle.Fill>
   <SolidColorBrush Color="Gold" />
  </Rectangle.Fill>
</Rectangle>

It so happens that in this case you can do the same thing with a conventional attribute:

<Rectangle Height="20" Width="50" Fill="Gold" />

How does the XAML parser know that the string "Gold" must be converted to a SolidColorBrush? This is done through a Type Converter, a class that in this example converts a string to a new SolidColorBrush object.

Type Converters extend the number of properties that can be set as attributes, but do not deal with every possibility. In this example, if you wanted to use a different kind of brush, you would have to use the verbose property element syntax, or possibly a Markup Extension.

So what's a Markup Extension? This is an expression within braces that generally returns an object instance. In Silverlight XAML this is either a static resource or a dynamic binding. You could define a LinearGradientBrush as a resource, and then use that within a Markup Extension using attribute syntax:

<Rectangle Height="20" Width="50" Fill="{StaticResource MyGradientBrush}" />

Another XAML feature is called Attached Properties. This is where a class defines static properties that can be attached to objects of a different class. For example, this XAML specifies where a button appears in a grid layout, presuming it is contained within a Grid element:

<Button Content="Click me" Grid.Row="1" Grid.Column="0" />

At runtime, the Grid element has code that iterates through its children, checks the attached properties, and positions them accordingly. Attached properties are a special case of a feature called dependency properties, which are calculated at runtime and can change dynamically.

You can also extend XAML with custom objects. The main requirement is that classes used in XAML must have a parameterless constructor. The procedure is straightforward. Define a class; make sure your application has a reference to the assembly containing the class; then add a namespace declaration for the assembly. You can then define elements in XAML that map to your class, and at runtime these will become object instances. XAML has a curious story when it comes to formatted text, especially in Silverlight. In one sense it is rather limited. XAML has no understanding of common formats such as HTML, CSS or RTF, let alone the fancy new OOXML. Silverlight developers have to interact with the browser DOM in order to display HTML.

XAML preserved in Silverlight

No escaping it: Silverlight .XAP bundle preserves the original XAML

That said, XAML with WPF actually is a document format. The full WPF has an element called FlowDocument and rich formatting capabilities. Silverlight lacks FlowDocument, but does have a TextBlock with basic formatting options via the inline <Run> object. It also supports the Glyph element. This is interesting because it is the core element in XPS, Microsoft's invented-here alternative to Adobe's PDF.

XPS uses a subset of XAML to describe fixed layouts. In consequence, and with some compromises, you can use Silverlight to display XPS.

The bottom line is that XAML is a way of programming .NET declaratively. Its more intricate features improve the mapping between XAML and .NET. The result is we have design tools like Microsoft's Expression Blend and a clean separation between UI objects and program code, which is a considerable achievement.

As ever there's a downside, and with Microsoft it's the classic: this is thoroughly proprietary, and the schema issues make it difficult to validate with standard XML tools. If this doesn't deter you, then check out Microsoft's XAML and WPF documentation is here