[OpenAjaxIDE] IDE Issue 1: Toolkit identification, configuration, loading, and initialization

Jon Ferraiolo jferrai at us.ibm.com
Thu Dec 13 10:28:54 PST 2007

I updated the proposal at the bottom of ISSUE 1 to reflect the discussion
at today's phone call:


In particular:

* Added a note that says that elements that are inserted into the document
must be inserted in the same order as the <require> elements
* Added a new attribute sandbox="true|false"
* Changed head="auto|true|false" to "includeRef="auto|true|false"
* I cleaned up some of the wording


             Park/IBM at IBMUS                                             To 
             Sent by:                  ide at openajax.org                    
             ide-bounces at opena                                          cc 
                                       Re: [OpenAjaxIDE] IDE Issue 1:      
             12/13/2007 07:51          Toolkit identification,             
             AM                        configuration,     loading, and     

At the Gadgets TF meeting yesterday, we looked at the IBM Widgets proposal:

* http://www.openajax.org/member/wiki/IBM_Widgets_proposal

where there is (what I think) an interesting idea for how to address some
of the problems associated with this issue. Here is a snippet:

<widget xmlns ="http://openajax.org/widget" ...>
<require library='dojo' version="0.9">
      "parseOnLoad: false, isDebug: true, extraLocale: ['en-us', 'ar-sy',
'es-es', 'zh-cn']"

This has some similarities with Adobe's <assetfile> and Jonathan's
<resource>, but I like a couple of particular things with the above
proposal. First, it is explicit in its name by saying that the key semantic
is that it is identifying a resource that is *required*. Second, it bundles
any customization information (i.e., <config>) with the resource reference.

Also, we need to take into account the fact that some leading
mashup-oriented gadget formats, such as Google Gadgets, only allow you to
identify the snippet that belongs in the BODY (but not the HEAD), whereas
others, such as Apple Dashboard, have you provide an entire HTML file that
can include the HEAD.

Here is a derivative proposal that builds on the above:

<widget xmlns ="http://ns.openajax.org/widget" ...>
<require [type=""] [name=""] [min_version=""] [src=""] [target=""]
      parseOnLoad: false, isDebug: true, extraLocale: ['en-us', 'ar-sy',
'es-es', 'zh-cn']

* 'type' is an an enum: library | javascript | css | xsl | folder | other
(we can add other options in the future) where
** 'library' indicates an Ajax library. If provided, then either ('name'
and 'min_version') or ('src') must be provided. If ('name' and
'min_version') are provided, then look to the OpenAjax Registry to find the
'src' for the standard download place for the given library. (Note that
there are three options to reference a library such as Dojo. Either use
<require type="library" name="dojo".../> or <require type="javascript"
src="../lib/dojo1.0/dojo.js"/> or if the widget system allows for complete
HTML files (as in Apple Dashboard) then simply include a <script
src="../lib/dojo1.0/dojo.js"/> line in your HTML file.)
** 'javascript' indicates a single JavaScript file that is needed by the
** 'css' indicates a single CSS stylesheet file that is needed by the
** 'xsl' indicates a single XSLT stylesheet file that is needed by the
** 'folder' indicates a folder whose entire contents are needed by the
** 'other' is for other single file resources such as images that need to
be deployed
* 'name' - see 'library'
* 'min-version' - see 'library'
* 'src' holds the relative URL for the given resource, where the base
folder is the location of the widget metadata file
* 'target' holds the relative URL within the deployed package where the
resource should be placed. Defaults to the same as 'src'.
* 'head' is an enum that says whether the resource needs to be referenced
at the top of the document (in HTML, within the HEAD):
** 'auto' requires a complete definition, but here is a start. For 'css',
'xsl' and 'javascript', auto=true. For 'folders' and 'other', auto=false.
** 'true' says that the given resource must be included in the HEAD. (Tools
SHOULD notify the user if there the given request cannot be performed.)
** 'false' says that the given resource must not be included in the HEAD.

If unsufficient attributes are provided for the tool to understand what it
needs to do (e.g., the <require> element has no attributes at all), then
the tool SHOULD notify the user.

I added the above proposal to the bottom of Issue 1:
* http://www.openajax.org/member/wiki/IDE_Issue_1


Inactive hide details for Jon Ferraiolo/Menlo Park/IBM at IBMUSJon
Ferraiolo/Menlo Park/IBM at IBMUS

                         Park/IB                                        To 
                         M at IBMUS                                           
                                          ide at openajax.org                 
                         by:                                            cc 
                         nces at op                                           
                         enajax.                                   Subject 
                                          [OpenAjaxIDE] IDE Issue 1:       
                                          Toolkit identification,          
                         12/05/2          configuration, loading, and      
                         007              initialization                   

URL: http://www.openajax.org/member/wiki/IDE_Issue_1

