RAP 1.5 M6 - New and Noteworthy

Markup Support

For a selection of widgets, simple HTML markup is now accepted in the setText() method. Currently supported widgets are TableItem, TreeItem, Label and CLabel.

To enable markup support for a widget, use the new constant RWT.MARKUP_ENABLED in the setData() method. This must be done directly after creating the widget and cannot be changed later. Here's a code example:

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>" );

The markup will be validated on the server. Currently, the following HTML elements area allowed:

• most inline elements like <em>, <strong>, <big>, <small>, <sup>, <sub>, <del>, <ins>, etc.
• linebreaks using <br/>
• images: <img src="images/example.png" width="16" height="16" />, width and height are obligatory
• links like <a href="http://eclipse.org">Eclipse</a>. To open the linked page in a new tab, you can use the target attribute.

See the JavaDoc for RWT.MARKUP_ENABLED for further information. You can try it out in our updated demo on the Rich Labels page. Check out the Table with markup page as well.

Custom Item Height

When you use markup in a Table or a Tree, you may want to set a fixed item height manually. To do so, you can use the new setData() constant RWT.CUSTOM_ITEM_HEIGHT:

table.setData( RWT.CUSTOM_ITEM_HEIGHT, Integer.valueOf( 62 ) )

A custom item height must be set directly after creating the widget and cannot be changed later.

Multiline Headers for Tree and Table

TableColum and TreeColumn now respect line breaks. No special setting is required. When the text of a header contains a linebreak character (\n), the line break will be rendered and the column height will be adjusted automatically.

Fixed Table Columns

It's now possible to exclude a given number of leftmost table columns from horizontal scrolling. This is very useful for tables that have a lot of columns, with the first column(s) containing some kind of heading or key value (e.g. a person's name) that should always be visible.

For more details, see the JavaDoc on RWT.FIXED_COLUMNS.

FileUpload Theming

The FileUpload widget is no longer bound to the theming of the Button theming but can be styled separately. All CSS properties that are supported for Button are now also supported for the new FileUpload CSS element.

EntryPoints by Path

Instead of adding entrypoints by name, and selecting them with the startup parameter in the URL, they can (and should) now be registered directly with URL path. The org.eclipse.rap.ui.entrypoint extension point supports a new attribute path. This attribute should now be used instead of the old parameter attribute. With the entrypoint below, the application will be available at the URL http://HOSTNAME/CONTEXT/example

<extension
    point="org.eclipse.rap.ui.entrypoint">
  <entrypoint
      id="org.example.exampleEntryPoint"
      class="org.example.ExampleEntrypoint"
      path="/example" />
</extension>

The brandings extension point is still supported, but will be replaced with a simpler concept in the future (see below).

Also when using the new ApplicationConfigurator API to create RAP applications programmatically, entrypoints are now registered by path.

config.addEntryPoint( "/example", ExampleEntryPoint.class, properties );

EntryPoint Parameters

Brandings in RAP are limited to adjustments needed for the web client. With the possiblity to support multiple clients for RAP, this concept is not flexible enough anymore. As a replacement, we now support simple properties maps for entry points. Every client implementation can provide their properties. The new class WebClient contains the properties for the default web client. Here's an example how to use it:

Map<String, String> properties = new HashMap<String, String>();
properties.put( WebClient.THEME_ID, "com.example.mytheme" );
properties.put( WebClient.FAVICON, "images/favicon.png" );
config.addEntryPoint( "/example", entryPointFactory, properties );

Protocol changes

The new protocol has been optimized for size and readablity by representing operations as JSON arrays instead of objects. So for example, instead of this message snippet:

{ "action": "destroy", "target": "w23" },
{ "action": "set", "target": "w24", "properties": { "visibility": false } }

the server now only answers:

[ "destroy", "w23" ],
[ "set", "w24", { "visibility": false } ]

This cuts the size of the responses by around 20% – 25% and we think it also makes the messages more concise and clear.