XAML

- Tech and Technology

XAML (short for Extensible Application Markup Language , and pronounced "Zammel") is the user interface markup language for the Windows Presentation Foundation , which is one of the "pillars" of the WinFX API .

XAML is a declarative XML -based language optimized for describing graphically rich visual user interfaces , such as those created by Macromedia Flash . XUL and UIML are other examples of XML-based user interface languages. SVG is another language proposed by W3C supporting graphics, animations, embedded media, events and scripted behavior which could be used as an XML-based user interface language.

In typical usage, XAML files will be produced by visual design and developer tools, such as Microsoft Expression Interactive Designer or Microsoft Visual Studio . The resulting XML is interpreted on-the-fly by the Windows Vista display subsystem which replaces the GDI in previous versions of Windows. XAML elements map to Common Language Runtime objects. Attributes map to properties or events on those objects.

XAML was designed to support the classes and methods in the .NET Framework that deal with user interaction, especially screen displays. The acronym XAML originally stood for Extensible Avalon Markup Language, Avalon being the original code name for Windows Presentation Foundation , the name for this group of .NET classes. -

Related Terms

- XAML and XML Language Feature Reference

XUL

ZUL ZK Framework

Macromedia Flex

OpenLaszlo

List of user interface markup languages

Comparison of user interface markup languages -

Microsoft XAML overview

XAML Controls from Microsoft Longhorn Developer Introduction

XAML used in Microsoft .NET platform

XAMJ, open source Java based project

United XAML Initiative - Open Source XAML Alternatives - From Wikipedia.com and Microsoft.Com

XAML and Custom Classes - Other Resources

XAML Overview

The Extensible Application Markup Language (XAML), XAML is based on Extensible Markup Language (XML) and enables developers to specify a hierarchy of common language runtime (CLR) objects with a set of properties and logic. -

XAML Features. XAML is a Declarative Language - Creating a User Interface with XAML - Creating a Basic XAML File - Base Classes and XAML -

XAML is a Declarative Language

WinFX application development raises abstraction to the level of a declarative programming model. To facilitate programming for this model a new XML-based declarative programming language, XAML, has been developed. Let's look at an XML example to see how little XML is necessary to create a user interface (UI) element. The following hypothetical example demonstrates that all you need to do to write a "Hello World" in XML (or really any markup language) is to initialize a few elements that have special meaning and represent user interface (UI) constructs to some hypothetical XML interpreter

?xml version="1.0" standalone="yes"?> <Window> <Button>Hello World</Button> </Window>

XAML is based on expanding this basic principle to the point that entire multipaged applications can be produced principally with markup. -

Creating a User Interface with XAML

XAML is the prefered way to create a UI in the WinFX programming model because it provides a way to separate UI definition from logic, and enables you to integrate code by using code-behind files that are joined to the markup via partial class definitions, or for simple cases to also specify inline code using a XAML directive and CDATA . The ability to mix code with markup is important because XML by itself is so inherently declarative that it does not really suggest a model for flow control. -

XAML enables you to create a UI entirely without using code. You can create quite elaborate documents or pages entirely in markup using controls, text, images, shapes and so forth. The following XAML example shows how little markup is necessary to create a button.

Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" > <Button>Click Me</Button> </Canvas>

However, if you want some event to occur when a user clicks the button, you will use code-behind written in a procedural language to handle the Click event that a button supports. The following example shows a XAML file, and a separate file that provides the code-behind for the XAML. When the button is clicked its background becomes red.

C# namespace MyNamespace { public partial class MyCanvasCode : Canvas { void Button_Click(object sender, RoutedEventArgs e) { Button b = e.Source as Button; b.Background = Brushes.Red; } } }

Creating a Basic XAML File

This section explains the basic structure of XAML filesthe steps you need to complete before you actually start adding UI elements. XAML files are conventionally XML files with an .xaml extension, and a namespace mapping to XML namespaces. Here, since we are documenting XAML for Windows Presentation Foundation (formerly code-named "Avalon"), all the namespace mappings are for the Windows Presentation Foundation and XAML namespaces. XAML has a set of rules to map classes into object tags, attributes into properties and events, and XML namespaces to CLR namespaces; for example, XAML element tags map directly to Microsoft .NET types as defined in the Windows Presentation Foundation assemblies. For more information, see XAML Namespaces and Namespace Mapping . -

The Root Element

Like all well-formed XML files, XAML files must have one root tag. It is only meaningful to use a root element that can support a content model so that you can add child elements or other content to it (panels such as a DockPanel or Canvas are typical), or an element that is part of the application model (Window or Page , for example). In the following example, the root element is a Canvas . The root element also contains the xmlns and xmlns:x attributes, which indicate to the parser via the namespaces which assemblies contain the tag names, and when members of those namespaces are being referenced. The following example shows the root element of a typical XAML file. -

Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" >

