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

Besides the usual bugfixes, performance and stability improvements, the 0.5.3 release brings some often requested features to an Android handset near you.

For more information visit: http://rapmobile.eclipsesource.com

The Tree widget supports the SWT.VIRTUAL style flag

The support of the SWT.VIRTUAL style flag allows you to easily scroll through huge amounts of data. While you are scrolling through tree content, the data to be displayed is automatically loaded on demand in the background. Intelligent pre-caching makes it possible to have content visible even when scrolling very quickly. If the complete data cannot be delivered quickly enough, you are still able to scroll through the available content while the data is fetched in the background.

Buttons can be colorized programmatically

We refined the support for background colors on buttons. You can now call button.setBackground(redColor) to change the background color of the button. The change in color applies not only to the default state but to all button states such as pressed, disabled, focused etc.

Opening and closing shells is animated

In the Android client we map an SWT shell to behave similarly to an Android activity. Multiple activities can be stacked on top of each other and the user is able to switch between them with the back button on the device. The creation and destruction of an activity is animated according to the current device. We play these very same animations on shells when they are created or closed. On a Samsung Galaxy S2 (Android 2.3.x) a fly-in animation is performed whereas on a Samsung Galaxy Nexus (Android 4.0.x) a fade/scale animation is applied.

Text widget tooltip is displayed in text field

If a tooltip is set on a Text widget we now display the tip inside the Android EditText. You can use this to add hints for completing fields.

Font probing on startup is implemented

When starting a new RAP session we measure the probe strings sent from the server. These probe strings allow the server to categorize the clients according to their text sizes. The server can use cached string sizes so that it doesn’t have to request that the client re-measure strings cached in a previous session.

UI updates are accumulated to execute in one operation

When a server response triggers UI changes, we now gather all these changes and execute them altogether. Previously, we applied the UI changes on the fly which resulted in incremental changes to the UI. The new approach creates a more native-like experience as the UI changes state in one operation.

Client sends a customized HTTP User-Agent string

The RAP mobile Android client sends a customized User-Agent string. It contains the Android version, information about the device and the RAPmobile client version. Example: Android/4.0.2,14 (samsung; Galaxy Nexus) RAPmobile/0.5.3

Okay, then I cannot tell you any news, but the participating projects at Eclipse shipped another coordinated Simultaneous Release in time! This Indigo SR2 release contains many improvements and bug fixes, e.g. an update of the underlying platform to 3.7.2. It’s worth an update!

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…

Update: APIs have changed a bit meanwhile, so I updated the code below accordingly. Entry points are now registered by path, and JEE_COMPLATIBILTIY has become the default mode, which makes the main loop obsolete in this kind of applications.

RAP is well known as an “RCP for the web browser”, including workbench, extension points, and all that stuff. Indeed, one of the greatest features of RAP is its ability to reuse RCP code in web applications. But did you know that you can also use RAP’s widget toolkit (RWT) to create simple web UIs for your applications, without the heavy weight Eclipse UI stack?

With RAP 1.5, you can now simply include RWT in any OSGi application. You only need two bundles: org.eclipse.rap.rwt (the RAP widget toolkit itself) and org.eclipse.rap.rwt.osgi which integrates RWT with the OSGi HTTP service. There are no tie-ins with Equinox anymore, thus RAP also works with other OSGi containers.

To create a UI with RWT, you have to implement the interface IEntryPoint, here’s a simple example:

  public int createUI() {
    // Create a maximized top-level shell without trimmings that represents the main "page"
    Display display = new Display();
    Shell page = new Shell( display, SWT.NO_TRIM );
    page.setMaximized( true );
    page.setLayout( new GridLayout() );
 
    // Create contents of main shell
    Label label = new Label( page, SWT.NONE );
    label.setText( "Hello" );
    Button button = new Button( page, SWT.PUSH );
    button.setText( "World" );
 
    // Open the top-level shell and run the main loop to process events
    page.layout();
    page.open();
    return 0;
  }

Now what’s new is that, instead of registering this entry point with an extension point, you can now implement the new ApplicationConfigurator interface like this:

  public void configure( Context context ) {
    context.addEntryPoint( "/simple", SimpleEntryPoint.class );
    context.addBranding( new AbstractBranding() {
      @Override
      public String getServletName() {
        return "simple";
      }
      @Override
      public String getTitle() {
        return "Simple RWT Example";
      }
    } );
  }

When this implementation is registered as an OSGi service, you can access the UI with a web browser:


You can check out the example project example.rwt.simple from my rap-helpers repository on github. Please note that for this example to run you need declarative services in your target platform, which are not included in the RAP 1.5M1 target but in the latest nightly build. Also be aware that the new API is still provisional and may change again until the final release.

Kudos to Frank Appel, who contributed the new OSGi integration. He has a more detailed introduction to the new OSGi integration and examples for configuration in his blog. BTW, Frank and me plan to demo the possibilities of this approach in our talk Dynamic web applications with OSGi and RAP at the EclipseCon Europe – vote for it if you’re interested!

I thought that this data would be a good example to show the ability of the new Tree widget in RAP to display huge datasets.

It’s clear that you cannot create half a million UI elements in a browser without running out of memory. Neither can you load the entire dataset (> 2GB on disk) into memory on the server. You need a mechanism to load and display data on demand.

As of this week, the RWT Tree widget has full SWT.VIRTUAL support, i.e. it is capable of creating Tree items only at the moment they become visible. This feature is used by the JFace TreeViewer to request data from a lazy content provider on demand.

So, in order to make a complex data set accessible with a web UI, you just need to write an ILazyTreeContentProvider implementation. That’s about one screen of Java code, mostly copied from a JFace snippet. That’s all.

