Dojo

Markup-based page processing (DojoML)

Dojo has a two-phase parser which passes through the document looking for widgets declared using three different styles of declaration:

<div dojoType="optionalns:widgetname">

and

<optionalns:widgetname>

and

<div class="dojo-widgetname">

The second is XHTML-like but designed to work in vanilla HTML documents without any special requirements. Unfortuantely, right now this is known not to work well in IE. See the explanation here: http://dojo.jot.com/XmlNamespace

Widgets can also be instantiated from JavaScript using dojo.widget.createWidget()

The widgets themselves are extensible and use a templating system to generate content which is inserted in place in the browser DOM, mixed in with the original markup. Within the widgets, attributes may be used to pass sets of values as arrays or hashes, and also templated data using ${} syntax. The markup associated with this tag may be bound directly with events to the widget implementation such that changes to the DOM are live and in synch with the UI.

Other JavaScript-based page processing

While not really page processing, Dojo provides a number of JavaScript-level utilities, such as event binding and aspect-oriented style binding, a "package loader" with pseudo Javascript namespaces (dojo.widget.Foo) etc. The package loader does not scan the document itself, but does introduce code via dojo.require() into the document using XHR + eval, sort of like a dynamic <SCRIPT> tag. This script loading mechanism recursively loads code as necessary and works in conjunction with a build system which is able to provide built "profiles" to pre-load subsets of Dojo code in a single dojo.js file to avoid the latency associated with this feature. There is also a cross-domain loader which is able to load Dojo "classes" from network or edge servers, such as AOL's CDN.

Script.aculo.us and Prototype (ACTION: Greg Murray)

Processing Model topic 1

Loading of Prototype and Script.aculo.us

prototype is initialized by writing a top level script element with the source to a prototype.js file.

The prototype.js will:

