[OpenAjaxIDE] Bootstrapping

Bertrand Le Roy Bertrand.Le.Roy at microsoft.com
Wed Oct 24 08:40:28 PDT 2007


I see. It does look like a file organization that would indeed be adequate for what jMaki is doing.

Our concerns are a little different in that one of the things Visual Studio is trying to do with web applications is enable the user to just point the tool to a directory or remote web site and just have it work without additional operations. It tries to be relatively agnostic about JavaScript toolkits and in particular we *don't* want to get into the business of managing a collection of toolkits, their metadata and their versioning.

In this context, we can't really rely on the metadata residing in a central location or being in a carefully nested directory structure. Rather, we need to be able to discover the metadata from a number of places, starting with the place where the file that's being reflected on is.

In summary, I think we should recommend some places where the files could reside but not assume any particular implementation. This kind of discoverability is of course a lot easier if there is a file naming convention rather than a directory naming convention.

From: ide-bounces at openajax.org [ide-bounces at openajax.org] On Behalf Of Jon Ferraiolo [jferrai at us.ibm.com]
Sent: Wednesday, October 24, 2007 5:09 AM
To: Rich Thompson
Cc: ide at openajax.org
Subject: Re: [OpenAjaxIDE] Bootstrapping

Hi Bertrand and Rich,
I came up with the idea of having separate files as a result of doing some homework on the widgets side, particularly with jMaki. I don't know if you have had a chance to look into jMaki much, but it is a very interesting set of technology (and recently a version 1.0 commercial product) that addresses many of the problems facing the IDE WG (primarily on the widget side). When you use jMaki with an IDE such as Netbeans (remember, this is the IDE WG), the widgets found within various Ajax toolkits (e.g., Dojo, Yahoo, Spry) appear in a palette, with inspector dialogs that allow for per-instance customization of widgets that you use in your web application. This illustrates the #1 special thing about jMaki from the perspective of the IDE WG: they have already solved the problem of how to integrate the widgets found in multiple Ajax toolkits into a developer tool.

I looked at the way that jMaki bootstraps itself and where it stores its files. In general, there are 3 distinct areas on the developer's hard disk:

1) A directory holding all of the (modified) source code for the Ajax toolkits that jMaki works with. For example, dojo is at <jmakirootfolder>/widgets/jmaki-dojo-0.9.zip
2) A directory holding all of jMaki's wrapper files that hold the standardized metadata that allows jMaki to work with different widget system. For example, the dojo wrappers are at <jmakirootfolder>/widgets/resources/dojo/{accordion,clock,combobox,datepicker,...}. In particular, each widget has its own widget.json file.
3) The application area holding application-specific metadata, where two key files are <approotfolder>/web/shared/resources/config.json (which includes application-specific metadata such as overall CSS files, the jMaki version# and API keys such as for Google Maps) and glue.js (which defines listeners to jMaki's pub/sub system).

What I see in jMaki is that there the key metadata is spread around at least 3 different file types, widget.json, config.json, and glue.js (which is procedural, but could have been declarative), each tailored to a particular purpose. If you look at the contents of those files, it looks like Greg and the jMaki team (who have been working at this a long time) made good decisions. Each of the files are simple and highly understandable. Therefore, I concluded it made sense to have multiple based on watching how the jMaki team designed their framework.

As far as I could tell, jMaki does not have a central manifest that indicates where all of the widgets are. Instead, it seems to find the widgets by searching through a series of directories (I believe ANT is utiltized for this purpose under the hood). This also made sense to me because new libraries can be added without having to locate and update a central manifest.

jMaki doesn't provide metadata for JavaScript APIs. When looking at the Aptana XML format and comparing that to the widget metadata proposal from Adobe and the JSON files that are used by jMaki, the only overlap is in the area of {name, type, defaultvalue}, which is common between widget parameters and JavaScript method parameters and properties. Everything else is much different. Therefore, I concluded that it made sense to have different XML grammars for the widget metadata and the JavaScript API metadata, but share the same syntax for {name,type,defaultvalue}.

I hope Greg Murray comes to the phone call on Thursday so he can correct my assumptions and explain the rationale that led them to architecting jMaki the way that they did.


PS - I hope I didn't sell jMaki short. Not only has it solved the problem of how to integrate multiple widget sets into an IDE, they also have addressed the multiple IDE problem (e.g., jMaki also works with Eclipse) and server-side framework integration (e.g., jMaki works with JSF, JSP and PHP, and I forget, but I'm pretty sure there is some support for Rails).

[cid:1__=07BBF9EDDFACBD1A8f9e8a93df938 at us.ibm.com]Rich Thompson/Watson/IBM at IBMUS

Rich Thompson/Watson/IBM at IBMUS
Sent by: ide-bounces at openajax.org

10/23/2007 01:53 PM


"ide at openajax.org" <ide at openajax.org>



Re: [OpenAjaxIDE] Bootstrapping

I too would prefer to not start by doing separations where we do not have well developed reasons for the distinctions. It is likely some such distinctions will arise as we move forward and that seems like the appropriate time to separate the information.

I also wonder about an approach that seems to be focused on a downloaded directory structure. In particular I'm concerned about how it maps to a web widget model. What about more of a URI approach where "discovering" the widget/component/library means one has been handed a defined set of metadata. This could be by ingesting the response from a URI or by reading a file. If it makes sense to partition the metadata, this top level set can point to other metadata (and thereby also support deferred loading of unused information ...).

Rich Thompson

From:   Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>
To:     Jon Ferraiolo/Menlo Park/IBM at IBMUS
Cc:     "ide at openajax.org" <ide at openajax.org>
Date:   10/23/2007 04:35 PM
Subject:        Re: [OpenAjaxIDE] Bootstrapping


