WTP is a large project. It offers features and functions for a wide range of web developers, and, some would say, focuses primarily on Java and JEE aspects of Web Development.

The WST project of WTP is for non-Java Web Development. JST, JSF and JPA are, as the 'J' implies, for Java and JEE Development. But, due to history and the whole Java-centric nature of Eclipse, WST has not received enough attention in its own right.

This was fine for a while, but as WTP matures, and as Web 2 applications become more popular, then some of the shortcomings of WST become more apparent.

This document is to serve as a place to organize this overall theme of non-Java web development. That is, organize it with prose, in a way that can not be done by individual bugzilla entries or individual line items in a plan. Hopefully this document will evolve, as our understanding and implementations evolve. 

I should be explicit about 2 things:

There are several areas within this theme that deserve focus.

One distinct aspect of non-java development is the user is perhaps less technical, or, at least, technical about different things. Hence, part of the solution is to be aware of that different type of user, and take that into account in a number of functional and user interface areas.

Non-java web developers have more concern, or need to know about, browser specific details. For example, they may want to validate their HTML against strict HTML 4.01 standards to work in any browser (bug 126934), or they may want to maximize some aspect of their application by writing to, and validate against some particular version of some particular browser or  perhaps even add custom tags. 

There are many other features for improved HTML and CSS editing (such as spell checking, dynamically updating CSS model, etc).

Non-java web developers typically do not much care about what server is being used, nor need to test different types of servers during development. Our current server UI in WTP is JEE centric in the sense it gives lots of flexibility and power in choosing and configuring servers. And, this is good for the power JEE developer, but is too complicated for the non-Java web developer.

There are several levels of server UI that should be available, depending on the users expertise and goals.

At this level, a user pretty much just would have to say "run" or "preview" and things would run on a server, perhaps without the user even being aware that it was running on a server. No setup, no properties to set, etc. For this level, users should be able to "run" the following sorts of pages. Where "run" means the content is served up by a server, handling resolution of page references, etc., as a server would: HTML pages, with CSS, JavaScript, and simple JSPs and Servlets. There would be no "web app" per se (or, if there was, it would be some default one that the user would not even know about). Where server-side debug exists, such as for JSPs and Servlets, the developer should (still) be able to debug. See bug 163100.

Here the user wants to simply point to an existing HTTP server. See bug 85971. In this case, any setup of the server is done entirely outside the development environment, and in many cases would have already been done. For example, the developer may have an HTTP server installed on their machine, which has been enabled to run PHP scripts.

Many web development IDEs do this by having the user simply specify an URL to the base of the server (where pages are subsequently published to, using FTP or WebDAV).

In Eclipse, if the server is actually on the same machine, the project/folder can be "linked" to the appropriate location outside the workspace so any change to the file would be immediately "visible" on the server.

It would be interesting to investigate use of EFS for a more invisible method of deployment.

This is already (pretty much) what we have in WTP. The developer wants to use and test several server, and be able to configure and integrate those test servers with their environment (so, for example, the tool knows what the server is capable of) and developers may need to share this configuration with teammates.

JEE developers usually know a great deal about WARs, EARs, RARs, Beans, etc., but non-java developers typically know nothing of these things.

The concept of "dynamic project" and "static project" is confusing, especially to this type of non-Java developer. See bug 173901.

Non-Java web development, more so that J2EE development, needs to work seemlessly with many different types of projects.

One good example is if someone has the PHP tools installed, and are developing a PHP project, then they should be able to use HTML, CSS, JavaScript in that project as they would in a web project. (I think that it all currently possible, but we need to verify). The one thing that is not currently possible, is that someone should be able to "run on server" from that PHP project .. preferably without the PHP project doing anything special. Or, if they do need to do something, we need to work with them to make it easy ... or, perhaps even contribute a patch? But, ideally, they'd have to do nothing, since it is not really scalable to require every possible potential project type to do something special to publish to a server. For example, someone might want to "run on server" from a Java project (either a servlet, or perhaps some random HTML file?).

While ease of use is always important, non-Java web development is an area of opportunity to excel.

To be able to hide complexities (until the user needs it) is one important aspect of Usability that would help non-Java web developers. In theory, for example, even if JDT was present in the installed software, perhaps it should not be "visible" by default, unless the user requested it.

One thing to investigate is if some more specializied views or perspectives would help the non-Java web developer. This would especially be true if solutions with capabilities could not, effectively, remove all the non- required aspects of the UI.

For example, if Java is installed, it may be unlikely they would, by default, disable all the Java UI or capabilities, just for historical reasons. Or, the user may use Java occasionally, but prefer to have a perspective that "hid" it most the time, perhaps emphasizing more JavaScript development, for example.

Even if not provided "out of the box", we need to make sure users can create the types of perspectives they desire for non-Java web development..

The other part of the investigation is not just to investigate what to remove from the J2EE perspective, but what other types of perspectives non-Java developers might need. for example, perhaps a JavaScript perspective, perhaps an AJAX perspective?

Some wizards seem to always have some complications presented, even if not required, in the case of non-Java web development.

