Extensible Application Markup Language (XAML)

SimpleApplication2.cs

 using System; 
 using MSAvalon.Windows; 
 using MSAvalon.Windows.Controls; 
 using MSAvalon.Windows.Media; 
 using MSAvalon.Windows.Navigation; 
 
 namespace IntroLonghorn { 
 public class MyApp : MSAvalon.Windows.Navigation.NavigationApplication { 
 
 protected override void OnStartingUp (StartingUpCancelEventArgs e) { 
 base.OnStartingUp (e); 
 CreateAndShowMainWindow (); 
 } 
 
 private void CreateAndShowMainWindow () { 
 
 // Create the applications main window 
 mainWindow = new MSAvalon.Windows.Navigation.NavigationWindow (); 
 
 // Fill window with appropriate controls 
   
 // Show the window 
 mainWindow.Show (); 
 } 
 } 
 
 internal sealed class EntryClass { 
 [System.STAThread]     private static void Main () { 
 Thread.CurrentThread.ApartmentState = System.Threading.ApartmentState.STA; 
 MyApp app = new MyApp (); 
 app.Run (); 
 } 
 } 
 } 

The code you ve seen up to now is just another variation on traditional programming models. The only new aspect is the actual classes I ve used. Most of the time, however, you won t actually write much of this code. Let s take a slight detour and learn about a new programming language that allows you to write this same code in a much more compact and ”to me, at least ”more understandable manner.

In many applications, much of the code you write pertains to creating and updating the UI of the application. In fact, in the previous examples, there was no code other than that required to create the UI. In the last few years , many developers have learned to write, and even to prefer to define, an application s UI by using one of a number of available markup languages. The Longhorn platform defines a new markup language named the Extensible Application Markup Language (XAML; pronounced Zamel, which rhymes with camel).

Using a markup language to define a UI has a number of advantages over using a procedural programming language. These advantages include the following:

• More apparent control hierarchies

• More apparent property inheritance

• Easier processing and interpretation of markup language by tools

• Potential separation of UI and procedural code

I like XAML, and I prefer to use it to define my UIs rather than using the procedural-type coding I ve shown you so far in this chapter. However, don t think that you ll be able to do everything you ll need to by using nothing but XAML.

Consider this statement from the documentation: Documents can often be written entirely in XAML and displayed in the browser. I hastily point out that this sentence uses the word documents , not applications , and it qualifies the statement with the term often . When you re writing a document that displays static content, you can create it in pure XAML. You can even write a document that uses data binding to display and update content from a data source by using nothing but XAML. You can define animations and mouse-over effects by using nothing but XAML. You can do a heck of a lot using nothing but XAML. (In fact, I try to do as much as possible in XAML and as little as possible in code. My applications seem to be less buggy and work more quickly the less code I write!) Nevertheless, to write a production application, you ll typically need to react to events, provide custom decision logic, or include many other non-UI operations, so you ll need to mix XAML and code. Fortunately, this is extremely easy to do.

I ll describe XAML files in more depth in Chapter 3; for now, let s look at a primer for XAML:

• A XAML element name is a .NET Framework class name. When you define a XAML element, you are effectively creating an instance of the .NET Framework class with the same name as the XAML element.

• A XAML attribute name maps to the property or field with the same name, typically in the class instance.

In the SimpleApplication1.cs program, I create a window and add some controls to it by using the following code:

 // Create the applications main window 
 mainWindow = new MSAvalon.Windows.Window (); 
 
 // Add a dark red, 14 point, "Hello World!" text element 
 txtElement = new MSAvalon.Windows.Controls.SimpleText (); 
 txtElement.Text = "Hello World!"; 
 txtElement.Foreground = new 
 MSAvalon.Windows.Media.SolidColorBrush (Colors.DarkRed); 
 txtElement.FontSize = new FontSize (14, FontSizeType.Point); 
 mainWindow.Children.Add (txtElement); 
 mainWindow.Show (); 

The following XAML document produces exactly this same UI.

 

HelloWorld.xaml

 <Window xmlns="http://schemas.microsoft.com/2003/xaml" Visible="true"> 
 <SimpleText Foreground="DarkRed" FontSize="14">Hello World!</SimpleText> 
 </Window> 

 

