RAP 1.5 includes a new API to define and start RAP applications programmatically (up to RAP 1.4, this was only possible using Eclipse extensions or web.xml properties). With this new API, RAP can also be used for leightweight applications based on OSGi, but without the entire Eclipse stack, even with other OSGi containers like Apache Felix. Also traditional web applications, that use RWT as a library without OSGi, benefit from the new API.

This API contains a couple of interfaces that we had trouble to find suitable names for. If you’ve used this API already you know that there were two interfaces side-by-side in the same package with almost the same name: ApplicationConfigurator and ApplicationConfiguration. Even though these names seemed to be correct, it turned out that they were hard to tell apart, and if mixed up in a service declaration, the application did not start, without any warning.

So we reviewed the case and eventually came up with better names for the interfaces without changing the structure. Let me explain the new API and our reasoning behind it.

Implementing an ApplicationConfiguration

A RAP application consists of various parts, such as entrypoints, URL mappings, themes, service handlers, etc. All these parts constitute an ApplicationConfiguration. The configuration is like the blueprint for an application. Based on an ApplicationConfiguration, the framework can create and start an application instance. There can be more than one application instances at runtime, e.g. running on different network ports or different servlet contexts.

Hence, when you write a RAP application, you have to provide an ApplicationConfiguration.

An ApplicationConfiguration is used to configure an application before it is started. For this step, RAP follows a callback approach to leave the responsibility for creating and starting the application with the framework. Therefore, the configuration must actively configure the application. To do so, it has one method configure( Application ). The framework provides a reference to the created Application as a parameter to this method. Here’s how a simple implementation looks like:

public class SimpleConfiguration implements ApplicationConfiguration {
 
  public void configure( Application application ) {
    application.addEntryPoint( "/simple", SimpleEntryPoint.class, null );
    application.addEntryPoint( "/other", AnotherEntryPoint.class, null );
  }
}

Registering the ApplicationConfiguration

When using OSGi, the ApplicationConfiguration can be registered as a service. I’d recommend using OSGi declarative services (DS) like this:

<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0">
   <implementation class="com.example.SimpleConfiguration"/>
   <service>
      <provide interface="org.eclipse.rwt.application.ApplicationConfiguration"/>
   </service>
</scr:component>

The bundle org.eclipse.rap.rwt.osgi will automatically start this application on every available HttpService. When using Equinox, don’t forget to also include the org.eclipse.equinox.ds bundle. You can find an example of a simple RAP application using DS on github.

When using RWT as a library in a traditional web application, i.e. without OSGi, you can register your ApplicationConfiguration in the web.xml by adding a context-param with the fully qualified class name of the implementation:

<context-param>
  <param-name>org.eclipse.rap.applicationConfiguration</param-name>
  <param-value>com.example.ExampleConfiguration</param-value>
</context-param>

You can always look up the param-name in the constant ApplicationConfiguration#CONFIGURATION_PARAM. The RAP FAQ has a complete example.

Starting an Application

When an ApplicationConfiguration has been registered as described above, the application is automatically started by the framework. Alternatively, it can also be started explicitly using an ApplicationRunner:

ApplicationConfiguration configuration = new SimpleConfiguration();
ApplicationRunner runner = new ApplicationRunner( configuration, servletContext );
runner.start();

There’s a saying that there were only two hard things in computer science, cache invalidation and naming things. I don’t happen to know what’s so tricky about cache invalidation But I can hardly remember any technical problem that caused me as much of a headache as these few names did. I hope that after so many discussions, this new API will prove to be simple to understand and to use.

Thanks to Frank, Rüdiger, Holger and Jordi for great discussions and especially to Frank for contributing this new API to RAP!

The changes are part of RAP 1.5M7, published this Friday, May 11.

Tags: api, juno, new & noteworthy, OSGi, rap

The RAP team started working on a new feature called ClientScripting. It’s still in it’s infancy and will not (yet) be part of the core framework , but its already very useable. The goal is to allow adding pieces of behavior to the client-components of RAP widgets. This makes it possible to have swift, dynamic user feedback in situations that require a certain amout of logic – so far a problematic scenario for RAP applications. It can be considered an alternative to custom widget development in many cases, and might also save some network traffic. We currently focus on the scenario of validating text input while typing, and will expand from there. Interactions between widgets are not yet possible, but is planned.

As you can test for yourself, the difference between server-side and client-side validation is quite noticeable.

When using ClientScripting, you will need to know very little JavaScript, and all API is as close to SWT as possible. The project has a wiki page with all further information you might need (including where to get the code). Note that you need RAP 1.5M6 or newer to use it. If you try it out, please consider giving some feedback, report bugs or file enhancement requests.

Tags: ajax, ClientScripting, demo, javascript, juno, news, rap

The RAP 1.5 M6 milestone build is packed with new features, especially for Trees and Tables. But most notably, you can now use HTML markup in Tables, Trees, and also in Labels:

Just enable the markup support for a certain widget (see below), then you can make its text bold, italic, yellow or … no, not blinking! Actually, RAP will validate the markup and allows only a selection of tags (no <script> tags, please!). But since the <img> tag is in that list, you can add a smiley instead .

Table table = new Table( parent, SWT.BORDER );
table.setData( RWT.MARKUP_ENABLED, Boolean.TRUE );
TableItem item = new TableItem( table, SWT.NONE );
item.setText( "Some <em>text</em> with <strong>markup<strong>" );

This also means that you don’t have to break your neck anymore just to add an HTML link to your RAP UI. You can now place real links in any Label or CLabel:

Label label = new Label( parent, SWT.NONE );
label.setData( RWT.MARKUP_ENABLED, Boolean.TRUE );
label.setText( "<a href=\"http://eclipse.org/rap\" target=\"_blank\">RAP project page<a>" );

Don’t like the setData() programming? We don’t like it either. But for now, it’s the simplest way to expose additional functionality without changing the SWT API. For RAP 2.0, we plan to come up with some better API for our extensions.

Try out the markup support in our updated online demo! BTW, did you notice that this is a deep link into the demo application? Yes, there was a bug preventing them from working in RAP for long, and it’s now finally fixed! You can now use the BrowserHistory to navigate to a certain point in your application right on startup. Here’s the link to an example page that shows markup in a Table.

And there are more Table and Tree enhancements, such as the fixed columns support that lets you exclude one or more colums from horizontal scrolling. Check out the full list of changes in the New & Noteworthy.

Get it while it’s hot, this milestone is a must have

Tags: juno, milestone, new and noteworthy, rap

Good keyboard controls have become a staple of modern web applications, such as Google Mail, Github (press “?”) and Flickr. However, almost every browser implements key events slightly differently, all with some quirks, and none of them like in SWT. For this reason, key events in RAP had, until recently, several issues and limitations. That is a thing of the past now, as the key events implementation has been largely rewritten in RAP 1.5M5, and now finally works reliably. This also brings some general changes to RAP key event handling.

• Some keys that didn’t work at all (like arrow-keys in Firefox), work fine now. This also fixes the JFace Content Proposal.

• Several non-alphanumeric keys had the wrong keycode,  those are fixed.

• Key events are no longer blocking the UI when sending the Ajax request to the server.

• There is now a feature called “active keys”, which makes it possible to drastically reduce traffic traffic.  It was already present in RAP 1.4, but has been greatly improved.

• Another new feature is called “cancel keys”. It allows to suppress the browsers and widgets default operations associated with any given key.

• The “cancel keys” replace the now-defunct support for the doit flag on key events.

Continue Reading »

Tags: eclipse, juno, Key Events, Keybindings, rap

In the RAP framework, the widgets in a website are remotely controlled by the web server. The server does this by sending messages to the client in response to Ajax requests. Until now, those messages used to contain proprietary JavaScript that has been evaluated by the browser. Apart from the drawbacks of using eval to process server responses, this tightly couples RAP to its default browser client. The messages were so specific that only this client could understand them.

One of our goals for RAP 1.5 is to open the framework for alternative client implementations. After all, the messages from the server contain precise rendering commands that are not at all specific to JavaScript. Commands like “create a button with text ‘Ok‘, set its size to 190x25px, and place it at pos (23,42)” or “change the text color of the label with id ‘w47‘ to ‘#ff0000‘” can be rendered by any client that is able to create and manipulate widgets. It doesn’t have to be a JavaScript client, also clients written in other languages like Java or Objective C can implement it. Clients can render widgets with any UI technology, be it SVG or even a mobile device’s native widget set.

To allow for those cases, we exchanged the communication format with a simple predefined format based on JSON. With the M4 build published today, all responses from a RAP server are now plain JSON. This also makes the debugging much easier, since developer tools like Firebug display the structure of a message.

When designing the protocol, we took great care not to limit the exchange format to widgets. Instead, we created a generic synchronization protocol for any kind of objects. Objects are identified with a unique id, and every operation is related to a target object that is referenced by its unique id. There are different types of operations: one to create an object, one to destroy it, one to change some properties on an object, etc. Every message from the server contains a list of operations, besides some meta information.

You’ve guessed that we already have some prototypes for alternative RAP clients in progress. We’ll write about them soon…

Tags: eclipse, juno, new and noteworthy, protocol, rap

With summer behind us and autumn almost here (in the northern hemisphere), you can feel the change in the air.

The Eclipse and Equinox teams have made Juno Milestone 2 available, however, these milestones are no longer based on the Eclipse 3.x stream. Starting with this milestone, we will be encouraging users to actively test the 4.2 stream. The Eclipse Juno release (coming June 2012) will be based on the 4.x stream.

There are a few goodies in this release including Quick-Fixes for loop refactoring:

An enhanced Ant editor:

And some fancy new transitions:

Checkout the entire New and Noteworthy. Or better yet, download the milestone and take it for a spin.

Tags: juno

Computer cluster, taken from http://thefullwiki.org/Parallel_programming

While most of us are busy with that latest bits of the Indigo release, some have the joy to work on one of the next new features in RAP: support for high availablity clusters.

Let me briefly mark out what we mean by clustering support and what we don’t. Load balancing clusters are used if you whish to provide your applications to a large number of users. If your application provides critical servies you may also want to make it fail safe by running it in a high availablity cluster.

A high availability cluster operates by having redundant nodes. So that if one node crashes, the service as a whole is unafected as other nodes take over the work. Whereas load balancing RAP applications is possible since ever, failover clusters put further requirements on the framework.

To be able to migrate sessions between nodes in a cluster, all session data has to be serializable. Also, the current implementation preserves the server-side execution flow within a UIThread in order to single-source RCP applications. These two form the main work areas.

• All session data must be prepared for distributing sessions among cluster nodes for failsafe operation.
• A new life cycle for processing requests without a UIThread was implemented and RAP can be configured to run with either of them.

The new life cycle also makes it easier to access security or transaction contexts and is conform to the JEE Specification. If you don’t use blocking dialogs or workbench features and want to be able to eventually run your application in a cluster – then this is for you.

For more details, see the RAP Wiki.

Tags: eclipse, juno, rap