Create a top level Prototype object with a respective version number (currently 1.5.0_rc0.

Update the prototype behavior of a few core JavaScript objects with behaiour such as the following:

'Object' with a function providing inheritence

'Class' with a create method for instance creation,

'Function'with a bind as listener property.

'String' with various utility functions

'document' getElementsByClassName

Places some global utility functions such as

$() for looking up document elements

$F() for locating form elements

$A() to allow for array objects to be quickly created.

etc.

Add some default objects

Ajax - For default AJAX style interactions

Ajax.PeriodicUpdate

Ajax.Updater

etc.

The Prototype library should only be loaded once a page is loaded and the default prototype.js library needs to be loaded before any extensions such as Script.aculo.us as the Prototype library uses building block like architecture to layer one level of functionality on top of another. Scriptaculo.us depends on the core functionalites added by the Prototype library and thus will load Prototype if it does not find the correct version it depends on. In the case of Script.culo.us 1.6.3 it depends on Prototype 1.5.0_rc0.

Script.aculo.us Loading

When the scriptaculous.js is loaded it creates a Scriptaculous global object which provides the namepace for all objects related to Scriptaculous. When this object is initialized it will look to see if the Prototype library if version 1.5.1. If Prototype has not been loaded or an older version of prototype has been loaded an exception with the relevant message will be thrown.

Script.aculo.us will load its dependencies using a document.write. Dependnecies include builder, effects, dragdrop, controls, and slider which are all found in separate files prepended by '.js'. Because of this design Script.aculo.us can not be loaded dynamically at runtime and it needs to be loaded using a top-level script element when the page is loaded. After these files are loaded the load function on the Scriptaculous object will be called to do further initialization of the dependent libraries.

Creating new widgets using Script.culo.us

Prototype type and Script.aculo.us objects are created programtically by passing in a <div> into which HTML content is injected. For Example:

In summary Prototype as a library focuses on adding functionality/behavior to the default JavaScript objects and adds a few utility functions as well. This could be an issue if other libraries attempt to update or rely on the default JavaScript behavior of the same objects. As the Prototype library is the building block for its dependent libraries such as Script.aculo.us it needs to be loaded first. Script.aculo.us uses document.write for its dependencies so it needs to be loaded as a top level script element. Widgets are created programatically.

? Processing Model topic on postbacks vs standalone ?

OAT - OpenLink AJAX Toolkit (ACTION: Ted Thibodeau)

Processing Model topic 1

text for this topic

Processing Model subtopic

text for this subtopic

? Processing Model topic on postbacks vs standalone ?

text for this topic

Spry (ACTION: Kin Blas)

Processing Model topic 1

Spry is targeted at Web Producers/Designers and will provide support for:

AJAX - Updating portions of the page dynamically.

Widgets - Converting existing markup into widgets.

Effects - Fades, sizing, movement, etc.

Currently, Spry is completely client-side and requires that users manually include script tags that loads the JS file which provides support for what they will use on the page, so JS files are not loaded "on the fly". Spry tries to make each file completely standalone to remove the guess work needed by the Designer to extract just what they need from the framework distribution for placement on their site.

With the exception of the xpath.js (Google's XPath implementation), all objects created within Spry are namespaced.

AJAX Support

Support for AJAX comes in the form of Data Sets and Dynamic Regions. Users must first include 2 JS files within the head of their document, declare the data sets that they intend to use, and then provide the markup to use for each region of the page.

During the loading/processing of SpryData.js, an onload handler is registered, using addEventListener()/attachEvent(). This allows Spry to run through the document, identify the dynamic regions and fire off the commands necessary to load the data sets and re-generate all dynamic regions on the page.

Widgets

The idea behind widgets is very similar to the OpenRico approach. That is, start with basic markup and make a single JS call that attaches widget behaviors to that markup. Unlike other frameworks, additional markup is *not* injected into the page. Each widget relies on a single JS file to provide all the functionality for that widget.

The widgets currently supported in the Spry framwork do not depend on an onload event handler, though it is possible for a user to register one and make the call to the widget constructor from their onload function instead of including a script block below each widget markup section.

Effects

Like Scriptaculous, effects are triggered by creating an effects object with a single line of JavaScript. Users must first include SpryEffects.js before attempting to use any effects.

? Processing Model topic on postbacks vs standalone ?

XAP

Background and Variable Scoping

XAP is primarily aimed at making entire web applications, not creating individual effects or widgets. XAP relies on other toolkits to provide UI widgets while wrapping them in a uniform syntax XML.

XAP currently registers two top-level variables "xap" and "google" (which corresponds to Googles XPath implementation hacked up a bit). XAP can be extended to include other widget libraries, so these additional libraries may also define their own top-level variables. For example current XAP examples include Zimbra components, Dojo components and Google gMap components. The out-of-the-box, default configuration should define few if any top-level variables other than "xap" and "google". (The latter of which may go away) Similarly any page scanning that individual toolkits do should be turned off by default.

Processing Model

XAP applications are defined in pure XML. Not XHTML or HTML. This XML can be included in an HTML page in two ways:

With a logical pointer to a separate pure XML file. This pointer is an attribute on some HTML element.

By imbedding the XML directly in the page. (Some restrictions apply)

When the initial page is loaded, the body is scanned for either XML file pointers or imbedded XML. That XML is then either loaded from file or read from the HTML DOM and placed in a separate XML DOM. If the XML was imbedded directly in the HTML that XML may be removed. (It's not 100% clear yet, at that point it serves no real purpose - up for debate among XAP devs)

Subsequent changes to the XAP application are made by changing the XML DOM, not the HTML DOM. These changes to the XML DOM are then realized on-screen as changes to the HTML DOM. A key difference here is that the XML DOM represents higher level contructs typical in application development, such as toolbars, splitters, etc.

The XML DOM is the model for a XAP application and the HTML DOM is the view - a strict separation. The original XAP markup can be included directly in HTML as a matter of convenience and efficiency only. This is in contrast to many toolkits where the HTML document contains original markup which is then morphed into markup that implements the onscreen view, while the orginal markup is lost or altered.

Executive Summary

XAP should play pretty nicely with other top level variables and processing methods. It does include a page scanner, although it is unlikely that HTML pages would be scanned by both XAP and other toolkits given the slightly different aims of the XAP project and the fact that XAP allows for widgets from different toolkits. It should play nicely with the proposals being presented currently around event hub/markup mixing.