Silverlight Programming Models, XAML, and the HTML DOM
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.
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.
var plugin_1 = document.getElementById("SLPlugin_1");
The Silverlight Programming Model
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.
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.
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.
<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.
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.