XBL Support for all Browsers via dojo.E
July 29th, 2008 by Bob BuffoneOne of the goals of the dojo.E project has been to bring some of the standards created by the W3C and others to developers for building their Ajax applications. A couple of weeks ago, I saw on Ajaxian.com that Firefox and Webkit are going to support XBL. Simply defined, the XML Binding Language or XBL is a way to create reusable components.
“The XML Binding Language (XBL) describes the ability to associate elements in a document with script, event handlers, CSS, and more complex content models, which can be stored in another document. This can be used to re-order and wrap content so that, for instance, simple HTML or XHTML markup can have complex CSS styles applied without requiring that the markup be polluted with multiple semantically neutral
divelements. ” - XBL Specification Quote
This is not the first attempt at developing a way to create reusable components. Sergey Ilinsky has also created an XBL library that works independently of any Ajax library.
Looking into this more and reading the specification a dozen times, I thought it was a good way to allow Ajax developers to build reusable widgets. Dojo already provides dojo.Declare and dojoML as ways to declaratively create widgets, event handlers and methods; however, these are specific to the dojo toolkit and do not lend themselves to other implementations. Other companies have created their own declarative languages for creating reusable components inside of their specific engines.
- Google - Google Gadgets
- Microsoft - Windows Live Gadgets
- …
Each of these is similar yet different enough that developers have to learn multiple languages and develop applications more than once to support each platform. This is where standards come in.
Standards aren’t perfect:
How could they be. Standards are developed in a committee format by people with diametrically opposed interests (political, corporate) and ideas. What they typically achieve however is something that many people are able to leverage en mass once the standard is put into play. HTML, CSS, JavaScript are all Open Web standards that people take full advantage of to create many things. Google announced that it accesses a Trillion Web links; search for HTML on Google and 11 billion documents are found. Are the Open Web standards perfect? Nope, but they don’t need to be, they can be flawed as long as they are open and flexible.
Why do this?
For a while I used to wonder: What is the W3C doing? I am still using mostly old things to create applications. Then I started to dig into more of what the W3C has specified and found that there are many things there that could be useful to many developers if they were just put into play. XBL is one of them, but XML Events, XForms and SVG are all things that can provide great value to the Open Web community if a bunch of Ajax toolkits get together to support them. Without the support of the Ajax community, it will be difficult to move these things forwards. Browser vendors can’t add support for these into old browsers. They must be supported either at the client tier or the server tier. Otherwise, Webkits support for XBL will only be useful to iPhone Developers.
Problems with the Toolkit/Library approach:
First, it will be impossible to “fully” support the specification. Most specifications are written from the “User Agents” (UA) or client applications (browser, email, search engine and so forth) point of view. An Ajax library can’t perform much of the “UA” functionality.
Recommendation to the W3C: When developing Open Web specifications, take into account that Ajax libraries may be developing the first implementation of the specification and that these can’t meet all the requirements and so provide another draft such as “Implementing Library” or “IL” that allows a clean degradation of the requirements.
This is the biggest issue with implementing the specification: that a developer can’t support everything in there 100%. And this can then lead people to very easily dismiss the approach despite its potential usefulness.
An Example of this in the XBL implementation:
The XBL specification states: “Shadow trees are hidden from normal DOM processing (hence the name “shadow”); they are not accessible via Core DOM navigation facilities such as firstChild or nextSibling. (See: shadow content.) “
Yet, in practice, I cannot force a browser to not include the content of the shadowTree in its DOM.
Dojo / dojo.E and XBL:
The implementation of XBL in Dojo and dojo.E was quite simple after I figured out what I needed to support. The dojo.E processor is very flexible and allows me to add processors for top level nodes and user interface namespaces. The implementation hooks into the processor in three places:
dojoe.registerNodeProcessor("xbl", dojoe.xbl.processorXblNode);
dojoe.uiProcessor.registerNsHandler("http://www.w3.org/ns/xbl", function(node){});
dojoe.uiProcessor.registerNsHandler("http://www.w3.org/1999/xhtml", function(node){});
Now that we are all hooked in, we are able to create and process any XBL document that is:
- loaded through the dojoe.xbl.loadBindingDocument(); or
- embedded into the HTML page using the <script type=”text/xml” dojoType=”dojoe.XmlScript”> tag
“hack”trick.
The processing is done simply be iterating over the different level of nodes and doing what is required:
for (childNodes){
var nodeName = childNodes[i].getNodeName();
if (nodeName == “implementation”){
}
}
The Dojo framework provides most of what was needed to implement XBL: Event Connection, Widgets, Querying, other. dojo.E just needed to wire the XBL specification to dojo. The current version is only a partial implementation; there is still some work to do in the event handlers area as well as with fully supporting the interface.
What actually Happens:
When the XBL document is processed, a Binding object that understands the parts of the binding is created for each “binding” tag. When the time comes to connect the binding to the HTML DOM, a “dojoe.xbl.BindingWidget” is created and the “template,” “implementation,” “resources,” and “handlers” are added to the widget.
The binding boils down to a dojo Widget. Thus, a developer can load XBL documents and attach them using:
new dojoe.xbl.BindingWidget({bindingId:"CustomLoginScreen"}, htmlNode);
One of the cool things about this is that anything in the implementation block is evaluated and is added to the widget:
<implementation>
<![CDATA[
({
red: function() {
var nodes = this.query("img");
for (var i = 0; i < nodes.length; i++){
nodes[i].src = ‘red.png’;
}
dijit.byId(”myButton”).setLabel(”Green”);
},
…
})
]]>
</implementation>
this allows the function “red” to become a function of the Widget and for it to be called from anywhere (dijit.byId(”widgetId”).red();)
XBL Samples, Code, and Documentation :
I have created several example applications that allow you to see a demonstration of how to utilize the dojo.E XBL engine. This is just the first implementation of the code, samples, and documentation. More will be coming. Until then, ask any questions you might have in the dojo.E forum.
Example Applications
- Flickr Sample - Creates a flickr widget that can be added to a Web page with the ability to customize the search parameters.
- Login Screen - Creates a login screen that is created as a dojo Widget.
- Watermark - Shows interoperability between the dojo.E implementation and another XBL implementation.
Zip File
The zip contains everything that is needed to create and use XBL in a dojo.E application. Click here for the document.
SVN Repository
Look at the repository to get the raw resources for the XBL implementation and test applications. Click here for the SVN Repository.
XBL Specification Recommendations for future versions:
- Allow developers to specify a “target” attribute on the “handlers” tag. This is allowed in the XML Events specification but not here. Without it here, it becomes difficult to use the handlers functionality, since, although the handlers functionality makes it easy to connect events, it only works on the outer element. To get around this, you could create multiple bindings, but it seems like overkill to do that just to handle a sub component’s events.
- Allow developers to use a query string in the binding element to specify where the binding goes. Now it is done external to the using CSS, but not from the binding itself. Although the following may not be best practices, doing this would make the binding definition self contained. <binding target=”input[type='text']“></binding>
Conclusion:
One thing that is lacking in the Ajax world is a portable way to create reusable widgets. XBL could be the way to achieve this or perhaps there is some other specification that could be implemented by the major Ajax libraries. A method of creating a widget that could be used by any library would create a truck load of widgets available to all developers. Still, there are other things that need to be solved before this could happen:
- Standardization of the CSS querying.
- Standard DOM modification layer.
- Standard way to connect to events.
- … (I am sure I missed one).
Even with these issues, it is possible to create widgets that can run on any Ajax Library. Last year I created a simple Ajax Library Independent Ajax Library (that was a mouth full) where this worked.
Other things that would be cool: To implement this in Jaxer and allow developers to create server-side Ajax widgets. Jaxer could perform all the consolidations and injection of the bindings on the server-side, this way the HTML for the bindings would be integrated into the HTML when the browser received the page. XBL would also be a good way to create reusable widgets that could be placed in a Mashup framework. More to come on this topic as well as a more robust implementation of the standard.
Bob (Buffone)
|
|