Well, it’s also still not clear to me why we need different formats for lib, api and widgets. What’s the difference between lib and api?

From: Jon Ferraiolo [mailto:jferrai at us.ibm.com]
Sent: Tuesday, October 23, 2007 1:27 PM
To: Bertrand Le Roy
Cc: ide at openajax.org
Subject: RE: [OpenAjaxIDE] Bootstrapping

Does your response mean that everything else in my email is good? I assume that the answer is no, and that your response represents only the subset of things you could think of at the moment. In any case, it would be good if you and others could respond with what parts sounded good and which ones didn't.


[cid:4__=07BBF9EDDFACBD1A8f9e8a93df938 at us.ibm.com]Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>

Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>

10/23/2007 01:18 PM


Jon Ferraiolo/Menlo Park/IBM at IBMUS, "ide at openajax.org" <ide at openajax.org>



RE: [OpenAjaxIDE] Bootstrapping

A few points:
• I’m a little uneasy about having the name OpenAjax (or even something generic such as metadata) as the file name because if the file gets separated from the library or gets out of the folder, you can’t guess what’s in there without opening it. I’d prefer a convention that is a variation of the library’s file name. i.e. prototype.js -> prototype.metadata.xml
• We shouldn’t force people to put different libraries in different folders if they don’t want to.
• The file should be discoverable from the directory where the file sits as well as from some central directory on the file system that’s determined by the IDE itself. This enables web authors to not have the metadata file pollute the web site if they don’t want it there.

From: ide-bounces at openajax.org [mailto:ide-bounces at openajax.org] On Behalf Of Jon Ferraiolo
Sent: Tuesday, October 23, 2007 12:52 PM
To: ide at openajax.org
Subject: [OpenAjaxIDE] Bootstrapping

(I'm only sending this to ide at openajax.org because this is mostly centered on IDE workflows, not mashup workflows, although this proposal does attempt to address some of the expected requirements from the Gadgets TF)

We have looked at various grammars (XML, JSON and JSDoc) for representing library metadata (APIs and widgets). At our last phone call, there was a sense that we would be able to take the best features from each of the proposals such that we could define a unified XML grammar that might address all of our requirements. This is all good.

My question today is how does it all get bootstrapped (i.e., discovered, loaded, initialized)? Let's assume we have an IDE and two Ajax libaries, "A" and "B". How does the IDE discover A and B, make them available to the IDE, and how does it find (or possibly auto-generate) the XML metadata files that describe the APIs and widgets?

Here is one approach that might work:

1) An Ajax library is assumed to have a root folder, and everything needed by the library descends from that root folder. It is assumed that the IDE "discovers" a given library either because the library ships with the IDE or the library can be imported into the IDE somehow (post-installation), and the key thing that the IDE needs to know is the name of the root folder for the library.

2) To bootstrap library metadata, a file named OpenAjaxLib.xml file SHOULD exist in the root folder. This file provides overall metadata about the library (e.g., version#). But note the word "SHOULD". It is OK if OpenAjaxLib.xml is separate from the library, in which case the IDE will need to collect the metadata some other way, such as prompt the user provide the location of the OpenAjaxLib.xml file.

3) API metadata and widget metadata can be scattered around the directory structure. Assume that the IDE will recursively search through directories to find those files. No need for a master manifest file, which is difficult to keep up to date. We simply have to come up with a standard filename for the metadata files, such as OpenAjaxAPI.xml and OpenAjaxWidget.xml. (Note: we might provide an optimization feature in OpenAjaxLib.xml where explicit search paths could be defined and the toolkit developer can choose different names than OpenAjaxAPI.xml and OpenAjaxWidget.xml)

4) We make sure that OpenAjaxAPI.xml can be generated dynamically by the IDE through a just-in-time transformation (e.g., transforming MS's inline XML annotations into OpenAjaxAPI.xml or transforming JSDoc inline annotations into OpenAjaxAPI.xml)

5) We attempt to define the format for OpenAjaxWidget.xml such that:
a) it can be used to serve all common definitions for "widget" (WUI=UI controls, WMASH=Mashup widgets, WDASH=Installable desktop gadgets such as Dashboard)
b) we make sure there are lossless transformations to/from selected existing WMASH and WDASH widgets formats (e.g., Apple Dashboard, Google Universal Gadgets)

6) Allow OpenAjaxWidget.xml to include API definitions that apply to the given widget. Therefore, inside of OpenAjaxWidget.xml there might be tags from OpenAjaxAPI.xml.

Relationship to the proposals from Adobe, Aptana, and MS, plus also jMaki:

a) OpenAjaxWidget.xml should be largely analogous to jMaki's widget.json file, but needs to (roughly) support the union of features from Adobe's proposals and IBM's proposal to the Gadget's TF, plus offer an extensibility approach such that a rich UI system like dijit could embrace this format down the road. (Not saying that dijit should do this, but the format should allow this as a future possibility.)

b) OpenAjaxAPI.xml should be extensible in a manner that address's MS needs for supporting other languages. (As we discussed at the last phone call.)

c) Under the extensibility veneer per (b), the description of JavaScript APIs probably should look a lot like Aptana's markup language

Bottom line, my thinking today is that we need 3 different formats, OpenAjaxLib.xml, OpenAjaxAPI.xml and OpenAjaxWidget.xml.

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/20071024/25def96a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: graycol.gif
Url : http://openajax.org/pipermail/ide/attachments/20071024/25def96a/attachment-0003.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 16993434.gif
Type: image/gif
Size: 105 bytes
Desc: 16993434.gif
Url : http://openajax.org/pipermail/ide/attachments/20071024/25def96a/attachment-0004.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: ecblank.gif
Url : http://openajax.org/pipermail/ide/attachments/20071024/25def96a/attachment-0005.gif 

More information about the IDE mailing list