e4 and RAP

For those of you who don’t know, RAP (the Rich Ajax Platform) provides the ability to run your Eclipse application on a server and have the UI served up in the browser using Ajax techniques. e4 is the next generation Eclipse platform that is targeting, amongst other things, the ability to do web UIs. Hmm, seems like there should be something in common.

Indeed! Yesterday the RAP team spent the afternoon looking at e4. First task was to check out the relevant code and setup the e4 photo demo. With that running it was time to switch out the target platform to use the RAP target platform.  Basically RAP provides alternate implementations of things like SWT and JFace. These maintain all the UI object structures on the server but with widgets that render in the browser. So putting in the RAP target substitutes these new implementations.

Moving to the RAP target resulted in quite a few compile errors but most were actually the same error in many places. For the most part alternates were substituted and in some cases, for the purposes of getting running, bits of the demo were hacked out. One of the major bits that had to be removed was the Nebula widgets–these just don’t have RAP equivalents yet. Of course, the photos in the photo demo are being displayed using these now missing widgets but that’s a different story.

So with that done, the app comes up. e4 on RAP or RAP on e4. However you like to say it.

In the end it was relatively easy once the details of how e4 starts up and works were  were understood. The result is actually too ugly to show here as the CSS styling has not been mapped onto the cool new RAP styling work. That’s a topic for another afternoon.

The goal of this afternoon adventure was to explore the space and see what the further topics of investigation might be. In that, it was a great success. Here is a short list of topics:

CSS styling — Much of the the property setting and basic styling will be easy to integrate but there appear to be some places where a graphic context is used. This will be harder. Perhaps there are some abstractions that can be done there…

RAP IEntryPoint and e4 Product/Application — Since a RAP system can have many concurrent sessions, there will be many concurrent applications.  IEntryPoint is the RAP abstraction for this. It would be good to investigate the use of the OSGi application model.

Nebula integration–This is harder.  Nebula widgets do all manner of stuff.  There has been work to do Draw2d but more is needed. In any event, that is not a critical element of e4.

Session support–Look at contributing RAP’s session support code to the parts of Eclipse that make up e4. This is likely to go a number of places but would be a very useful thing to have.

Internationalization–The extension registry and other parts of the system expect there to be just one locale. With the web there are users all over the place and they expect to see their content in their language.

Other cool stuff.  Stay tuned to this channel and post a comment if you are interested in RAP and e4 as another way of bringing your apps to the web.

1 Comment
  • Posted at 10:31 pm, February 23, 2009

    Great to see that the e4 work has been investigated for use with RAP!

    RAP does a good job of taking the UI written for the desktop and “remote’ing” it to the web. Perhaps though in this case the photo app’s desktop “shape” is wrong for the web.

    I’ve been speaking to Erich and others recently about the notion that the workbench model should just describe the parts and their relationships, with then all visual decisions being made elsewhere. Presently there’s an odd mix of some decisions such as containment within sashes, sash positions, etc., being made in the model, and others such as fonts and colors made in CSS. Then there’s the problem that once you get below the part level, it’s up the handler code to make the additional child widgets. If instead that widget creation was declarative, then for the RAP case we could create an equivalent web control rather than ‘web-ifying’ the Gallery widget.

    So I’m not sure if the right solution for RAP is:
    1) Make a remote’able Gallery widget (like you’ve done for SWT)
    2) Override the e4 modelled workbench renderers to produce web’y things instead of producing SWT things that can be remote’d (cut out the middle man)
    3) Copy the e4 photo xmi, replacing the thumbnails part with something specific for the web
    4) Go the full-on declarative route where the parts describe the widget tree declaratively and, like the workbench model renderers, produce the right widgets for desktop or web.