A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.
To request an account, ask an autoconfirmed user on Chat (such as one of these permanent autoconfirmed members).
Behavior Attachment: Difference between revisions
Line 19: | Line 19: | ||
|- valign="top" style="border-bottom: 1px solid LightGray;" | |- valign="top" style="border-bottom: 1px solid LightGray;" | ||
| align="right" | [http://code.google.com/webtoolkit/ GWT] (Google Web Toolkit) | | align="right" | [http://code.google.com/webtoolkit/ GWT] (Google Web Toolkit) | ||
| Also uses parallel object hierarchy to shield the user from behavior attachment deficiency, relying on [http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/gwt/user/client/ui/Button.html inheritance] | | Also uses parallel object hierarchy to shield the user from behavior attachment deficiency, relying on [http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/gwt/user/client/ui/Button.html inheritance] for compartmentalization and reuse. | ||
|- valign="top" style="border-bottom: 1px solid LightGray;" | |- valign="top" style="border-bottom: 1px solid LightGray;" | ||
| align="right" | [http://jqueryui.com/ JQuery UI] | | align="right" | [http://jqueryui.com/ JQuery UI] | ||
Line 28: | Line 28: | ||
|- valign="top" style="border-bottom: 1px solid LightGray;" | |- valign="top" style="border-bottom: 1px solid LightGray;" | ||
| align="right" | [http://www.sencha.com/ Sencha] | | align="right" | [http://www.sencha.com/ Sencha] | ||
| | | Complete isolation from DOM with a Javascript objects as proxies, simple [http://dev.sencha.com/deploy/ext-4.0.2a/examples/form/combos.js inheritance model] (even maps ids of the underlying DOM elements to the variable names). | ||
|- valign="top" style="border-bottom: 1px solid LightGray;" | |- valign="top" style="border-bottom: 1px solid LightGray;" | ||
| align="right" | [http://www.sproutcore.com/ SproutCore] | | align="right" | [http://www.sproutcore.com/ SproutCore] |
Revision as of 21:56, 7 July 2011
WORK IN PROGRESS
- element is DOM element.
- content is DOM content.
- document is HTML document
Behavior Attachment in the Wild
HTML, as exists today, does not provide an organized model of attaching behavior to a DOM element. While you can add individual scripting methods, properties and event handlers to it, there is no way to do this atomically and with proper encapsulation.
This deficiency is addressed at a library level, with every Javascript framework attempting to solve this problem. Here is a quick overview of approaches:
Library | Behavior Attachment Implementation |
---|---|
Dijit (Dojo's UI Library) | Creates a parallel object hierarchy to create illusion of homogenous object space, with full wrappers around DOM objects. Relies on inheritance-style approach by assigning each DOM element a dojoType attribute in markup, then traversing DOM and attaching corresponding behavior. |
GWT (Google Web Toolkit) | Also uses parallel object hierarchy to shield the user from behavior attachment deficiency, relying on inheritance for compartmentalization and reuse. |
JQuery UI | |
Prototype | Uses prototype inheritance chain to bestow new properties/methods on a DOM element. The changes are purely additive and imply permanent change in context of document’s lifetime. |
Sencha | Complete isolation from DOM with a Javascript objects as proxies, simple inheritance model (even maps ids of the underlying DOM elements to the variable names). |
SproutCore |
Comparison Between Decorator and Element Behavior Attachment
Decorator | Element | |
---|---|---|
Purpose | Give existing content new behavior and/or appearance. | Create new content building blocks. |
Paradigm | Aspect-Oriented Programming | Object-Oriented Programming |
Compartmentalization and Reuse Vehicle | Aspect | Inheritance |
Symptoms |
|
|
Examples of Use |
|
|
Identity | Does not change the identity of the element. | Creates a new type of element. |
Lifetime | Transient, added and removed dynamically. | Permanent, originates with the element’s creation and exists through the lifetime. |
Environment | Foreign document or limited control of content. | Full control of content. |
Defining Traits |
|
|
Shadow Tree | Each decorator must have its own shadow subtree, and the aggregate shadow tree of an element is composed out of these subtrees. | Only one tree, initialized as the element is created. Inherited shadow trees can be reused, nested in the element's tree. |
DOM API | Should avoid adding any extra methods or properties to the DOM element that’s being decorated. | Explicitly interested in exposing methods or properties on the DOM element as its API. |
Inheritance and Shadow DOM
What if an inherited element already has a shadow DOM subtree? In this case, the descendant has two options:
- Use
inherited
element. The inherited DOM subtree will be inserted in place of this element. Neither descendant nor ancestor will be able to access each other's subtrees. - Disregard the inherited shadow subtree. The inherited DOM subtree will still be created and continue to exist, but it will not be rendered (a "ghost tree"). This is necessary to ensure that the ancestor element's behavior is not affected with override.
Interaction of Element and Decorator Behavior Attachment
Since both behavior attachment models can exists in the same document, we must provide a way for the two to coexist on the same element.
- When a decorator is applied with an element with a shadow DOM subtree, the element subtree is treated as inherited.
- Order of
content
application: thecontent
elements contained in the inherited shadow DOM tree are applied last. This way, if both descendant or decorator claim a direct child, it will appear to the inherited tree as if there's nothing there.
Progressive Enhancement and Behavior Attachment
Progressive enhancement technique is a great example of an existing technique which would benefit greatly from element behavior attachment. This technique originates from the assumption that markup contains the base semantics, and these semantics are then extended with DOM scripting. It’s a nearly perfect explanation of the problem that element behavior attachment is trying to solve, where markup are elements and DOM scripting is the behavior.
Analysis of Existing Specifications and Implementations
What does XBL2 do?
- There are two ways to bind: using binding element (inline or via external document) and using CSS. The former somewhat matches the notion to be element behavior, and the latter is the decorator behavior. However, there is no distinct difference in the attachment mechanism.
- Inheritance is entirely self-contained, using “extends” attribute. However, the prototype chain of the implementation object is fixed up to follow inherited bindings.
- There is a fair bit of machinery specified to marry the aspect and inheritance concepts seamlessly.
- There is no notion of extending DOM elements.
What does XBL1 do?
- There does not seem to be a separation between these two decorator and element behavior attachment. The http://mxr.mozilla.org/mozilla2.0/source/toolkit/content/xul.css seems to indicate the need for element attachment.
What does HTC do?
- HTC does not have the concept of shadow DOM, but the specified behavior is firmly an element behavior attachment.
What does sXBL do?
- It appears that the spec is abandoned, but the gist is similar to XBL2, except there is only one shadow tree, direct access to shadow subtree, and a binding model that seems to indicate element behavior attachment, but using decorator API.