</Canvas>

Note that the xmlns attributes are only necessary on the root element of the page or application. -

Adding Code

Most WinFX applications consist of both XAML and code, such as Microsoft Visual Basic .NET or C#, in a code-behind file. The root XAML element identifies where it expects to find its code-behind when compiling by specifying a namespace and class as its x:Class attribute value. The XAML example given in the previous Creating a User Interface with XAML section sets this value as MyNamespace.MyCanvasCode, and you'll see in the matching code-behind file that this same namespace and class are being declared, with the class here being declared as a partial class . The compiler is effectively creating a class in the background for any given XAML page already, and defining the code-behind class as a partial class enables the resulting code to be literally combined within the same namespace and class when interpreted at runtime. The most obvious benefit of this is that you can take advantage of Name identifiers you declared in XAML markup and use them as if they were object instances that can be referenced by code. - If you do not want to create a separate code-behind file, you can alternatively put your code embedded within a XAML file. x:Code is a directive element defined in XAML that can contain inline programming code to interact with the XAML on the same page. The following example illustrates inline C# code. Notice that the code is inside the x:Code element and that the code must be surrounded by to escape it for XML, so the markup parser (interpreting either the XAML or Windows Presentation Foundation schema) will not attempt to interpret the code literally.

Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" x:Class="MyNamespace.MyCanvasCodeInline" > <Button Name="button1" Click="Clicked">Click Me!</Button> <x:Code><![CDATA[ void Clicked(object sender, RoutedEventArgs e) { button1.Content = "Hello World"; } ]]></x:Code> </Canvas>

There are a number of reasons for discouraging and/or limiting use of this facility to place code inline. In terms of architecture and coding philosophy, separating markup and code-behind enables designer and developer roles to be much more distinct. On a more technical level, the code that you put inline can also be awkward to write, because you are always writing into the XAML page's generated partial class, and are typically using the default namespace mappings. You may need to fully qualify many of your API calls you make here because you cannot add using statements. The default Windows Presentation Foundation mappings include most but not all CLR namespaces present in the Windows Presentation Foundation assemblies, you'll have to fully qualify calls into the remainder. You also can't define multiple classes in the inline code, and everything must exist as a member or variable within the generated partial class. For more information, see x:Code XAML Directive Element . -

Base Classes and XAML

Underneath XAML is a collection of classes that correspond to objects / markup elements; however, some classes cannot be mapped to elements. Abstract classes, like ButtonBase , are used for inheritance and do not have corresponding XAML markup tags, and there are related nonabstract classes that are intended only as base classes because they don't have inherent rendering through content models and theme styles. Some classes lack default (parameterless) constructors, which is a XAML language requirement for being interpreted as an element when geneting objects based on the markup. Also, there are a number of classes that are valid as XAML elements but will only function properly when they are placed in an expected position of an overall content model or element tree. For instance, a MenuItem should typically only be placed as a child of a MenuBase descendant such as Menu .

FrameworkElement is the base UI class of the WinFX presentation framework. When designing UI, developers will use various shape, panel, decorator, or control classes, which all derive from FrameworkElement . A related base class, FrameworkContentElement , supports document-oriented elements that work well for a flow layout presentation. - Most interaction between an XAML application and an end user is accomplished through control classes. For example, the TextBox class enables users to enter text input and receive output. The following example shows the complete code needed to create a text box that allows you to enter and delete text. Notice that you simply use the object element syntax to create a text box object.

TextBox>This is a Text Box</TextBox>

Note that this element has text content between the opening and closing tags, which would be analogous to InnerText in the XML document object model. The interpretation of such inner text varies somewhat from element to element depending on its content model, but for a typical control, this inner text becomes display text for that control in the UI. -

XAML Properties

XAML properties expressed as attributes enable you to add features to object element tags. For example, the following markup creates a button with red text and a blue background.

Button Background="Blue" Foreground="Red">This is a button</Button>

Properties as they appear as XAML attributes on an element are often inherited from base classes. For example, in the previous code example, the Background property is not an immediately declared property on the Button class, but is instead inherited from the base Control class. In order to be settable as a XAML attribute, a property must be public, must be read-write, and must reference a type that can be parsed/instantiated by a XAML reader application either on basis of a type-converted string representation or an object reference made through a markup extension. -

Attribute and Property Element Syntax for Properties

Most properties can be set in a syntax that is analogous to XML attributes, as the previous example did. -

Properties can also be defined using property element syntax. The syntax for such properties is <Object.Property>. For cases where both attribute and property element syntax are enabled, the two syntaxes are entirely equivalent, and in many such cases using the property element syntax will probably seem unnecessarily verbose. The following example shows exactly the same properties being set, this time using property element syntax.

Button> <Button.Background> <SolidColorBrush Color="Blue"/> </Button.Background> <Button.Foreground> <SolidColorBrush Color="Red"/> </Button.Foreground> This is a button </Button>