For example, a new project wizard, always lists a "target server" to select, even though, as we've said elsewhere, the non-Java web developer typically only has one server that should apply to all cases ... and the "target server" is confusing to new users, who are accustom to simpler tools.

Similarly, if there are no facets to add then that part of the new web-project wizard should not be displayed.

Besides having a number of pre-reqs, often the exact version of pre-reqs is critical. This makes it hard for the casual user to "click and go", so to speak.

One way to improve is to actually 'include', not just 'require' some of our pre-reqs, in both zips and WTP update sites. See bug 182340.

There is a number of places where dependencies can be simplified, eventually.

For example, SSE still depends on the UnDo functionality that happens to be provided in EMF. This was done since historically since EMF had it first, but now that the platform offers one, we should transition to it. (I should say transition completely, as some of the preliminary work has been done ... but, a hard part remains). 

Another case, Some of the "utilities" in JEM should be promoted to EMF (as their purpose is to provide some enhanced EMF-related function). 

One hard aspect of this line of work is that there is little pay back for each fix. It will only be when a dozen or so such simplifications are done that the pay-off would actually start to show up in simplified dependencies overall.

Typically, there is one update site for official releases. This is required to remain true, since other adopters or their products require only official releases be available to their users.

But, to speed adoption by bleeding edge end-users, we should have milestone, and even weekly update site for those users who choose to follow closely.

This is thought especially important for web developers since the time scale of web developers is sort of "compressed" ... they make frequent updates to their environments and tools.

There's a number of problems that cause WST to be larger than it needs to be.

Technically, JDT is not required by any WST code, directly, but WST pre-reqs JEM and EMF, and parts of JEM and EMF pre-req JDT.

So, for example, if we get rid of the JEM dependencies in WST, then WST would be smaller, since it would not only need JEM, it would also not need JDT.

Just for some historical reason, some plugins in WST use some utilities in JEM. We could package just the jem.utils  in WST, and the rest of JEM in JST. That would eliminate one source of JDT requirement in WST. See bug 182269.

WST as a whole, will always need some parts of EMF (such as the EMF core, and XSD Info set) but, there are other parts, such as the SDO models, that are only required in JST. While EMF does not provide exactly that packaging we need, based on features, there's no reason we can not "repackage" what we need from EMF into our appropriate features. See bug 182340.

In some cases, there are only minor dependencies on pre-reqs. In many of these cases, the pre-req should be optional, and even if there is minor loss of function, at least it gives more choices and flexibility in trading off footprint for function. Even if we in WTP still provided everything, at least there would be more options for others (such as the AJAX Tool Project) to provide a reduced install).

In some cases, using an optional pre-req can prevent large indirect "drag in" effects, where for example, a tiny dependency requires the whole JDT. See bug 182274.

WTP and it's pre-reqs are often judged as "too big". While there are many ways to make it smaller, once way is to better provide the proper packaging for end-users. Namely, end- users, those simply using it to create web apps, need only the non- sdk versions of WTP (or WST, for this discussion) and it's pre- reqs, not the SDK versions. This can make an extreme difference in size. For example, the following table shows the approximate zip file size comparing SDK vs. runtime for all of WST and its pre- reqs, in Megabytes.

So, at least 50% smaller, just by not packaging the SDK. It is interesting to note, for comparison, if by chance we somehow got rid of ALL our pre-reqs (except the Platform), then our zip file size then would be reduced by about similar amounts (85 + 33 = 118 (SDK)  or 39 + 21 = 60 Meg) ... so, hopefully we can eventually do a little of both and get down to around 30% of what we are now.

One measure of a non-Java component's adequacy, is it it provides the same sorts of functionality that is available in the Java IDE. In many cases we do, but there's a few that are noticeably absent.

Refactoring means something a little different to non-Java Web developers. In this case, it is mostly about link references and link "fix up". For example, if some images files are moved to another folder, it would be nice to offer the user to "fix up" any HTML pages that linked to those images.

While we have put in some refactoring support for JEE projects and artifacts (still more to do there) we have not done any such refactoring work for WST only users.

We currently provide no model based compare for XML, HTML, CSS, etc. In a model based compare, things like the order of attributes in a tag would not show up as a "difference" in files, since that makes no difference to interpreting that particular type of data.

Perhaps add known or common HTML tags, etc, to built-in dictionary.

Perhaps improve spell checking API (to be sensitive to content types, partition types, etc).

In general there's a few week spots in WST that could be improved. They become even more important in the context of Web 2.0 development.

Scripting languages are more important to non- Java web developers than to their JEE developer counterparts. JavaScript, PHP, etc.

The JSDT is one effort to improve JavaScript in WTP and make it a first-class development environment, on par with the Java Development environment. Plus, there are other, similar efforts, such as in DLTK that we should leverage to the extent possible.

XSL and XSLT is important in any web development, and probably more so in non- Java web development. WST currently has nothing "built in" for XSL or XSLT. While in theory many "advanced functions" could be in scope of WST, as a practical matter, just a few simple additions would drastically help web developers. Some "new file" templates, some basic "launch" capability.