JSDT

JavaScript Development Tools

Introduction

The ATF team is proposing to develop a new set JavaScript Editor/Development Tooling. The ATF team feels that a good JavaScript editor with a real JavaScript model for both AJAX and JavaScript developers. This effort would be an incubating component of WST, since the WST project is scoped to do JavaScript development tools for the web. The JavaScript Development Tooling would be a WTP 3.0 2008 release item and would replace the existing JavaScrip editor.

Description

With the advent of Web 2.0, JavaScript have become central in the creation of a richer user experience on the Web. Its use has shifted from the creation of simple functions and handlers to events, to the creation of complex Web Application frameworks. Such complexity makes it crucial that more sophisticated set of tool become available on Eclipse.

The JavaScript Development Tools's goal will be to develop a framework for development of JavaScript applications, with full support for editing, refactoring, and searching. The JavaScript editor would be designed such that is can be plugged in to the Web Tools. The JavaScript Development Tools would be also be extensible such that new language features can easily be added.

The functionality of the JavaScript Development Tools will be heavily based on the functionality of the JDT. Because JavaScript is not a fully typed or class-based language, it will not be possible to provide 100% of the JDT functionality. Configurable capabilities will be provided to infer type and class structure from the JavaScript code, so as much JDT functionality as possible can be used.

Functions provided include:

• Editor capabilities:
  • Syntax highlighting
  • Code folding
  • Configurable formatting
  • Code completion
  • Content assist
    • Variable/function resolution
    • Resolution Context
  • Quick fix
  • syntax checking/error display
  • Hover help/tips
  • Occurences marking
  • open selected item
  • highlight matching parenthesis/brace/bracket
  • add/remove/generate comment
  • Typing helpers:
  • Automatically close strings, parentheses, brackets,etc
  • Automatically insert semicolons, braces
  • automatic formatting
• Refactoring
  • method- rename, move, delete, change signature
  • var - rename, move, delete
  • class (inferred) rename, move up/down
• Javadoc support (or JSDoc)
• Externalize strings (NLS support)
• Class hierarchy view
• Call hierarchy view
• Script explorer view
• Search references/declarations
• j(s)unit support
• Preferences:
  • Appearance
  • Templates
  • Formatting
  • Validation options
  • Error/Warning levels
  • Editor options
• Code Obfuscation
• Code Compression

Proposed Design

The JavaScript Development Tools design would use the JDT design with the necessary adjustments made for JavaScript.

As far as the JavaScript Development Tools design is concerned, the major differences between Java and JavaScript are:

• Javascript has no explicit typing support, whereas in Java everything is typed.
• At the top level, a JavaScript file can contain any program statement, whereas a Java file only contains a class.
• JavaScript has no classpath/jar file concept.

Other areas where the java/JavaScript differences will necessitate changes:

• syntax differences - parse definitions
• additional program elements with no correspondence in java
  • object literal
  • for (var in collection)

Inferred Types

In order for some JDT functionality (such as code completion) to work correctly, class type information needs to be available. This information is not available in JavaScript, but it can be inferred in many cases. A type inferring framework will be put in place to support this functionality. The type inferring will examine the JavaScript abstract syntax tree (AST), and generate "virtual" class information.

The type inferring will run off of a configuration will provide many options for how to infer the types/classes. The type inferring will also be extensible, so the unique conventions among various JavaScript toolkits can be handled. The type inferring will be configurable on a project basis, and possible on a file by file basis.

The type inferring configuration will also be used by the refactoring function.

Javascript file handling

Java files have a very top down structure, where files only contain classes, which only contain fields, methods, and classes, and program statements only contained within methods. Because of this, some JDT functionality will not work for JavaScript, because a program statement can be directly at the top of a JavaScript file. This will be handled by refactoring the relevant JDT code.

Variable/function resolution

In Java, everything is resolvable because of the classpath, package structure, and import statements. This has no correspondence in JavaScript. The function will be handled within JSDT by various means. When resolving functions/variables, JSDT will search all files in the same directory, files in referenced projects, files in referenced paths (configured by something like JDT "Java Build Path" page), and system API files (contained within JSDT).

Because of the "loose" nature of JavaScript, many of the validation errors produced by the resolution code will be changed to warnings, or removed altogether. It may be desirable to configure what should be errors on a (JavaScript) file by file basis.

Functionality mapping

This table shows how the JDT functionality corresponds to the JavaScript functionality. It does not include anything where there is a direct one to one correspondence.

JDT function	JSDT function
Build path	include path (or something similar)
JDK level (1.4 vs 1.5)	Ecma script level 3 vs 4
Compile	validation

Extension Points

The JSDT will functionality will be embedded. This means, for instance, the JavaScript editing capabilities will be embeddable within HTML and XML editors, both within script tags, and script attribute values.

The following jsdt.core extension points will be supported :

• include path variable initializer
• include path container initializer
• code formatter
• validation participant

In addition, the JavaScript syntax tree will be presented as an XML dom, so that various XML processors can be run against it for a variety of reasons, for instance, a Schematron processor could be used to do validation.

The following jsdt.ui extension points will be supported :

• javascript element filter
• javaScriptEditorTextHovers
• javadocCompletionProcessor
• quickFixProcessors
• quickAssistProcessors
• includepathContainerPage
• foldingStructureProviders
• queryParticipants
• javaScriptCompletionProposalComputer
• javaScriptCompletionProposalSorters

Development Plan

The high level plan as follows:

1. Copy the 3.2 level JDT code.
2. refactor java -> JavaScript , org.eclipse.jdt -> org.eclipse.jsdt, etc .
3. update syntax definitions, parsing, etc to JavaScript
4. class inferencing
5. update/refactor jdt junit tests to JavaScript and make work
6. update ui
7. remove dead code (any java functionality not used)
8. determine what code is unchanged from JDT and figure out how to share with JDT

Specific work items (non-exhaustive):

• Update syntax definition to JavaScript
• Add AST nodes for JavaScript Object literal, array initializer, and "for (var in collection)"
• Change junit test cases from testing java to be the corresponding JavaScript
• Add inferencing framework
  • Generic inferencing engine
  • Configuration support
  • Support for one or two popular toolkits such as dojo
• Include path support
  • Change resolution mechanisms
  • Change classpath model to include model
  • UI
  • Support for one or two popular toolkits such as dojo
• Change formatting code to support JavaScript
• Change syntax highlight code to support JavaScript
• Remove non-applicable actions from ui
• Expose ast as XML dom
• Refactoring
  • Change to run based on inferred types
  • May need to display dialog when not confident about what needs to change
• Code completion
  • Possible completion parser changes
• Quick fix
  • Add JavaScript possibilities
  • Remove non applicable possibilities