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

Rich Thompson richt2 at us.ibm.com
Mon Dec 10 12:25:49 PST 2007


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
Subject:
Re: [OpenAjaxIDE] IDE Issue 1: Toolkit identification, 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.

Jon


Jon Ferraiolo/Menlo Park/IBM at IBMUS


Jon Ferraiolo/Menlo Park/IBM at IBMUS 
Sent by: ide-bounces at openajax.org 
12/05/2007 02:54 PM



To

ide at openajax.org

cc


Subject

[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 
initialization 

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' : [
                 '../resources/libs/dojo/v0.4.3/djd43.js'
             ],
             'preload' : 'if (typeof djConfig ==\'undefined\') djConfig = 
{ parseWidgets: false, searchIds: [] };',
             'resources' : [
               '../resources/libs/dojo/v0.4.3/src'
             ]
  }, 
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 
address: 
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 Specification.) 
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. 

Analysis 
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 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. 
<widget 
  libraryName="dojo"
  libraryVersion="0.4.3"
>


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' : [
                 '../resources/libs/dojo/v0.4.3/djd43.js'
             ],
             'preload' : 'if (typeof djConfig ==\'undefined\') djConfig = 
{ parseWidgets: false, searchIds: [] };',
             'resources' : [
               '../resources/libs/dojo/v0.4.3/src'
             ]
  }, 


Adobe Dreamweaver metadata 
Adobe proposes an <assetfile location="..." referenceType="javascript"/> 
tag to identify the JavaScript that needs to be loaded" 
  <assetfiles>
  <!--  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" 
referenceType="link"/>
  <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" 
referenceType="javascript"/>
  <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" 
referenceType="javascript"/>
  <assetfile location="yui/2.3.1/build/menu/map.gif" />
</assetfiles>


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 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..."
...
>
...
<assetfiles>
  <assetfile type="javascript|css|..." location="<url>"/> <!-- from Adobe 
-->
  <!-- etc -->
</assetfiles>
...
<preload> <!-- from jMaki -->
  ...javascript logic...
</preload>
...
</library> 
Within OpenAjaxWidget.xml: 
<widget xmlns="http://ns.openajax.org/widget" ...>
...
<assetfiles>
 <assetfile type="javascript|css|..." location="<url>"/> <!-- from Adobe 
-->
  <!-- etc -->
</assetfiles>
...
<preload> <!-- from jMaki -->
  ...javascript logic...
</preload>
...
</widget>_______________________________________________
IDE mailing list
IDE at openajax.org
http://openajax.org/mailman/listinfo/ide
_______________________________________________
IDE mailing list
IDE at openajax.org
http://openajax.org/mailman/listinfo/ide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20071210/6c7a2824/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071210/6c7a2824/attachment-0010.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071210/6c7a2824/attachment-0011.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071210/6c7a2824/attachment-0012.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071210/6c7a2824/attachment-0013.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071210/6c7a2824/attachment-0014.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071210/6c7a2824/attachment-0015.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071210/6c7a2824/attachment-0016.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071210/6c7a2824/attachment-0017.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20071210/6c7a2824/attachment-0018.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/6c7a2824/attachment-0019.gif 


More information about the IDE mailing list