IDE Survey

From MemberWiki

(Redirected from IDE TF Survey)
Jump to: navigation, search

This wiki page contains short executive summary descriptions of how some IDEs integrate Ajax components today.



Aptana supports various AJAX runtimes through two mechanisms:

Aptana currently ships with AFLAX, Dojo, jQuery, MochiKit, MooTools, Prototype, Rico, Scriptaculous, YUI, and YUI-EXT libraries.

Aptana has plans to further enhance the mechanism by which libraries and components are inserted and updated as "packages" to make the development and deployment aspects simpler and easier.

Eclipse AJAX Toolkit (ATF)

Personality support has been removed from ATF as of 0.2.3 (see overview). This section needs to be updated.

ATF current supports AJAX runtimes via the concept of "Personalities". A Personality describes a AJAX component to ATF. Personalities define the following:

  • Runtime artifacts needed by the component, normally a .js (i.e. dojo.js). These artifacts are added to a web project when the personality is addded to the project.
  • Code snippets for the personality. These can be dragged/dropped into the project source.
  • Wizards for added a personality to a project.

(Added by JonF 2007-04-27) ATF includes a "personality builder" that allows integration of Ajax libraries into ATF. By going to File->New->Other... and choosing ATF->ATF Personality, a dialog comes up that asks for the following information:

  • Personality name (short and descriptive)
  • Icons (small=16x16, large=75x66) for the "personality" (where personality pretty much means "toolkit")
  • Location of JavaScript files
  • Information needed by Eclipse-specific wizards, such as the "project name" and the default "application name", a list of variables that should be presented by the Eclipse wizards (and which wizard view for each variable)
  • Any predefined snippets of HTML (e.g., "tree widget" snippet) for that personality/toolkit that will populate Eclipse's snippets view

(Conspicuously absent from the snippets feature is an icon for the snippet. This is because ATF doesn't display snippet-specific icons for snippets, just text, but Eclipse itself seems to support snippet-specific icons, even if ATF isn't using the feature.)

jMaki Framework

jMaki support JavaScript frameworks/libraries declaratively in JSON format. The dependencies are defined for an application in a config.json file. Library dependencies are tracked by a server side runtime (PHP/Java/JavaScript) that interprets the JSON and insures that dependencies are written only one for each library/framework. Areas of interest for the IDE task force include the following.

  • Widget Model - jMaki can either describe or provide wrappers for JavaScript widgets. Widgets representing a reusable portion of JavaScript code are represented using a convention where namespaced JavaScript objects which take only one object literal that represents all the properties a widget needs including mix-ins. Widgets exist in a pre-defined location that is deduced from the JSON based library or Framework Dependencies. Widgets also contain meta-data about a widget in a declarative widget.json file which describes the properties which may be provided to a widget and may also describe the library dependencies for that widget. widget.json dependencies take precedence over the global configuration.
  • Customizer - jMaki contains tools provide customizers for the widgets that interpret the widget.json data and provide a property editor to allow users to graphically configure a widget regardless of the toolkit of origin. Documentation for the different properties is also provided in the widget.json.
  • Shareable Widgets - Widgets may be self contained with all of its dependencies and drag/drop template code fragments may zipped up across organizations. The convention for the structure will be later defined on the jMaki documentation Page. These widget can be imported into a tool or unzipped into the resources directory of a application containing a jMaki runtime and the widgets will become available. In the case of a tool they will become visible in the jMaki widget palette.
  • Layouts - jMaki provides a set of CSS layouts with HTML templates that can be a good start for a Ajax application. These layouts are part of the project creation wizard in jMaki and may also be created with new pages.

TIBCO General Interface Builder

General Interface Builder (GI Builder) is a visual authoring environment that supports WYSISYG creation of Ajax RIAs. GI Builder itself is an ajax application built with javascript components from the TIBCO General Interface Framework. GI Builder and GI Framework also provides extensibility mechanisms through subclassing of JavaScript objects, and embedding of arbitrary HTML and javascript within reusable component prototypes. Both of these can also be wrapped into an "add-in" that enables packages of components and their comlimentary visual tooling if any, to be bundled into manageable sets.


