Markup Mixing Nexaweb IBM 20060726

From MemberWiki

Jump to: navigation, search

Contents

About the current version of this wiki page

This wiki page is an update to Markup Mixing Nexaweb IBM 20060712 that has been updated to reflect commitee discussion (Markup Minutes 2006-07-13).

At this point, it is primarily a historical document capturing discussion in the 13July2006 timeframe.

Terminology

namespace - For purposes of this discussion, "namespace" refers to a proper XML namespace in conformance with W3C specifications. Thus, an oa:type attribute uses a proper namespace prefix, but an oatype attribute has an "oa" prefix but this does not reflect the use of a namespace.

Background

This proposal builds on both the Alternate Hub Proposal Using XML Namespaces as well as the Tibco Dojo Proposal Toolkit Loading, Markup Mixing. This proposal is a refinement of the Alternate Hub Proposal Using XML Namespaces proposal that goes into more algorithmic and technical details.

This proposal assumes the existence of some shared OpenAjax Alliance code that is a part of the page that all toolkits know about and can use. As additional detail is added, this proposal ultimately should include enough information to allow for creation of a prototype implementation.

This proposal not only accommodates both W3C-compliant XHTML, with proper declaration of namespaces, but also accommodates the defacto HTML4 support within today's popular browsers. This proposal allows developers to choose among multiple markup approaches, some which are W3C-compliant, and others which instead focus on the most convenient approaches for making Ajax work within today's browsers. The OpenAjax Alliance's preference, which ultimately will be captured within published Best Practices, are that developers create web pages that are W3C-compliant, but developers can are free to ignore the namespace-related Best Practices guidelines and can still use the OpenAjax Hub.

This proposal supports both the "Single DOM" approach and the "Dual DOM" approach for Ajax toolkits. With the Single DOM approach, the original source markup is intermixed with other HTML, where the generated HTML for advanced UI controls is co-mingled with original HTML and/or replaces the original HTML. Dojo is one example of Simple DOM among many existing toolkits. With the Dual DOM approach, the source markup and generated HTML are separate DOM trees. XAP is one example of a Dual DOM approach.

Markup Requirements recap

  • 1: Allow existing toolkits to re-use existing syntax
  • 2: Allow the mixing/intermingling of widgets from different toolkits - multiple levels of mixed containment
  • 3: Optimize page scanning and widget creation
  • 4: Simple from an end-user perspective
  • 5: Must support both the Single DOM and Dual DOM approaches for Ajax toolkits.
  • 6: Must take into account the realities about limitations in today's browsers, such as poor XML namespace support in IE6.

Page scanning by shared OA code

