Managed API for Silverlight

In Silverlight 1.0 previously, and under the JavaScript API currently (independent of the client version), there is no support for defining a truly custom UI element. You could composite an element and then load it multiple times from the same defining XAML, and assign the same functions as code support, but this approach cannot support large-scale extensibility. Using the managed API, extensibility is simply a matter of deriving from an existing class or control that supports a useful baseline of functionality, and perhaps also defining some support elements such as a new control template, updated class-specific event handlers, and so on. Extending managed code is a basic concept of managed and .NET Framework programming and does not have a single dedicated topic in the Silverlight documentation, but you might find the following topics useful:

• Common Language Runtime

• Control Customization

• XAML and Custom Classes

• Custom Dependency Objects and Dependency Properties

The object tree concept exists in the JavaScript API, but manipulating the tree in that model is somewhat limited by the lack of an object construction technique. In the managed API, you can call constructors on classes and can add to the tree without having to use the XAML parser as an intermediary. In fact, you can build up large parts of the tree using purely code, by calling constructors in succession and adding objects to the object tree starting from the root and working through various "children" properties. For more about how to work with the Silverlight object tree using code, see Silverlight Object Trees.

The primary technique for defining a UI in Silverlight is to define the elements in XAML markup. This might include use of styles and templates, which are also defined in XAML markup. In many cases you will want to factor the markup into different XAML files that integrate with the Silverlight application model. In order to define the interaction that is needed for the application, you generally want to define event handlers that respond to object lifetime events or user-initiated events for the objects defined in XAML. In the managed API, each XAML page where event handling is required, or where the XAML is intended as root element content, must undergo a markup compile pass as part of the build. The markup compile pass provides the necessary hookups for run-time interaction with the object tree that is created when the XAML page is loaded. These hookups include the event handlers as well as references for any object that is given a Name or x:Name in the XAML. In the Silverlight architecture, XAML is not compiled in its entirety. Much of the object tree creation that comes from XAML markup for UI is deferred until the XAML page is actually loaded into an application at run time and is processed by the Silverlight XAML parser. These concepts are explained in more detail in Code-Behind and Partial Classes.

In the JavaScript API, referencing objects or variables in the HTML DOM from your Silverlight scripting or vice versa can be done informally, because the script is interpreted by the same browser script engine and could potentially exist in the same scope. In the managed API, a more formal separation exists because the managed code is used by the Silverlight core libraries and its CLR, not by the browser. To interact with the DOM from the managed API, you can use a series of features that are sometimes collectively referred to as the HTML bridge, or HTML DOM bridge. These include the following:

• APIs that expose the commonly used parts of the DOM (for instance, the Document object) to managed code.

• Facilities that can make your managed types scriptable from the DOM.

• Conversion techniques for generating managed types from marshaled JavaScript values or objects.

• APIs that specifically expose the Silverlight plug-in's object representation in the DOM.

For more information, see HTML Bridge: Interaction Between HTML and Managed Code or Silverlight Programming Models, XAML, and the HTML DOM.