When a user drags and drops a component in the visual canvas from the Component Library, they are in fact dragging and dropping a prototypical instance of one or more javascript class objects arranged into a component. A single XML serilization file for that prototype component contains the classes and values for the instance properties. Components in this XML serization format register themselves by virtue of being placed in the appropriate components subdirectory within GI Builder's folder.


Class definitions can be added-ad hoc as part of any project's javascript files, or can be added more formally through an add-ins infrastructure. Using the later it's possible to also include XML data that drives API refernece within the Builder environment and the XML data that's used to describe the available properties (and their possible values) and set events which appear in GI Builder's visual Properties Editor and Events Editor. GI's support for OO concepts includes introspection of the object. Thus while classes could self-describe, the restrictions that would be useful in assuring valid property settings at author-time are not part of the object themselves and are registered in an associated XML format.


Add-ins are detected by virtue of being placed in the appropriate subdirectory within GI Builder's folder and by having the appropriately formed config.xml file in that directory.


  • means to load additional, compatible javascript libraries desired by the user
  • means to desribe the properties, events, and API documentation for those and methods of the elements within the library
  • means to bundle groups of items together
  • means to register and load extensions to the visual authoring tools since not all javascript components in visual tools are necissarily GUI components. For example one might have a communication or data transformation class that perhaps has unique visual tools associated with it.

It seems we need the ability to load some code and the meta-data descriptions for it. Self-describing code would probably be a burden where as supplmental meta-data would be more easily generated and organizations could porbably write code to derive the meta data files automatically (as in the way in which JavaDocs does for API reference). What ever that metadata format is, it should be easily transformable into a variety of languages since tools are written in a broad variety of languages.

Adobe GoLive CS2

(This information was derived by downloading the GoLive CS2 SDK and studying its manuals.) Adobe GoLive CS2 has an extensive extensibility system based on the ability to add HTML+CSS+JavaScript "plugins" (or add-ons or whatever) to the GoLive Web/HTML authoring environment. This extensibility system supports the ability to add new HTML UI components (now often referred to as Ajax components) to the GoLive authoring system, but goes far beyond this. The extensibility system is generalized to all aspects of the GoLive product, where the entire tooling environment is customizable, where the authoring tools APIs are exposed to JavaScript plugins and all user interface is represented using HTML.

The most relevant part of GoLive's extensibility system for the IDE TF is its support for what they call "custom elements". A custom element is defined via XML/HTML markup as follows:

Identifies the custom element's tagname, such as <MyTreeControl>, via the tagName attribute, and also defines a few other things about the element.
<jsxpaletteentry> and <jsxpalettegroup>
GoLive ships with dozens of widgets, so their widget palette has tabs for different categories of widgets. These two elements indicate on which palette/tab this custom element should appear
Contains the HTML that is used to populate the Inspector palette whenever the user selects a widget from this class. Note that GoLive does not auto-populate the Inspector palette by introspecting into property lists, but instead requires that the widget developer author custom HTML for the Inspector palette
Icon for the widget
Boils down to an HTML:IMG element, but GoLive offers tools and instructions for creating the raster

The above sounds simple and basic, but GoLive offers rich APIs for widget developers for many author-time features. Here are some:

  • Callback for when GoLive first creates a new instance of the widget within an HTML document (typically via drag/drop from the palette onto the document surface)
  • Callback for when the authoring environment (layout view) requires a redraw of the custom element
  • Callback for when the user attempts operations on the custom element, such as a mouse click
  • Callback for just before the inspector palette is rendered for a custom element
  • Integration with GoLive's Undo manager

Adobe/Macromedia Dreamweaver

The online book "Extending Dreamweaver 8" shows that Dreamweaver 8 offers similar facilities to GoLive CS2 in terms of the ability to extend the product through HTML and JavaScript. One difference is that GoLive seems to be more focused on adding custom widget icons to the GoLive widget palettes, whereas Dreamweaver generally puts its widget icons onto the Insert toolbar (which has sub-categories).

Dreamweaver attempts to define all extensions as mini-HTML documents. For example, suppose you wanted to customize the Dreamweaver UI to add a strikethrough button on one of the button bars, you would create an HTML file such as:

<script language="javascript">
function isDOMRequired() {
// Return false, indicating that this object is available in Code
return false;
function objectTag() {
// Determine if the user is in Code view.
var dom = dw.getDocumentDOM();
if (dw.getFocus() == 'textView' || dw.getFocus(true) == 'html'){
var upCaseTag = (dw.getPreferenceString("Source Format", "Tags Upper
Case", "") == 'TRUE');
// Manually wrap tags around selection.
if (upCaseTag){
// If the user is not in Code view, apply the formatting in Design
}else if (dw.getFocus() == 'document'){
// Just return--don't do anything else.

and then you would create a raster image for the icon that appears in the toolbar.

Dreamweaver also offers related features, such as snippets (code snippets), libraries (common HTML that is shared across multiple pages in a site), templates (HTML master pages with editable regions, including repeating elements), and support for tab libraries and server-side includes.

Dreamweaver has strong features for WYISYG data binding in conjunction with multiple server technologies.

<?xml version="1.0" encoding="utf-8"?>
<!-- note that we need both localized and non-localized versions of the category attribute -->
<widget name="Spry Tooltip" location="" version="1.5"
author="Adobe Systems, Inc." about="" 
  <help src="urlToDocumentationForWidget" />
    <!-- note that alternate text will need to be localized -->
    <icon size="small" width="18" height="18" 
alt="Spry Tooltip" />
    <assetfile type="css" location="" reference="local" />
    <assetfile type="javascript" location="" reference="local"/>
    <argument name="id" type="string" subtype="id" required="true" default="tooltip" />
    <argument name="selector" type="string" subtype="cssSelector" required="true" default="#trigger"/>
    <argument name="options" type="object" subtype="options" required="false" />
    <option name="closeOnTooltipLeave" type="boolean" default="false" />
    <option name="followMouse" type="boolean" default="false" />
    <option name="hideDelay" type="integer" subtype="milliseconds" default="0" />
    <option name="hoverClass" type="string" subtype="class" default="" />
    <!-- What should we do for values that could either be a unitless int or a string with units? 
          Should we just handle that internally by always checking for either, but only writing out one? 
          Should we preserve what the user wrote at all costs? -->
    <option name="offsetX" type="integer" subtype="pixels" default="15" />
    <option name="offsetY" type="integer" subtype="pixels" default="15" />
    <option name="showDelay" type="integer" subtype="milliseconds" default="0" />
    <option name="useEffect" type="enum" subtype="string" values="'blind','fade'" default="" />
  <!-- I think we need to define some specific locations to insert code. 
        I'm assuming that the asset files will go in the head, of course, and that the default 
        HTML will go at the insertion point. There might be additional JS, which I'm calling the 
        constructor after the Spry pattern, that needs to go somewhere, and it might be different 
        for each widget type. Spry constructors usually go at the bottom of the body, below the 
        defaultHTML. jQuery and YUI code might go in the head.  -->
  <constructor location="afterDefaultHTML">
  <!-- I'm using @@argumentName@@ to indicate how the arguments listed above are ordered 
        in the constructor, so we can make a substitution when inserting. -->
  <appliesTo tag="any" />
  <!-- Should we break up widgets based on usage scenarios (e.g., provide three *different* 
      Spry Tooltip widgets)?

      Note in the defaultHTML below, the id="triggerElement" corresponds to the @@selector@@ 
      constructor argument, but not exactly. If the @@selector@@ were ".triggerElement", for 
      example, the div would need to have class="triggerElement", not id="triggerElement". It's 
      a bit complex to have just <div @@selector@@></div>, though; what if the selector is just 
      "div"? What if it's a complex selector like "#mainpage .foo"? -->
    <![CDATA[<div id="trigger"></div>
    <div id="@@id@@"></div>]]>
  <!-- If the developer wants to provide his own extension files, perhaps we should just have 
        an entry that points to an mxp? Individual entries as below, on the other hand, would allow 
        the developer to implement as little or as much as s/he wants, and for us to know what 
        remains to be done. -->
  <objectFile url="DwObjectFileOnAServerSomewhere" />
  <designtimeFile url="WidgetDesignTimeFileOnAServerSomewhere" />
  <propertyInspectorFile url="PIFileOnAServerSomewhere" />
  <translatorFile url="DwTranslatorFileOnAServerSomewhere" />

Adobe/Macromedia FLEX components

Adobe (Macromedia) has developed the FLEX product line, which uses the MXML user interface language that compiles into Flash+ActionScript for execution on the Flash player. One of the fundamental technology pieces of FLEX is its component architecture. Recommended best practice for FLEX developers is to develop reusable user interface components leveraging the OO features of MXML/ActionScript.

Of particular interest to the IDE TF are the features for integrating FLEX components into a visual IDE. Each UI component can define the following:

  • Raster icon for inclusion within the IDE's UI
  • List of properties (name, type, default value) that should be included within inspector dialogs, along with the category for the property under the assumption that the inspector dialog has tabs ([Inspectable(defaultValue="whatever")] public var z1:String;)
  • List of events to which the component listens or the component broadcasts
  • List of custom CSS styling properties that are supported on the given component, where {name,type,format,inherit} quadruple is provided for each supported styling property
  • List of effects and behaviors to which the component can respond ([Effect("userItemAddedEffect")])
  • List of external resources, particularly images and multimedia, that need to be included in the generated SWF file ([Embed("kaching.mp3")])

Java Beans

(From the Java Beans 1.01 spec)

Java Beans take into account both run-time and design-time requirements. The three most important features of a bean are:

  • The properties it exposes
  • The methods it allows other logic to invoke
  • The events that it generates and observes

By default, IDEs discover the metadata on a bean due to various naming conventions used by beans. To find properties and events, the IDE introspects for method names (getters, setters, event listeners) that follow particular naming conventions. All other methods are assumed to be public methods. The default can be overridden if the bean provides a BeanInfo interface. In addition to the previously mentioned features, BeanInfo also provides:

  • Icons (color 16x16, color 32x32, mono 16x16 and/or mono 32x32)
  • Arbitrary user data


  • Property change listeners
  • Hooks for validation
  • Some ability for property changes to be vetoed (didn't fully research this one)

Other key features:

  • Beans support persistence in that instances of a bean can be serialized to disk.
  • Beans can be visible or invisible.
  • Beans are localizable using standard Java localization facilities.
  • Beans leverage Uniform Data Transfer for passing structured data between different beans (Ajax/JavaScript probably would just use JSON)
  • Beans have some level of clipboard service
  • A rather sophisticated event system, including event adapters (the Hub has subscribe filters, which overlaps to some level)

For advanced UI representation of components within IDEs, a bean can provide a customerizer class that provides an arbitrary user interface for the property inspector dialog within an IDE, which overrides the automatic default UI that the IDE uses after introspecting the bean to gather its list of properties.

The JAR file that holds a bean has a mechanism to identify design-time features so that the design-time pieces within the JAR can be eliminated from the deployed final application.

XBL and SVG's proposed <traitDef>

XBL has been shipping in Mozilla since the late 1990s as component technology that complements XUL. (XUL defines standard UI elements, XBL allows creation of custom UI elements.) In 2001, Mozilla submitted the XBL specification to the W3C, but it did not get traction there. In 2004, there was progress on an sXBL specification that defined a functional subset of Mozilla XBL for SVG application development, but that stalled. Now, in 2006 and 2007, the W3C is working on an "XBL2" specification that is a functional superset of Mozilla XBL (largely backwards compatible, but backwards compatibility is not a requirement). It appears that both Mozilla and Safari/WebKit will implement XBL2. The latest draft of XBL2 is at

XBL does not define any IDE-oriented metadata for components. It does include declarative syntax for what external resources, such as stylesheets and multimedia, are required by the component.

XBL2 is focused mainly on providing a component architecture for HTML, but there is coordination with the SVG WG. The SVG WG is considering a minor extension to the XBL2 spec in the form of the <traitDef> element (, whose main purpose is to identify the data types for properties on custom elements to allow SVG's animation engine to know how to animate the value of the custom property over time. Clearly <traitDef> overlaps with IDE-oriented metadata.

NOTE: If there was an XML representation of the IDE metadata that we define, the W3C might consider it as a good complement technology for UI components defined using XBL.

MS Visual Studio

Visual Studio has included JavaScript debugging in IE for a very long time. Visual Studio 2008 greatly improves JavaScript debugging and also adds full JavaScript IntelliSense. IntelliSense is driven by reflection on the code and by XML doc comments but may also be driven by an external file that can be extracted from the code and XML doc comments. An external file enables generation from other frameworks and also the use of different annotation formats. Visual Studio 2008 also has explicit support for Microsoft Ajax projects and Ajax-enabled server controls and extenders, including on the design surface. Extenders are special controls that extend other controls. For example, a watermark extender can extend a textbox control. Several extenders can be added to a single control. Both controls and extenders benefit from the existing server control infrastructure in .NET and Visual Studio (toolbox, icon, "prototype" markup, property grid, design-time rendering, wizards, etc.).

Microsoft also publishes a documentation generation tool that now works with JavaScript in conjunction with a specific extraction tool. The tool, which is published under a Microsoft Permissive License, extracts metadata from JavaScript for consumption by IDEs and documentation tools. The tool is focused on Microsoft Ajax, but the file formats it uses should be of more general use. The most interesting part for the alliance is probably the schema of the reflection files, which is free to use and modify. This schema is actually not specific to JavaScript or any language (and pre-existed the JavaScript extraction tool). The system works by looking at the structure of the JavaScript code itself as well as XML doc comments inside the code to generate an XML documentation file (which can be localized) and a reflection file, which describes the class hierarchy of the code.

The tool can be found here.

The doc comment format was discussed here.

The reflection file schema is here.

Examples of a reflection file that validates against this schema ( and a documentation file (MicrosoftAjax.xml) can be downloaded from this page

Visual jQuery

The jQuery team has an online and print documentation system called Visual jQuery that (apparently) transforms JSDoc annotations into an XML file, which then goes through XSLT transformations to produce online documentation for jQuery and print documentation for jQuery. The link to Visual jQuery is To see the XML markup language, just do a view source.

Here is a snippet:

<?xml version='1.0' encoding='ISO-8859-1'?>
<?xml-stylesheet type='text/xsl' href='style/cat.xsl'?>
<docs version='1.1'>
<cat value='Core'>
<method cat='Core' type='jQuery' short='This function accepts a string containing a CSS or
basic XPath selector which is then used to match a set of elements.' name='$'>
<desc>This function accepts a string containing a CSS or
basic XPath selector which is then used to match a set of elements.

The core functionality of jQuery centers around this function.
Everything in jQuery is based upon this, or uses this in some way.
The most basic use of this function is to pass in an expression
(usually consisting of CSS or XPath), which then finds all matching

By default, $() looks for DOM elements within the context of the
current HTML document.</desc>
<params type='String' name='expr'>
<desc>An expression to search with</desc>

<params type='Element|jQuery' name='context'>
<desc>(optional) A DOM Element, Document or jQuery to use as context</desc>
<desc>Finds all p elements that are children of a div element.</desc>
<before><p>one</p> <div><p>two</p></div> <p>three</p></before>

<code>$("div > p")</code>
<result>[ <p>two</p> ]</result>
<desc>Searches for all inputs of type radio within the first form in the document</desc>
<code>$("input:radio", document.forms[0])</code>

<desc>This finds all div elements within the specified XML document.</desc>
<code>$("div", xml.responseXML)</code>
<method cat='Core' type='jQuery' see='appendTo(String)' short='Create DOM elements on-the-fly from the provided String of raw HTML.' name='$'>
<desc>Create DOM elements on-the-fly from the provided String of raw HTML.</desc>
<params type='String' name='html'>
<desc>A string of HTML to create on the fly.</desc>
<desc>Creates a div element (and all of its contents) dynamically,
and appends it to the element with the ID of body. Internally, an
element is created and it's innerHTML property set to the given markup.
It is therefore both quite flexible and limited.</desc>

Personal tools