Check out the example on our online demo (navigate to the tab called Complex Data). The source code of this demo page is available on github.

Full SWT.VIRTUAL support for the Tree widget is available in CVS and will be part of RAP 1.5M1.

The FileUpload is a new widget that wraps the HTML file selection <input> tag. It looks like a button, and when it’s pressed, a native file dialog opens up that lets users select a file from their local file system. On file selection, a SelectionEvent will be fired. You can then programmatically upload the selected file to an http server using FileUpload.submit( URL ).

In order to receive and store the uploaded files on the server, you also need a server-side component. We created such an upload server component in the RAP Incubator. It’s called FileUploadHandler and it uses the Apache fileupload component internally. It’s included in the bundle org.eclipse.rap.rwt.supplemental.fileupload. This handler accepts file uploads to a certain URL (FileUploadHandler.getUploadUrl()) and delegates the data to a FileUploadReceiver. You can either use the provided DiskFileUploadReceiver or create your own receiver to do whatever you like with the uploaded data: put it into a database, or simple analyze the data and discard it.

Sounds complicated? Well, there’s a much easier way to upload files with RAP 1.4! We’ve encapsulated the entire upload process in an implementation of the SWT FileDialog, which is also available in the incubator.

To make it easy to use, we now provide an update site for the Incubator. To use the FileDialog in your application, all you have to do is to:

1. include the bundles from the RAP Incubator repository http://download.eclipse.org/rt/rap/1.4/incubator/ in your RAP 1.4 target platform, and
2. add a bundle dependency to org.eclipse.rap.rwt.supplemental.filedialog to your project (yes, you have to use Require-Bundle here because this bundle contributes a class to the org.eclipse.swt.widgets package, effectively creating a split-package).

That’s all. Now you can use the FileDialog just like in SWT:

  FileDialog fileDialog = new FileDialog( shell, SWT.TITLE | SWT.MULTI );
  fileDialog.setText( "Upload Files" );?
  fileDialog.setAutoUpload( true ); // This API will change, see below!
  fileDialog.open();
  String[] fileNames = fileDialog.getFileNames();

After uploading, the dialog closes and the variable fileNames contains the absolute file names of the uploaded files on the server’s file system. There’s an auto-upload feature that is really nice (I think it should be the default) – with autoUpload on, the upload starts immediately after file selection. A user can still press Cancel to prevent the application from using the uploaded files.

Note: Please note that this stuff is in the incubator and not part of the 1.4 release. The API and implementation may (and will) have to change and mature over time. However, if you use the latest version from 1.4/incubator site, you’ll always get a file dialog that will work with RAP 1.4. The server-side upload receiver and the required Apache bundles are also included.

We hope you enjoy these new features. Please try them out, tell us what you think, open bugs for the new stuff, and help us improving them.

Kudos to our new RAP committers Austin Riddle and Cole Markham who created this great new feature!

Update: I mistakenly left out the “.rwt.” from the bundle namespace in the original post, the bundle names are fixed now in the text.

Update: The 1.4 incubator repository has been updated with a newer version of the file dialog that is compatible with RAP 1.4. This update fixes the problem with missing file names mentioned in the comments.

1. We have a new implementation of the SWT Tree widget which is faster, more flexible, and provides many new features.
   
2. In order to support new application servers that already ship with Servlet API (javax.servlet.*) 3.0, RAP is now able to leverage the new Servlet specification. Deploying RAP on application servers like Tomcat 7 or Glassfish 3 is now possible.
3. Since RAP 1.3 you can easily use IApplications instead of IEntryPoints. With this milestone the RAP launcher supports choosing and launching IApplications.
   

• Check out the complete New and Noteworthy for M1.
• Get RAP 1.4 M1 from the RAP download site

1. Eventually, a GraphicsContext implementation that lets you draw onto the browser using SWT API! In the early days of RAP, we regarded this as being impossible.
   
2. Animations support in CSS enables cool effects like sliding menus, fading tooltips, and more.
   
3. Vertical-only grid lines make Tables with alternating row colors look much clearer. I had this feature on my todo list for almost one year.
   

• Check out the complete New and Noteworthy for M7.
• Get RAP M7 from the RAP download site or
• Get the M7 Eclipse for RCP/Plug-in Developers package that includes everything you need to develop RCP and RAP applications.

Therefore we now integrated the core functionality needed for such animations into RAP. Since the existing client-implementation of RAP was not written with such a feature in mind, it was considerable effort to do this without changing much of the existing code. And for the same reason, there are currently some limitations on what we can do with this feature. However the groundwork is done, and we hope to expand on that in the future.

Just like with gradients and rounded borders before, you can expect the number of supported widgets and effects to grow. You should keep in mind though, that this feature is meant only for subtle animations that seamlessly integrate into the UI. We can and will not turn RAP into some kind of multimedia powerhouse where everything is moving all the time.

For now, “Button”, “Menu”, “ToolTip” and “Shell-DisplayOverlay” each have one effect that can be enabled. This is done using RAPs CSS-theming, not Java, as this kind of animations are mainly eye-candy and don’t add any functionality. The syntax for this is based on a small and easy-to-use subset of the CSS3 working draft for animations. For example:

Button[PUSH] {
  animation: hoverIn 350ms ease, hoverOut 600ms ease-in;
}

This generates a faded hover-effect for buttons.

Animations work on all browser supported by RAP, but might not run smoothly on very old machines. They will be part of the upcoming 1.3M7 build. To see what we can do for now, check out the new “Theming”-Page in our examples-demo.