About reusable components

MCS provides a mechanism that allows authors to define their own markup structures (i.e. elements) to represent so-called "reusable components". Reusable components can be created by combining the various existing built-in components and capabilities of XDIME 2 with custom JavaScript, styles, etc. Reusable components are practically indistinguishable from those provided by the core of MCS. Page authors who want to use a reusable component need to link its binding policy from their projects and then they can use the custom markup just as if it was a part of XDIME. At runtime, MCS uses the component definition to map from the custom markup to XDIME that it can process directly.

MCS provides a mechanism that allows authors to define their own markup structures (i.e. elements) to represent so-called "reusable components". Reusable components can be created by combining the various existing built-in components and capabilities of XDIME 2 with custom JavaScript, styles, etc. Reusable components are practically indistinguishable from those provided by the core of MCS. Page authors who want to use a reusable component need to link its binding policy from their projects and then they can use the custom markup just as if it was a part of XDIME. At runtime, MCS uses the component definition to map from the custom markup to XDIME that it can process directly.

A binding policy contains a binding definition and a corresponding implementation that together are applied to custom elements in an input document to transform them into other elements, either built-in or other custom elements that will be further transformed by other bindings. The definition of a reusable component provides the interface of the binding that is constant across devices and visible to page authors who use the component. The binding definition can have a number of corresponding binding implementations, each of which can be associated with a variant. Binding implementations contain the potentially device/feature-specific implementation of a binding definition. Each implementation accepts the same input from the page but transforms it into a different output depending on the device capabilities. Each project can have a set of binding policies that can be applied to elements from within the project.

The component authors can also define custom pseudo-elements to provide a way for page authors to style any presentational aspects of the binding which do not have a corresponding bound element.

Refer to the topics entitled Defining common information, Creating a binding definition, Writing binding implementations, Custom pseudo-elements, Binding policies and Glossary for further information.