Silverlight's managed APIs

The Silverlight API defines its set of objects as an object tree, so that you can load the XAML to populate the initial content of the Silverlight-based application, and then adjust the object tree at run time. In the managed API, the interaction with the Silverlight object tree is defined through managed code. Use the CLR to compile managed code into an assembly. The Assembly also typically contains XAML for use with Silverlight applications. Managed code can support the Silverlight application model and can invoke managed code in response to object lifetime events or user-initiated events. You can also use managed code to write support classes, define data objects, and use them for many other application scenarios. You can also discuss this using the DLR instead of the dynamic language in Clr,silverlight.

Attributes of the managed API

Managed code is extensible

The definition of true custom UI elements is not supported in previous Silverlight 1.0 and the current JavaScript API (regardless of client version). You can synthesize an element and then load it multiple times from the same definition XAML and specify the same function as code support, but this method does not support large extensions. With the managed APIs, the extension essentially derives only from existing classes or controls that support useful basic functionality, and may also include defining some supporting elements, such as new control templates, updated class-specific event handlers, and so on. Extended managed code is the basic concept of managed programming and. NET Framework programming, and there are no specialized topics in Silverlight documents, but the following topics can be useful:

Common Language runtime

Control customization

XAML and Custom Classes

Customizing dependency property and Dependency properties

Object Tree

The object tree concept exists in the JavaScript API, but manipulating the object tree in the model is limited to some extent by the lack of object construction methods. In the managed API, you can call a constructor on a class without using a XAML parser as an intermediate source to add objects to the tree. In fact, most of the tree can be built using only code, by calling the constructor continuously, adding objects to the object tree from the root, and then completing various child properties.

Managed code-behind and partial classes

The primary way to define the UI in Silverlight is to define the appropriate elements in the XAML markup. This may include the use of styles and templates, which are also defined in XAML markup. In many cases, you need to break the markup into different XAML files that are integrated with the Silverlight application model. In order to define the interactions that your application requires, you typically define event handlers for objects defined in XAML in response to object lifetime events or user-initiated events. In the managed API, each XAML page that requires event handling, or one of the XAML pages in which XAML is to be the content of the root element, must be tagged for compilation processing as part of the build. Markup compilation processing provides the necessary hooks to create a run-time interaction with the object tree when the XAML page is loaded. These hooks include event handlers and references for any object that is given its Name or x:name in XAML. In the Silverlight architecture, XAML is not fully compiled. A majority of the object trees that create XAML markup from the UI are deferred until the XAML page is actually loaded into the application and processed by the Silverlight XAML parser at run time.

Normalize DOM interaction

In the JavaScript API, you can informally refer to an object or variable in the HTML DOM from a Silverlight script, and vice versa, because the script is interpreted by the same browser script engine and may be in the same scope. There is a more formal separation in the managed API, because managed code is used by the Silverlight Core Library and its CLR, not by the browser. To interact with the DOM from the managed APIs, you can use a range of features, sometimes collectively called HTML Bridge, or HTML DOM bridge. These features include:

An API that exposes common parts of the DOM, such as the Document object, to managed code.

The functionality that enables managed types to be written from the DOM.

A conversion technique used to generate managed types from marshaling JavaScript values or objects.

An API designed to expose the object representations of Silverlight Plug-ins in the DOM.