XAML Part 2.

Ok, what is XAML and what does it look like?

XAML defines an application's UI, with tags representing standard Windows controls and attributes representing their properties. Nothing revolutionary there! Here's a simple XAML page:


<Canvas xmlns="http://schemas.microsoft.com/2003/XAML" ID="sample">
     <Label ID="exampleLabel1" FontFamily="verdana" FontSize="8" Canvas.Top="10" Canvas.Left="10">This is a label's text!</Label>
     <TextBox ID="exampleTextBox1" FontSize="8" Canvas.Top="8" Canvas.Left="75">This is some text in a TextBox!</TextBox>
     <Label ID="exampleLabel2" FontFamily="verdana" FontSize="8" Canvas.Top="35" Canvas.Left="10">Another Label control</Label>
     <TextBox ID="exampleTextBox2" FontSize="8" Canvas.Top="33" Canvas.Left="75"></TextBox>
     <Button ID="exampleButton" Width="50" Canvas.Top="60" Canvas.Left="155">OK</Button>
</Canvas>


Note that the example above is based on the original "Avalon" preview - I haven't had chance to check out the latest bits, but note that the schema namespace is http://schemas.microsoft.com/winfx/avalon/2005 in the latest release.

Each XAML page consists of a root panel element (a Canvas in this case) that contains nested controls, such as Labels, TextBoxes, and Buttons. "Avalon" deserializes these elements into live object instances of strongly-typed controls, using the attribute values (such as ID or Width) to set the object property values. Note that positioning is handled by the strange Canvas.Left, Canvas.Top construct; these are known as "extended attributes", and elements inherit these because they are nested within a Canvas element. This is strikingly similar to the way "expando" properties work in IE (you may have used them when using DHTML Behaviors); but that's no coincidence - the IE team members are heavily involved with "Avalon".

Each XAML element corresponds to a class in the "WinFx" release of the .NET framework. When the application runs the XAML markup is deserialized into objects by the runtime; markup elements become object instances, and properties are set according to the values defined in the XAML elements' attributes. The concepts involved are exactly the same as how you serialise and deserialize objects to and from XML using .NET 1.x today.

The root element of all XAML documents is one of the subclasses that inherit from the Longhorn Panel class. There are several different panels that provide positioning and layout services. If you create a XAML Application with the Visual Studio.NET "Whidbey" alpha on the "Longhorn" preview, it creates a default Canvas panel, which provides something similar to absolute positioning in Web pages or the standard positioning model in Windows Forms.

Just like a web app, a XAML application is made up of pages. A .proj file groups the pages together into an application, and in addition to containing information about each XAML page, also specifies compiler settings, such as version info. It also controls whether the app will run in the browser (i.e. run from the server, like a web app), or be displayed in a window (i.e. installed to the client, like a thick client). An application definition file defines the application's navigation model and application-level events. If you're familiar with .NET, then you should be seeing shades of ASP.NET and Win Forms development by now... but a subtle combination of the two...

More soon... inlcuding some info on "rival" application markup initiatives... and some products that allow you to create XAML applications that run on .NET 1.x...

If you need more info on any of the above (keep in mind that "Avalon" is still under development, and anything can change until it ships!), please see the MS "Longhorn" SDK site, which contains all the publicly available info on "Longhorn", "Avalon" and XAML.