• Article

Silverlight Programming Models, XAML, and the HTML DOM

Microsoft Silverlight will reach end of support after October 2021. Learn more.

Silverlight-based applications using the Silverlight plug-in in a browser host expose their functionality through a browser-based Document Object Model (DOM), as well as a Silverlight-specific programming model that includes an object tree concept. When using the Silverlight programming model, you can choose one of three API variations: JavaScript interpreted by the browser, managed code, or dynamic languages interpreted by the dynamic language runtime (DLR). This topic discusses the relationship between the DOM and each possible variation in API, and also discusses how XAML markup is used by the various API and application models.

This topic contains the following sections.

  • Document Object Model
  • The Silverlight Programming Model
  • XAML and the Silverlight Object Tree
  • Non-browser Hosts
  • Related Topics

Document Object Model

The Document Object Model (DOM) is a general platform-neutral and language-neutral programming concept. A DOM provides a structured representation of a document, such as a Web page, as well as a defined way to access and manipulate the document's structure, style, and content. Browsers that can host the Silverlight runtime as a plug-in each implement an HTML DOM that exposes the elements of the HTML page, including the Silverlight plug-in.

The World Wide Web Consortium (W3C) DOM standard forms the basis of the DOM implemented in the most widely used browsers. However, most browsers offer extensions beyond the W3C standard. Therefore, developers need to be aware of these differences in order to create platform-neutral content. Silverlight can be accessed by the browser DOMs listed in the following table.

DOM

Description

Gecko DOM (Mozilla, Firefox, Netscape version 6 and later, and other Mozilla-based browsers)

Gecko is the software component that handles the parsing of HTML, the layout of pages, the document object model, and the rendering of the entire application. For more information, see Gecko DOM Reference.

DHTML DOM (Internet Explorer)

The Dynamic HTML (DHTML) DOM gives authors direct, programmable access to the individual components of their Web documents, from individual elements to containers. For more information, see About the DHTML Object Model.

After you create the Silverlight plug-in (typically with a HTML object tag), you can retrieve a reference to the plug-in instance in the HTML DOM by referencing its ID. The following JavaScript example shows how to retrieve the ID of the Silverlight plug-in by using the document.getElementById method.

var plugin_1 = document.getElementById("SLPlugin_1");

The Silverlight Programming Model

The Silverlight API defines its set of objects as object trees that enable you to populate the initial content of a Silverlight-based application by loading XAML, and then adjust the object tree at run time. The Silverlight object tree is exposed through the Silverlight plug-in, which you create as a plug-in instance on a Web page. Silverlight uses the COM plug-in model for Microsoft Internet Explorer, and uses the Netscape API plug-in model for other browsers. You can program for Silverlight using either the managed API or the JavaScript API; most scenarios will use the managed API.

XAML and the Silverlight Object Tree

When you provide content for the Silverlight plug-in, as initially declared by the source parameter of the object tag (and then handled by the Silverlight application model if using the managed API), you are defining XAML elements in markup that have a hierarchical tree structure, with a root element. Parsed XAML creates the initial object tree for Silverlight.

Managed API

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="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://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

For certain managed API scenarios, you can load loose XAML, meaning a XAML file that is either included as content in a Silverlight XAP package or is accessed by URL. This XAML cannot declare x:Class or use code-behind. Example scenarios for this are merged resource dictionaries, user-specific resources, or content strings for Load. The relationship of this loose XAML to the remainder of the object tree depends on the exact scenario and is not described here.

JavaScript API

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="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="https://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.

Non-browser Hosts

Silverlight is not necessarily hosted in a browser. You also have the option of deploying a Silverlight-based application out-of-browser, or writing an alternative host framework. In these cases, the full DOM and scripting to it may not be available. For more information, see Out-of-Browser Support or Alternative Hosting.