Vasu Balakrishnan’s Blog


leave a comment »

As I’m reading XAML Demystified chapter from book, few things caught my attention and I didn’t know about them before.

  • “XAML is a relatively simple and general purpose declarative programming language suitable for constructing and initializing .NET objects”. I’d thought XAML was built for WPF. The author say that it could be applied to any .NET technology like Workflow Foundation, etc. I then did a quick search for XAML usage and it led me to video where they talk about XAML in .NET 4.0. I’m excited about some of the upcoming features.
  • XAML specification defines rules that map .NET namespaces, types, properties, and events into XML namespaces, elements and attributes. XAML was designed to work with .NET type system, and can be used with just about any .NET object.
  • At runtime, event handlers are always attached before any properties are set declared in XAML (excluding Name property which is set immediately after object construction)
  • Property Elements – They always take form as TypeName.PropertyName, they are always contained within the TypeName object element and can never have attributes of their down. They can be used for simple properties as well.
  • Type Converters – They know how to convert the string representation to the desired data type.
  • Markup Extensions, like Type Converters, enable you to extend the expressibility of XAML. Both can evaluate string value at run-time and produce an appropriate object based on the string. Unlike Type Converters, Markup Extensions are invoked from XAML with explicit and consistent syntax. They support Positional / Named Parameters. Positional parameters are treated as string parameters to the extension class’s appropriate constructor.
  • An Object element can have three types of children – a value for content property, collection items or a value that can be type converted to its parent. To avoid ambiguity, the following rules are followed by XAML compiler when encountering / interpreting child elements

    • If type implements IList, call IList.Add for each child
    • If type implements IDictionary, call IDictionary.Add for each child, using Key attribute value for key and element for the value
    • If the parent supports Content property and the type of the child is compatible with that property, treat the child value as its value
    • If the child is plain text, and a type converter exists to transform the object into the parent type, treat the child as input into the converter and the use output as the parent object instance.
    • If none of the above applies, raise an error.
  • WPF’s runtime XAML parser is exposed as two class XamlReader / XamlWriter.
  • XAML language namespace has a Name keyword that enables you to give any element a name. x:Name syntax is used to name elements but that can be overridden to any other property using a custom attribute RuntimeNameProperty. You can use either mechanism but not both.
  • XAML compilation involves three things: converting a XAML file into a special binary format, embedding the converted content as a binary resource (BAML) in the assembly being built and performing the plumbing that connects XAML with procedural code automatically.  BAML stands for Binary Application Markup Language, is simply XAML that has been parsed, tokenized and converted into binary form. Its a compressed declarative format that is faster to load and parse. Its just an implementation detail of the XAML compilation process. This does not generate procedural source code. Some procedural code do get generated (if you use x:class) but its just some glue code written to load / parse a loose XAML file at runtime. They files are given .g.cs suffix. The glue code generates a partial class (specified by x:class), contains a field (private by default) for every named element in the XAML. It also has an InitializeComponent method that does the work of loading embedded BAML resource, assigning fields to appropriate instances originally declared in XAML and hooking up event handlers. BAML can be decompiled back to XAML using Application.LoadComponent.

The last item in the list, is something that I wasn’t aware of. I’ve seen the glue code few times as part of my debugging process, but didn’t pay attention to it. Now it makes it clear.

I’m moving on to next chapter…


Written by nbvasu

June 29, 2009 at 2:10 pm

Posted in WPF

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: