The following example creates a markup hierarchy that contains the root UserControl element and child TextBlock and Canvas objects. This example is specifically for the managed API, and represents the designated entry point class from a XAP package and the application manifest for a Silverlight-based application.

<UserControl x:Class="SilverlightApplication1.Page"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
  <StackPanel>
    <Rectangle
      Width="200" Height="35"
      Fill="PowderBlue" />
    <TextBlock
      Foreground="Teal" FontFamily="Verdana" FontSize="18" FontWeight="Bold"
      Text="Sample Output" />
  </StackPanel>
</UserControl>

For the managed API, before the XAML is parsed, it is compiled by a markup compiler on the developer machine. For details on this concept, see Code-Behind and Partial Classes.

When the XAML is loaded and parsed at run time on the client, the parser creates an object tree from the markup. The object tree will have a UserControl object as its root. In fact, it will contain an instance of a specific UserControl subclass: the Page class that you reference in the x:Class attribute of the root element.

When you interact with your Silverlight-based application at run time, you use the Silverlight managed API to access your Page class. You can also extend beyond the Page root of the immediate object tree and access the Application object. The Application provides access to aspects of a Silverlight-based application that you want to persist even if you replace the entire metaphorical page of the UI displayed in the Silverlight content area. Application includes application-level resources, access to the package that contains the application parts, and objects that connect to the HTML DOM. For more information, see Application Model.

Loose XAML

The following example creates a markup hierarchy that contains the root Canvas object. This example is specifically for the JavaScript API, and represents an individual XAML file that is served by the same server as the HTML page that hosts Silverlight. In this case, the XAML file is not packaged and has not been compiled by a markup compiler.

<StackPanel
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
  <Rectangle
    Width="200" Height="35"
    Fill="PowderBlue" />
  <TextBlock
    Foreground="Teal" FontFamily="Verdana" FontSize="18"
    FontWeight="Bold"
    Text="Sample Output" />
</StackPanel>

This XAML also defines a basic UI. In fact, it is visually identical to the previous example. When this XAML is parsed, the parser creates an object tree from the markup. This object tree will have a StackPanel as its root element.

When you interact with your Silverlight-based application at run time, you do not have immediate access to the full object tree. You have access to the variable you might have created to reference the Silverlight plug-in in the DOM, but otherwise your access to the programming model is typically through the sender of an event handler. This sender is an object that is within the object tree and is accessible to either Silverlight API. But sender is not usually accessible to the HTML DOM; the DOM stops at the level of the host object tag.

Any Name / x:Name references are used at run time by the JavaScript API, but their only use initially is to serve as targets for FindName calls. Only after you have made a FindName call do you have an actual object in the object tree; before this point the name of an object is just a string, and not an object. By convention, you typically use a variable name that is identical to the string used for Name, and this convention will be very useful if you ever migrate from JavaScript code-behind to managed code-behind while using the same XAML.