(Each toolkit? | The developer?) must indicate the following to the OpenAjax Hub:

  1. Identification of those elements that the library will handle. We have agreed on the following options:
    1. ID (i.e., a list of IDs to scan)
    2. tagname
    3. toolkitprefix:tagname | toolkitprefix: (we haven't address the issue about whether we scan for a particular QName such as dojo:comboBox or a particular prefix such as dojo: or allow either)
    4. class="... value ..." (we don't have agreement on what 'value' might be)
    5. openajax:type="value" (we don't have agreement on what 'value' might be) (we don't have agreement on openajax: vs oa:)
    6. openajaxType="value" (we don't have agreement on what 'value' might be) (we don't have agreement on openajaxType vs oaType)
  2. Registers a method that will be called back when elements with that namespace [JF] those elements[/JF] are encountered.

We decided that page scanning will be under the primary control of the OpenAjax Hub, but that there would be hooks for Ajax libraries or the developer to provide custom page scanning. Except for ID scanning, the OpenAjax Hub would do a top-down, non-recursing traversal.

Recursion would be the responsbility of the handlers, who would have to restart the scanning on recursive subtrees. For example in the following snippet, the subtree rooted at <foo:ButtonBar> will be passed to the method registered for that namespace, but the <bar:FancyButton> will not be passed to a handler method. 

<foo:ButtonBar>
  <bar:FancyButton>Button label</bar:FancyButton>
</foo:ButtonBar>

It will be up to the individual toolkit handler method to recursively handle other-namespaced imbedded subtrees by calling some helper OpenAjax methods. This code should be simple boilerplate code in most cases.

A full example 

<html
  xmlns="http://www.w3.org/1999/xhtml"
  xmlns:oa="http://www.openajaxalliance.org"
  xmlns:foo="http://www.foo-toolkit.org"
  xmlns:bar="http://www.bar-toolkit.org" >
<head>
  <!-- All OpenAjax-compatible web pages would have to use a JavaScript
       library that implemented the feature set we define for our hub.
       The hub would have to be listed in the html:head before any
       references to any OpenAjax-compatible toolkits. -->
  <script src="...URL to JavaScript for OpenAjax hub..." />
   
  <!-- Each OpenAjax-compatible toolkit typically would load its 
       bootstrapping JavaScript logic within the html:head after the OpenAjax 
       hub were loaded. The initialization routines for the bootstrapping 
       JavaScript would register the same namespace prefix as was defined in 
       the root element (e.g., "foo" and "bar").-->
  <script src="...URL to bootstrap JavaScript for foo-toolkit" />
  <script src="...URL to bootstrap JavaScript for bar-toolkit" />
</head>

<body>
  <foo:ButtonBar>
    <bar:FancyButton>Button label</bar:FancyButton>
  </foo:ButtonBar>
</body>
</html>
  • 1: Toolkit A is loaded and registers a handler for the namespace identified by prefix foo
  • 2: Toolkit B is loaded and registers a handler for the namescape identified by prefix bar
  • 3: The OA page scanner detects the <foo:ButtonBar> namespaced subtree
  • 4: The OA page scanner hands this subtree off to the registered handler
  • 5: The toolkit-specific handler parses the subtree and alters the HTML DOM. Example result 
<body>
  <table>
    <tr><td>
      <bar:FancyButton>Button label</bar:FancyButton>
    </td></tr>
  </table>
</body>
  • 6: When the alteration is complete tookit A asks the shared OA code to rescan some segment of the subtree. In this example the segment inside the <td> tag
  • 7: The OA page scanner detects <bar:FancyButton> and hands that subtree off to the handler method from toolkit B
  • 8: The toolkit B-specific handler parses the subtree and alters the HTML DOM. Example result: 
<body>
  <table>
    <tr><td>
      <div>Button label</div>
    </td></tr>
  </table>
</body>

[JF] ISSUE: I believe that when we actually go public with our documents, we should show examples of non-destructive techniques where the original markup is preserved, versus the above example, where the original markup is clobbered by the generated HTML. We probably need multiple examples. Maybe there should be a Single DOM example that shows non-destructive techniques with a <div oa:type="..."> that is preserved after toolkit processing (although child HTML elements might be added to the <div>), and then a Dual DOM approach where the original XML is stored somewhere else. My guess is that we will reach consensus that best practice for Ajax toolkits is to preserve original markup somehow or other, in which case our examples should reflect these best practices.[/JF]
[LS] To what extent do most toolkits preserve the pre-processed xml now? Most offer the value of manipulating the DOM and offer APIs for scripting against new elements as opposed to the original ones. Maybe this is an issue we can debate in the meeting today? I don't see any great value in preserving the original xhtml in the case of widget containers for instance.[/LS]
[JF] Response to Lindsey: I don't know the extent to which toolkits preserve original content today, but it is clear that at least some toolkits do a reasonable job of preserving original markup. XAP has preservation of original content as a first-order design requirement. Dojo is generally non-destructive with original markup. In one usage scenario, Dojo will use empty DIV elements where all Dojo parameters are attributes on the DIV. The generated HTML is attached to the DIV as child elements. In a sense, the child element are "rendering shadow tree" for the DIV. The Dojo approach has good alignment with Mozilla and W3C work with XBL, and most likely XBL was studied when Dojo's approach was defined. Note that alternatives to Ajax, such as XAML and MXML, are non-destructive with the original markup objects.[/JF]

Rationalization for lack of automated recursive scanning

The lack of automatic recursive scanning is the responsibility of the individual toolkits for a few reasons.

  1. Certain toolkits may not play nicely with widgets from other toolkits imbedded within them. These toolkits can simply not parse the imbedded namespaces or throw some error/warning/exception.
  2. There may be timing/ordering of operations issues.
  3. The toolkits know more than the OA shared code about how they manipulate the HTML DOM. For example in an extreme case they may alter parts of the DOM not related to the current subtree at all, which then may also need to be scanned for namespaced subtrees. They may also scope down the area that needs to be scanned, by for example tracking imbedded content during their own parsing routines.

Open issues

  1. The exact mechanism that toolkits register namespaces and handlers for them. (Some simple shared OA code)
  2. The exact details of the scanning algorithm. [JF] ISSUE: Just how flexible do we have to make the hub in how it scans the document? The simplest approach would be that the hub does a simple one-pass top/down traversal of the whole document, examining each element according to criteria (e.g., prefix/namespace of each element, QName of each element, and the value of a well-known OpenAjax special attribute. But there are infinite ways to complicate this, such as allowing toolkits to interpose just before or just after another toolkit processes an element, or scanning for a particular toolkit's elements before another toolkits elements.[/JF][JF] RESOLUTION: During committee discussion, the conclusion was that the default scanning method would be a simple one-pass top/down traversal, but that other (potentially faster) options would be available to the developer.[/JF]
  3. Unified mechanism to deal with toolkits that do not imbed well in others, or that do not handle imbedded toolkits well.[JF] We haven't gotten to this issue yet in committee discussion, but my thinking is that we shouldn't worry about toolkits that have yet to embrace OpenAjax, except that we should strive to minimize barriers to OpenAjax adoption by requiring as few changes as possible to existing toolkits.[/JF]
  4. [JF] The exact set of XML namespace support we can use successfully across popular browsers today. It appears that custom elements such as <foo:bar> do not work reliably in IE6 -- see http://archive.dojotoolkit.org/nightly/tests/namespaces/test_myns.html. What about namespaced attributes, such as oa:type="..."? Or do we need to throw in the towel there, also, and use a naming convention such as openajaxType="..."[/JF]

These issues are probably best ironed out in prototype code creation.

Markup Requirements check

  • 1: Allow existing toolkits to re-use existing syntax
    • Yes other than that the root tag of a toolkit-specific subtree must have either a namespaced tag or an oa:type attribute on it. All other syntax remains the same.
  • 2: Allow the mixing/intermingling of widgets from different toolkits
    • Yes at the markup level. Work may still have to be done to ensure toolkits play nicely with event handling, layering, etc.
  • 3: Optimize page scanning and widget creation
    • Page should only be scanned once regardless of number of toolkits used. Page can be scanned only in part if page author specified specific element IDs to look for.
  • 4: Simple from an end-user perspective
    • Does not require much from user other than use of namespaces and/or oa:type attribute. Very little extra code or markup required
  • 5: Must support both the Single DOM and Dual DOM approaches for Ajax toolkits.
    • I believe there are adjustments that we need to make to this document to support Single DOM.
  • 6: Must take into account the realities about limitations in today's browsers, such as poor XML namespace support in IE6.
    • I believe there are adjustments that we need to make to this document to support Single DOM and the deficiencies in current browsers regarding XML Namespace support.
Retrieved from "http://www.openajax.org/member/wiki/Markup_Mixing_Nexaweb_IBM_20060726"
Personal tools