IDE Issue 1: Toolkit identification, configuration, loading, and

Original write-up

Most of the widgets that we are looking to use with IDEs are built on top
of an Ajax toolkit. For example, in 3 early samples, we looked into the
date picker widget (built on Dojo), a menu widget (built on YUI), and a
Google Map widget (built on Google-developed JavaScript). In most cases,
one or more Ajax libraries need to be sourced into the HTML application via
a <script> tag and (in some cases) some sort of library configuration and
initialization must occur for the widget to work properly when deployed
with the HTML page.

The question is what information will we include within our IDE standards
around toolkit identification, configuration, loading and initialization.
On one extreme, we could decide to steer clear of defining any standards in
this area and decide that the various IDEs must take care of this somehow
or other. On the other extreme, we could decide to define an industry
standard for how widgets identifier the Ajax libraries that they need and
how those libraries are configured, loaded and initialized.

Existing industry practice

jMaki's widget.json file includes a config property that provides
information about toolkits and how they should be initialized. Here is a
snippet from the information within jMaki for the Dojo date picker widget:

    'config' : {
        'type' :
         { 'id' : 'dojo',
           'libs' : [
             'preload' : 'if (typeof djConfig ==\'undefined\') djConfig = {
parseWidgets: false, searchIds: [] };',
             'resources' : [

The jMaki engineers need to explain this in more detail, but a good guess
is that libs: points to the root JavaScript file to load for Dojo, preload:
provides configuration settings that are used once the Dojo file is loaded
via a dynamic <script> tag, and resources: is the root folder for finding
other resources needed by Dojo.

Adobe Dreamweaver proposes an <assetfile type="javascript"
location="<url>"> tag to identify JavaScript files that need to be loaded.

Complexities that we might want (or not) to address

Here are some sub-issues about various complexities that we might want to
                        Shared use of Ajax libraries - If two widgets use
                        the same Ajax library, we might want to (or in fact
                        need to) ensure that the Ajax library is loaded
                        only once and that the two widgets share the same
                        instance of the given library. This begs the
                        following question:
                                                What happens if widgets use
                                                different variations of the
                                                same Ajax library? -
                                                Suppose one widget requires
                                                jQuery 1.5 and another one
                                                jQuery 2.3 and there is a
                                                major incompatibility
                                                between jQuery 1.x and 2.x.
                                                Suppose one widget ships
                                                with a custom version of
                                                Dojo 1.0 that only supports
                                                the features needed by that
                                                widget and another widget
                                                uses a different custom
                                                version of Dojo. (Most
                                                likely we will have to have
                                                some reasonable behavior
                                                rules on Ajax toolkits,
                                                such as what we see in the
                                                introduction chapter to the
                                                OpenAjax Hub 1.0
                        Dynamic loading standards for Ajax libraries -
                        There have been at least two recent proposals to
                        OpenAjax Alliance about having us define a standard
                        JavaScript loader. OpenAjax Alliance hasn't taken a
                        run at that issue yet.


It seems like an IDE loses much of its value as a visual UI tool if it
cannot automatically insert <script> tags for the necessary Ajax libraries
automatically into the Web page on behalf of the user. (Same argument for
other resources such as <link> tags pointing to CSS files.) For a
reasonable user experience, one would hope that a user does not need to do
any more than:
                        Identify an Ajax library that they want to use with
                        their application, and thereby have the IDE make
                        all of the widgets from that library available to
                        the user
                        Import specific widgets from that library into the
                        HTML document, such as via drag-and-drop
                        Customize those widgets, such as with a property
Therefore, due to a strong user requirement, we are strongly inclined to
provide some automation in the area of automatic loading of Ajax libraries
from within the IDE.

Many common Ajax libraries have an architecture that would allow some level
of automation in this area. It is common that a library has a base set of
JavaScript such that it is possible to:
                        first load the base set of JavaScript for a given
                        then load the specific JavaScript for each widget
                        used on the Web page
(Note: some Ajax libraries have packaging features, such as dojo.require,
that allow consolidation of JavaScript into a single file.)

Both jMaki and Dreamweaver have had some degrees of successful with popular
Ajax libraries in this area.

Given the strong benefit to the user and the fact that many Ajax libraries
have a reasonably desirable architecture in this area, it seems like we
should pursue standardization.

Alternative approaches

Strawman widget metadata

The strawman proposal simply identifies a library by name and version.


jMaki widget metadata

jMaki identifies the library by name and points to the JavaScript files.
jMaki also includes configuration information (i.e., djConfig).

    'config' : {
        'type' :
         { 'id' : 'dojo',
           'libs' : [
             'preload' : 'if (typeof djConfig ==\'undefined\') djConfig = {
parseWidgets: false, searchIds: [] };',
             'resources' : [

Adobe Dreamweaver metadata

Adobe proposes an <assetfile location="..." referenceType="javascript"/>
tag to identify the JavaScript that needs to be loaded"

  <!--  the following asset files will get copied to the users's site when
they save their document and the paths will be adjust to point to them -->

  <!-- Specifing referenceType (link, import, or javascript) will create a
reference to the associated asset file in the <head> -->
  <!-- not specifying a referencetype copies the file but adds no reference
to it -->
  <assetfile location="yui/2.3.1/build/menu/assets/skins/sam/menu.css"
  <assetfile location="yui/2.3.1/build/fonts/fonts-min.css"
destination="yui/build/fonts/fonts-min.css" referenceType="link"/>
  <assetfile location="yui/2.3.1/build/yahoo-dom-event/yahoo-dom-event.js"
  <assetfile location="yui/2.3.1/build/container/container_core-min.js"
  <assetfile location="yui/2.3.1/build/menu/menu-min.js"
  <assetfile location="yui/2.3.1/build/menu/map.gif" />

Jon's proposed resolution

Specific recommendations:
                        Only focus on workflows where there is only a
                        single version of a given Ajax library used within
                        a particular HTML page. For example, our primary
                        target workflow would be situations where the
                        entire page uses a single version of a particular
                        library (e.g., Dojo 3.1 or YUI 1.9), but don't
                        attempt to define metadata markup that address the
                        ability to mix Dojo 0.4 widgets with Dojo 1.0
                        widgets. Assume that if a user needs a new widget
                        from a newer version of a given library (e.g., Dojo
                        1.0's grid widget), then the user has to upgrade
                        the entire page to the newer version of the
                                                NOTE: By saying only focus,
                                                that just means where we
                                                focus. It doesn't
                                                necessarily mean that we
                                                don't allow other
                        Choose a markup approach similar to Adobe's
                        <assetfile> that lists various widget-specific
                        files (including the library's core JavaScript)
                        that need to be loaded within the <head> of the
                        HTML page. The idea is that, in general, each
                        <assetfile> would result in the addition of a
                        single line of code to the HTML page, such as a
                        <script> tag or <link> tag.
                                                NOTE: This simple approach
                                                neither requires that Ajax
                                                libraries and IDEs support
                                                this metadata nor restricts
                                                Ajax libraries and IDEs
                                                from supporting other
                                                similar mechanisms. If this
                                                simple approach is not
                                                sufficient for particular
                                                requirements, Ajax
                                                libraries and IDEs are
                                                fully free to invent their
                                                own mechanisms.
                                                NOTE: If multiple widgets
                                                point to the same asset
                                                files, assume the IDEs will
                                                be smart enough to only
                                                load the given assets once.
                                                NOTE: We might consider a
                                                feature where
                                                OpenAjaxLibrary.xml also
                                                supports something similar
                                                to <assetfile> for any
                                                files that must be loaded
                                                in order for any of the
                                                widgets to work.
                                                NOTE: We need to think
                                                through how this might
                                                relate to a possible future
                                                OpenAjax standard around
                                                centralized JavaScript
                        Define XML metadata markup that provides similar
                        hooks to jMaki's libs, preload, and resources,
                        which means markup that identifies the location of
                        the JavaScript files to load for a given library,
                        any JavaScript to execute before loading that
                        library, and the location of the root directory for
                        that library.
                                                NOTE: Regarding resources,
                                                perhaps that belongs in
                                                NOTE: Regarding preload,
                                                maybe we need a
                                                library-level preload
                                                instruction within
                                                OpenAjaxLibrary.xml along
                                                with widget-level preload
                                                instructions within the
                                                widget metadata.
Here is some markup that would address the bullets listed above:

Within OpenAjaxLibrary.xml:

<library xmlns="http://ns.openajax.org/library"
baseDirectory="...relative URL to root folder for library..."
  <assetfile type="javascript|css|..." location="<url>"/> <!-- from Adobe
  <!-- etc -->
<preload> <!-- from jMaki -->
  ...javascript logic...

Within OpenAjaxWidget.xml:

<widget xmlns="http://ns.openajax.org/widget" ...>
 <assetfile type="javascript|css|..." location="<url>"/> <!-- from Adobe
  <!-- etc -->
<preload> <!-- from jMaki -->
  ...javascript logic...
IDE mailing list
IDE at openajax.org
IDE mailing list
IDE at openajax.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20071213/3578abd7/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071213/3578abd7/attachment-0006.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic24374.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071213/3578abd7/attachment-0007.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071213/3578abd7/attachment-0008.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2B785889.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071213/3578abd7/attachment-0009.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2B075126.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071213/3578abd7/attachment-0010.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2B645825.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071213/3578abd7/attachment-0011.gif 

More information about the IDE mailing list