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

Jon Ferraiolo jferrai at us.ibm.com
Mon Dec 10 13:55:33 PST 2007

Hi Rich,
I don't think we can use the rule that everything in the list of assets
would translate into a new HTML element (e.g., SCRIPT or LINK) in the HEAD
for two reasons:

1) Some assets will not map to an HTML element that goes in the HEAD. For
example, images or readme text files. What happens if the developer leaves
off the attribute when pointing to an image? I think it would be too
complicated to say that you don't need the attribute for images but you do
for JavaScript files.

2) I expect we will want to support the ability to point to a folder as an
indication that all files in the given folder should be deployed.


             BM at IBMUS                                                   To 
             Sent by:                  ide at openajax.org                    
             ide-bounces at opena                                          cc 
                                       Re: [OpenAjaxIDE] IDE Issue 1:      
             12/10/2007 12:25          Toolkit identification,             
             PM                        configuration,  loading, and        

Or perhaps just an attribute which defaults to case #1.

Rich Thompson
IBM T.J. Watson Research Center / Hawthorne, NY

 From:  Jon Ferraiolo/Menlo Park/IBM at IBMUS                                 
 To:    ide at openajax.org                                                   
 Date:  12/06/2007 01:54 PM                                                
 Subjec Re: [OpenAjaxIDE] IDE Issue 1: Toolkit identification,             
 t:     configuration,        loading, and initialization                  

Just an observation.

During the extra-time period of our phone call today, it struck me that
there are two potentially orthogonal uses for <assetfile>:

(1) Identify the files that require markup insertion (e.g., SCRIPT and LINK
for css) into the HEAD area of the document
(2) Identify the files that must be deployed onto the Web site

Many files belong to both categories (1) and (2), but some files might be
referenced indirectly and therefore would fall into category (2) but not
category (1). Maybe we need separate XML tags for the two uses.


Inactive hide details for Jon Ferraiolo/Menlo Park/IBM at IBMUSJon
Ferraiolo/Menlo Park/IBM at IBMUS
 Jon Ferraiolo/Menlo                                                       
 Park/IBM at IBMUS                                                            
 Sent by:                                                                  
 ide-bounces at openajax.o                                                    
 12/05/2007 02:54 PM             ide at openajax.org                          
                                 [OpenAjaxIDE] IDE Issue 1: Toolkit        
                                 identification, configuration, loading,   
                                 and 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 inspector
      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 library
            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

      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


      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
       <assetfile location="yui/2.3.1
      /build/container/container_core-min.js" referenceType="javascript"/>
       <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 library.
                  NOTE: By saying only focus, that just means where we
                  focus. It doesn't necessarily mean that we don't allow
                  other workflows.
                  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 loading.
                        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 OpenAjaxLibrary.xml instead.
                              NOTE: Regarding preload, maybe we need a
                              library-level preload instruction within
                              OpenAjaxLibrary.xml along with widget-level
                              preload instructions within the widget
                        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
                         <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
                        attached file: pic29913.gif)
                        IDE mailing list
                        IDE at openajax.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20071210/aae45900/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/20071210/aae45900/attachment-0006.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic19749.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071210/aae45900/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/20071210/aae45900/attachment-0008.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 25241638.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071210/aae45900/attachment-0009.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 25814092.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071210/aae45900/attachment-0010.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic29913.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071210/aae45900/attachment-0011.gif 

More information about the IDE mailing list