Embedding web UI components in Eclipse using e4

The demand for software that can be accessed through a web UI is increasing. We already expect software for occasional use (e.g. online shopping, banking, filling out forms, ...) to be accessible from a browser, without having to install anything locally. Over the last few years, more and more producticity applications (email, documents, spreadsheets, etc.) have become available through browsers as well. It is only a question of time until software development tools (at least for a certain class of uses) will have to have a web UI as well. In fact, a few browser-based IDEs already exist, such as Mozilla's Bespin project, and a very recent example: embed, a special-purpose IDE for embedded development.

At the same time, locally installed "rich client" applications, especially software development tools, aren't going to go away soon - there is a huge investment in the tools we have today, and I don't expect that all of this will be reimplemented using other technology just because web UIs are now the cool new thing to do.

So the obvious question is, how can we, the Eclipse community, prepare ourselves for the trend towards the web, while keeping our desktop users happy?

One approach is to keep the current programming model and just "make the stuff run in a browser". Fundamentally, this is very hard because the existing code we have today is not written with a client-server separation in mind. To a certain extent, it can be made to work though, and we have two examples of this at Eclipse, in form of the RAP project, and the experimental "SWT Browser Edition".

The basic idea behind RAP is to place all application and UI logic on the server, including all widgets and their state, and to render those widgets on the client in a web browser while sending user events back to the server. However, there are a couple of characteristics of RAP that limit its applicability: For example, the "stuff" you run in a browser will be a complete application as opposed to individual UI components, high-latency situations are problematic, and you cannot run application code on the client side. (I hope the RAP team will let me know in the comments if I got any of this wrong.)

The work on SWT BE "browser edition" is another take at the same problem, taking, if you will, the opposite approach: Client code (application and UI logic) makes use of the SWT API and as such can run in a desktop situation just fine. For "making it run in a browser", all the code is cross-compiled - to JavaScript for the Dojo port of SWT, or to ActionScript for the Flex port of SWT. So in a nutshell, instead of placing all application code on the server as with RAP, all application code ends up running on the client, in a browser. The obvious problem with this approach is that you still need code that runs on the server, to at least send data to the client and to receive updated data from the client, and that more often than not, you will end up with too much code on the client for execution. Of course, you could rewrite your existing code and ensure a proper client-server split, but if you are rewriting it anyway, why not go all the way and rewrite it using HTML and JavaScript?

For the e4 0.9 release, we have done the first step of exactly that - we rewrote or "cloned" an existing component using HTML, CSS, JavaScript, and Dojo on the client side. The idea is to gradually move certain components (not complete applications) over to use web technology, while still having these components appear in the desktop Eclipse client as first-class citizens. As a first example, we chose the PDE site.xml editor, because of its relative simplicity but also because it is a good representative of a whole class of form-based UI components in Eclipse. We wanted the end result to run in a regular browser, as well as an editor inside of Eclipse. Here you can see it running stand alone in a browser:

To make the editor work in a regular browser, it had to have a "real" server-side counterpart. Luckily, Eclipse already ships with an embedded servlet container, Jetty. This means that the web UI editor could talk to a servlet running in the same VM as the embedded browser widget rendering the UI. This is not unheard of at all - the Eclipse help system is taking the exact same approach.

However, just presenting the unchanged web UI in an embedded SWT browser widget - backed by IE if you run Windows, Firefox on Linux, and Safari on the Mac - is not enough. The editor would only be a first-class citizen in the Eclipse UI if, for example:

• you didn't have to authenticate to the web UI every time you open an editor,
• the editor signaled unsaved changes through the usual "*" in the editor tab, as opposed to an indicator in the editor itself,
• you can trigger saving your changes using the menu (File>Save ),
• etc.

In other words, the editor needs to make use of appropriate Eclipse APIs that connect Eclipse UI components such as views and editors to their context: the Eclipse workbench. One of the goals of e4 has always been to simplify the core APIs, and to make them accessible from other programming languages. So in a sense, we have started to make this real by offering JavaScript APIs that can be called by web UI components: to signal that they have unsaved changes, to provide a callback that will save those changes, etc.

Give it a try! After downloading the e4 0.9 SDK, start it up with an empty workspace and create an update site project (Ctrl+3, 'nusp'). Add some features and categories to it using the regular PDE site.xml editor, save, and then right-click on the site.xml file and use "Open With" to open it with the web-based editor. It will look like this:

Please leave comments if you have any questions. I will try to write up more about this in the next couple of days, going into more technical detail.