The root Window element creates an instance of a class named MSAvalon.Windows.Window . Somehow, the build system needs to know that the XAML element named Window refers to an instance of the class named MSAvalon.Windows.Window . The xmlns attribute value provides this mapping.

XML parsers interpret unqualified element names relative to the namespace specified in the most-recent, in-scope, default namespace attribute, xmlns . When you specify an xmlns value of "http://schemas.microsoft.com/2003/xaml" , the build system interprets an unqualified element name on the defining element, or one of its subordinate elements, as the name of a class in a predefined set of namespaces.

Let me restate that in more concrete terms, using C# as an example. The xmlns declaration effectively adds a number of using statements to your code. The build system then interprets each unqualified XAML element name as a class name with the using declarations providing the context for the possible namespaces. Although the list might change, at the time of this writing, specifying the standard value for the default namespace attribute causes inclusion of the following using statements:

 using MSAvalon.Windows; 
 using MSAvalon.Windows.Controls; 
 using MSAvalon.Windows.Controls.Primitives; 
 using MSAvalon.Windows.Data; 
 using MSAvalon.Windows.Documents; 
 using MSAvalon.Windows.Shapes; 
 using MSAvalon.Windows.Media; 
 using MSAvalon.Windows.Media.Animation; 
 using MSAvalon.Windows.Navigation; 

The standard default namespace declaration also causes the build system to reference the PresentationFramework and PresentationCore assemblies, which contain classes in the previously listed namespaces.

I set the Visible attribute of the Window element to true . This corresponds to my original code that displays the window by calling its Show method.

I ve nested a SimpleText element within the Window element definition. This tells the system to instantiate an MSAvalon.Windows.Controls.SimpleText object, make it a child of the Window object, and set the value of the simple text object to the Hello World! string.

Save the preceding XAML code in a file named HelloWorld.xaml, and run the file. The browser will interpret the XAML code in the file and display the UI, as shown in Figure 1-1.

Figure 1-1: The browser displaying the XAML version of Hello World

You might want to use a .NET class that isn t defined in one of the default namespaces listed previously. A typical example is using a class from an assembly that you create. The build system needs to be able to map the element name that you specify in the XAML source file to the appropriate .NET class in the correct assembly. XAML defines an XML processing instruction (PI) named ?Mapping that you use to make this association.

The ?Mapping PI allows you to define an XML namespace prefix that maps to a CLR namespace and assembly. When you qualify an XAML element name with this namespace prefix, you tell the build system, in effect, to take the element name, add the CLR prefix to the name, and create an instance of the class with the resulting name. The compiler will reference the specified assembly so that it can find the definition of the class.

The following example creates an instance of the WiseOwl.Statistics.PoissonDeviate class, the definition of which resides in the WiseOwl.Statistics.Library assembly:

 <?Mapping XmlNamespace="stat" ClrNamespace="WiseOwl.Statistics" 
 Assembly="WiseOwl.Statistics.Library" ?> 
 <Window xmlns="http://schemas.microsoft.com/2003/xaml" Visible="true"> 
 <SimpleText Foreground="DarkRed" FontSize="14">Hello World!</SimpleText> 
 <stat:PoissonDeviate Mean="5.0" /> 
 </Window> 

I cannot emphasize enough that XAML is simply another way to produce code that uses the .NET Framework UI classes. In fact, you could have a tool that displays a XAML UI specification graphically using a visual designer. Another tool might do the reverse and allow you to design the UI graphically and save it as a XAML file. Yet another tool might save the UI design as procedural code, which is similar to how the WinForms designer works. All these approaches are just different methods of specifying the same information.

Earlier in this chapter, I mentioned that the browser could render a XAML file in its window. The browser can do this only when the XAML file contains nothing but markup, like the simple example just shown. As your UI becomes more complicated, you ll typically have to use event handlers and other nonmarkup source code in addition to the XAML that describes the UI. Any time you have a mixed source code base ”that is, markup and nonmarkup source code ”you must compile the markup and source code using the MSBuild utility. After compilation, you can run the application as a stand-alone component or have the browser display the resulting UI.