Talk:JSDT Use Cases

Comments from Robert Goodman:

Here are some initial comment. Based on you document it looks like you a looking at the project structure and include path support for JavaScript libraries in JSDT. I think that there are three main scenarios to be considered.

Browser define objects (window, document) for the environment like the ECMA, firefox, i.e. libraries JavaScript/Ajax libraries like Dojo on the include path User define JavaScript files (created by the user when developing an application in eclipse).

The GUI and the issues involved are different for the Browser define object, than the include path/javascript file case. For instance. in the JavaScript library case one of the issues is how/when do the libraries get deployed out to a Web Server. JavaScript libraries potentially put requirements on other WTP components than JSDT such as the Server support.

1. Browser define objects

The way JSDT has implemented support for these browser objects is to define the base implementation classes in JavaScript files (Document, Window) and then infer the instanced objects document and window. The files that contain the implementations classes also show up in the project structure. From a use case standpoint my the biggest concern with these browser implementation classes files is that generally Web programmers don't program to the classes. They use the instanced objects. It is possible to use the classes directly, but it is generally not done. Given this fact, I would do the following.

By default hide the directory that contains the files from the project explorer view. By default the implementation classes don't show up in content completion.

A possiblility would be to support a preference option that will allow a user to see the implementation classes and have them show in content completion.

2. JavaScript libraries on the include path.

From a use case standpoint for JavaScript libraries on the include path, I think there are three main areas to be concern about.

1. Content completion of functions in the library for HTML and JavaScript files.

HTML files The big issue to be resolved is whether functions in the JavaScript library only show up in content completion/validation for a HTML file when a src tag specifying a path to the library is specified or should the functions from the library just be put in the global scope. Since one of the big gains with JSDT is validation and finding of problems before running the application, a developer should be required to specified a src tag pointing to a JavaScript file in the library. This means the GUI for defining a library on the include path needs to have the option for specifying a "path" to the library. A developer would use this path on the src tag in the HTML file.

JavaScript file Since Javascript doesn't support a include statement there is no good way to determine when functions in the JavaScript library should show up in the content completion/validation. When running the application this is determine by the src tag in the HTML file used to run the application, but this can't really be used when developing the application. I may develop the JavaScript files before I write the HTML file and there could be multiple HTML files in a project. There are two possible solutions to the problem

The functions in the JavaScript library automatically show up in completion/validation There is a GUI that allows a developer to specify a set of JavaScript files from the library to be used during context completion/validation.

Note: In ATF we allowed the developer to specified a directory relative to the Web content directory for a Ajax/JavaScript library. We then copied the library into the directory mostly to simplify the next item below. In an HTML file a developer had to specify a src tag to get content assist/validation. For JavaScript files the functions in the JavaScript library automatically show up in context completion.

2. Running an Application that uses a JavaScript library on the include path.

Since JSDT has this concept of a Include Path, what happens when a user runs/deploys the application on a server. I think that there are three use cases that need to be considered here.

External HTTP Server

For an External HTTP server it is possible to make it a user problem. Just make the user manually deploy the JavaScript library on the server.

The WTP preview Server

Requiring the user manually deploy the JavaScript library makes the WTP preview server useless. I wouldn't know where to copy the Ajax library to for the WTP preview server.

Running a Project without deploying to a server.

Only ATF support this option today but it was one of out most requested feature enhancements. A person developing just JavaScript and html, doesn't need to actually deploy to the server to do testing. I only point this out because in the future WTP may want to support this option. Again the issue is how are JavaScript libraries on JSDT include path handled in this case.

Note: In ATF we took the simple solution and just copied the library into the project so the src tag was relative to the Web Content directory.

3. JavaScript files the user creates

Here again the question is how/when the functions in a user created JavaScript file show up in content completion/validation. As stated before JavaScript doesn't support a include statement there is no good way to determine when functions in user created JavaScript files should show up in the content completion/validation. I think the two possible solutions are the same for JavaScript libraries on the include path

The functions in the JavaScript library automatically show up in completion/validation GUI that allows a developer to specify a set of JavaScript files from the library to be used during context completion/validation.

Note: In ATF we really didn't come up with a good solution to this problem.

I think resolving some of the above issue will help direct the representation of JavaScript libraries in a project and the GUI to support them.

One last thing issue for Ajax libraries

A number of Ajax Libraries do use a method to include JavaScript libraries. The Open Ajax Alliance is attempting to define a standard around this as part of the IDE working group. this is a issue that JSDT may have to deal with in the future