Component Model Use Cases

Uses cases that represents the set of problems we are trying to solve by implementing a component model for the web. For implementation details, see XBL2 Spec.

This document is broken out into two sections: general use cases provide insight into how the component model could be used; specific constraints are interesting scenarios within the general use cases that should be treated as constraints/requirements, imposed on the specification/implementation of the component model.

General Use Cases

Custom Controls

Current practice for sizable web applications is to use JavaScript libraries to provide a system to support the construction of custom controls. Implementing these controls can be made simpler and more interoperable with runtime support.

The lifecycle of these components may differ, with some being bootstrapped from in-page markup (aka, the "decoration" pattern), whereas many use programmatic instantiation, but the former can be easily considered a superset of the latter (see "Declarative Composition" below).

The actions components support are:

• construction of the component
• configuration, often through arguments to the constructor
• view generation and configuration
• addition of the component to the visible DOM of the document
• enumeration/configuration post-insertion

Declarative Composition of Custom Controls with "Native" HTML Controls

Custom controls should be able to be declared the same way HTML elements are, using markup for demarking their location in the generated DOM, attributes for configuration and property setting, and lightweight type conversion based on attribute type. The lifecycle of markup-declared controls must be able, therefore, to host non-custom controls as children (optionally), and must participate in the DOM and layout hierarchies naturally. Existing JS-based component systems generally preserve these properties to varying degrees.

Implementing Built-in HTML Elements

Many non-trivial (i.e. with additional behavior and styling beyond the standard box model) elements that exist in HTML today could be implemented using HTML/CSS/JS. It makes sense to provide a standardized way to accomplish this, with the short-term goals of reducing the size of browsers C++ code and making new element implementation easier, and the long-term goal of converging built-in HTML element implementations across browsers.

Media Controls For The Video Element

Using DOM elements, build a media controls panel for the video element. The media controls include:

• timeline slider
• stop/start, replay, closed-captioning, forward, rewind and volume buttons, and
• a volume control, which is revealed when hovering over the volume button.

The implementation details of the media controls should not be accessible or perceptible from outside of the video element. Document styles should not interfere with the styles of the media controls panel, however we must provide a way for an author to explicitly style all parts of the media controls panel.

...

Custom Widget System

As it is today (Jan 1, 2011), pretty much every Javascript framework has a widget system (see http://jqueryui.com/, http://sproutcore.com/, http://o.dojotoolkit.org/projects/dijit, http://cappuccino.org/, http://code.google.com/webtoolkit/, http://code.google.com/closure/library/, http://www.sencha.com/ as just a few examples). All of these these widget systems are framework-specific and mostly incompatible with each other. Because the Web platform doesn't provide a well-functioning way to extend HTML elements, all of these tend to build a parallel widget space, where widget objects act as proxies to DOM objects, and the extensibility exists only within that parallel widget space. A DOM-based component model should aim to eliminate the need for this parallel space and allow widget systems to just use DOM with the goals of:

• reducing the amount of widget-space-related code written in each framework
• providing better, leak-free abstraction for widgets
• providing interoperable API to allow widgets from different frameworks to coexist and integrate.

Requirements:

• provide a uniform way (i.e. DOM) to declare widget APIs
• encapsulate widget implementation details
• enable control over how styles and events outside of a widget affect it
• enable widget styling primitives
• asynchronously instantiate and initialize widgets (for instance, display a widget without starting up a script context, then progressively enhance with script).
• allow seamless reuse a widget written using various libraries or frameworks
• allow using widgets declaratively, with minimal knowledge of the underlying implementation
• provide a way to create new widgets by extending existing widgets

Needs:

• content element (output ports)
• attachment using CSS and DOM
• separate instantiation and binding phases (or another way to allow asynchronous binding)
• attribute/pseudo forwarding
• declarative templating/binding

Could use:

• dynamic attachment/detachment
• template inheritance
• supporting form-control like behavior like "disable" HTML attribute, "form" JS property, etc.

Doesn't care:

• mutable templates
• xml:base handling

Interesting scenarios:

• Implement a "polaroid frame" widget? This widget, when bound to any element would display its contents in a Polaroid(tm)-like frame.
• Suppose the widget system has a centralized "settings" widget, with which all other widgets should communicate to add their settings. Implement this communication, provided that all widgets are opaque elements.
• Implement a "tab set" widget. As you add "tabs" to it, tab titles appear in a row at the top, and tab contents appear in the main area, only visible when the corresponding tab title is selected.