There are a number of possible reasons for using the property element syntax. Some are required, some are optional. The following are some examples. Note that this is not a complete list; as you view the remainder of the documentation, it will be noted either in the references, conceptual material or examples whenever the property element syntax is a requirement. Property element syntax is typically not shown in cases where it would have been optional. -

The Name Property

Many XAML elements support a Name property. This property is particularly important because it allows you to reference a particular element from code-behind, when that element was originally created from XAML markup. Even elements that cannot use Name because of their class inheritance can use an essentially equivalent x:Name Attribute for this same purpose. -

Collections

The Resources collection is a collection property that is present on all framework-level elements, and setting this property in XAML requires the property element syntax. Without property element syntax, the parser wouldn't be able to apply multiple values using an attribute syntax, and couldn't just accept any child element of the element tag because the child element collection is what's used to compose a typical element tree of visible elements for an application, not the resources. Therefore, to specify resources for a given element, such as a Canvas , use the property element syntax , and then enclose all your resources for this collection within it as object element syntax. See Define and Reference a Resource for a more complete usage example. -

By-Reference Types

Many properties where the underlying type of the property is a by-reference object type rather than a value type will necessarily require either a property element syntax to wrap an object element declaration (this is analogous to just-in-time constructor call to satisfy the reference), or a markup extension reference to an already existing instance (such as a resource). In some cases the by-reference types are conceptually akin to "alternate content" of a given element, and require declarative markup that must go beyond a simple attribute value. For example, here is the syntax required to define the ContextMenu of an arbitrary framework element (this is defined by a property that takes a ContextMenu object as its value): -

Button> <Button.ContextMenu> <ContextMenu> <MenuItem Header="1">First item</MenuItem> <MenuItem Header="2">Second item</MenuItem> </ContextMenu> </Button.ContextMenu> Right-click me!</Button>

In contrast, there are also a limited number of object types that support a "mini-language", which enables a new instance to be constructed and used as the property value on the basis of specially parsing the string value of a single attribute. The Thickness structure type, commonly used to denote measurements of a rectangular area such as a Margin , is an example of such a type with a mini-language exposed to promote ease of use in XAML markup. Note: On a technical level, such "mini-languages" are facilitated by supplying a particular type converter attribute and type-conversion implementation on a per-property basis rather than having type conversion be at the class level.

Other Required Property Element Usages

Many syntax constructs when writing a XAML style will require the property element syntax. For instance, the value of a property setter in a style, if it is anything other than a simple parsable value such as a double or a string, must be enclosed within a Setter.Value property element tag which is a property of the setter. For more information on style syntax, see Styles Overview . -

Optional Usages

Optional usages include being specific about "spelling out" element content properties that the parser considers implicit. For instance, when declaring the contents of a Menu , you could choose to explicitly declare the Menu 's Items collection as a <Menu.Items> property element tag, and place each MenuItem within it, rather than using the implicit parser assumption that all child elements of a Menu must necessarily be a MenuItem . -

Events

XAML creates UI elements such as buttons, text boxes, shapes, and so forth, but without code of some sort, XAML does not handle events. For example, if you have a button on a page, the XAML can create and display the button and its UI text and all manner of visuals and behavior, including some visual changes when the button is clicked, but beyond that the button will do nothing, yet. XAML and the larger Windows Presentation Foundation programming model enables you to associate events for elements and the handlers to be run in attribute syntax, with the name of the event being the attribute name, and the method name of the handler you will write as the (string) attribute value. You must then provide the implementation of that event handler in code-behind, in a language such as Microsoft Visual Basic .NET or C#. That event handler is expected to match the delegate for the appropriate event, and to be findable in the scope either of the page's partial class or by an otherwise qualified reference. The following example shows the XAML that creates the button, and the C# code-behind of a handler that does something meaningful to the button's characteristics by acting on data that was passed in the event's arguments. You've already seen this example in the context of describing the relationship of a XAML file and its code-behind.

C# namespace MyNamespace { public partial class MyCanvasCode : Canvas { void Button_Click(object sender, RoutedEventArgs e) { Button b = e.Source as Button; b.Background = Brushes.Red; } } }

A particular event feature that is unique to Windows Presentation Foundation is the concept of a routed event . Routed events enable an event to be sourced by one element but then travel along a route that moves through the tree of elements that your application defines, and potentially to be handled by one or more elements along that route between the source element and the application's root. The most common scenario for routed events is handling input. For instance, in a small application, you could centralize all of your event handling logic in the root element, writing a single handler for each relevant event, identifying the source of the event with arguments, and reacting differently to each source with branching logic in the handler. You can also do the same thing when compositing controls and handling or exposing events from the control components more generally at the top level of the control.

Note: Styles do support some pure XAML syntax for events via the Triggers mechanism; for details, see Styles Overview ).