Here's a list of the most noteworthy things in the RAP 1.5 release which will be available for download on June 27, 2012. In the meantime, all changes described here are available in the most recent nightly build.
The fragment org.eclipse.rap.rwt.q07 is no longer needed and has been removed. The contents are now located in the org.eclipse.rap.rwt bundle.
The q07 fragment had originally been introduced to be able to support different versions of the qx client library. Meanwhile, we decided to maintain and evolve our own copy of this client library (bug 320993), so the fragment is not needed anymore. However, with the new protocol (bug 311355), it will become possible to plug in alternative clients for RAP.
A new bundle org.eclipse.rap.rwt.osgi has been introduced that integrates RAP with OSGi.
With this architectural change, it is now possible to use RWT in OSGi applications without
having to include org.eclipse.rap.ui and all its dependencies.
Instead of registering your RAP application's entrypoint, theme, etc. as extensions
(which involves dependencies to the extension registry and more equinox core bundles),
you can now implement the service interface
org.eclipse.rwt.engine.ApplicationConfigurator and register it as an OSGi
service.
public class MyConfigurator implements ApplicationConfigurator {
public void configure( ApplicationConfiguration configuration ) {
configuration.addEntryPoint( "default", SimpleEntryPoint.class );
configuration.addBranding( new AbstractBranding() {
public String getServletName() {
return "myapp";
}
} );
}
}The RAP workbench also uses this new bundle to connect with an OSGi HTTP service, so you'll always have to add this new bundle to your launch configurations.
The runtime repository now contains two different features: One contains only the RAP bundles and the other feature provides all bundles that are required for a complete RAP target platform. If you want to create a simple RAP target platform, you'll need both.
This split will make it easier to work with mixed targets. If you already have the Equinox Core SDK and Jetty, you'll only need to add RAP itself. This way, you prevent duplicate bundles in your target platform.
Support for transparent session failover was added to RWT. This enables applications to run in a high-availability cluster.
RWT had to be extended in two places to achieve this. An alternative life cycle was implemented that does not use a UI Thread because threads cannot be migrated. With this simple life cycle implementation, RAP isn't fully compatible with SWT anymore, but the differences are small. As a side effect, this life cycle also eases integration with JEE and other technologies that use thread-local variables to access to security or transaction contexts.
The second area of work was to enable sessions to be replicated between cluster nodes. Therefore all classes in RWT whose instances will have session scope were made serializable. Note that application code must also be prepared in that all objects that live in the session scope must be serializable.
Serializable RWT sessions can also be used to swap inactive sessions onto disk and thereby releasing the memory consumed by them. This allows for infinite session timeout settings and saves users from annoying 'the session has timed out' messages.
For further details, please visit our Cluster wiki page.
The UI callback was redesigned and made more robust.
When a callback request fails, the client sends a new callback request to re-establish the broken callback connection. To avoid unnecessary load on the client, retry requests are sent with a suitable delay.
On some servlet engines, an active UI callback prevented the session from expiring. This has been solved so that applications can activate the UI callback without interfering with the session timeout.
The Server Push wiki page summarizes how the mechanism works internally.
The Theming now supports text shadows for most widgets that display text: Shell, Label, CLabel, CTabFolder, Button, DateTime, ExpandBar, Group, Link, List, Spinner, TabFolder, Menu, ToolTip, Combo, CCombo, Tree, Table, Text, and ToolBar
Text shadows are not available in Internet Explorer due to this browser's lack of support for this feature. Transparency for text shadows is supported using the rgba notation for color. Example:
Button {
text-shadow: 0 1px 0 rgba( 0, 0, 0, 0.3 );
}The server-side part of the Tree widget was considerably improved and optimized. Now, a Tree with SWT.VIRTUAL style can handle huge item counts without performance degradation.
For a live demo, check out the tab called Complex Data in our Examples demo.
We planned this for a long time, and now it's becoming reality: the communication between server and client is being replaced with a new, JSON-based format (see bug 311355). This new protocol will enable alternative client implementations for RAP.
In this milestone, we focused our efforts on retrofitting LCAs to utilize this new protocol for communication with the client. The following widgets are already using the new protocol: Button, Combo, Composite, Group, Label, Link, ProgressBar, Sash, Scale, Shell, Slider, Spinner, Text, CCombo and CLabel. Changes are currently tracked in bug 351945. Also the text size determination has been switched to the protocol.
We're planning to complete this conversion before the end of this year. As the protocol stabilizes, we'll update the specification on the RAP Protocol wiki page.
RAP 1.5 is about to get a new default look. The new theme aims at bringing a modern, decent look into RAP applications with more white space and subtle usage of roundings, shadows and gradients. To achieve this, the themability of many RWT widgets has been extended by adding missing CSS properties. The new look is already part of M3, but we will continue to improve and polish the theme during the next months. Any feedback is highly welcome.
Internet Explorer 9 was a significant improvement over previous versions, finally catching up to other browsers regarding performance and compatibility. RAP can now fully utilize all its new features (HTML5, CSS3, SVG) by switching to standard rendering in IE9 (as opposed to quirksmode used for previous IE versions). This gives RAP applications a noticable performance-boost in IE9, especially when using GC for drawing complex graphs.
As technology marches on, we also decided to no longer officially support IE6 in RAP 1.5. RAP 1.4 will continue to support it.
The way to start standalone RWT applications has been changed. The former init parameters have been replaced by an API that allows you to configure all aspects of the application to be started. This web.xml fragment and code snippet shows how starting an RWT application now looks like:
<context-param>
<param-name>org.eclipse.rwt.Configurator</param-name>
<param-value>com.example.ExampleConfigurator</param-value>
</context-param>
<listener>
<listener-class>org.eclipse.rwt.engine.RWTServletContextListener</listener-class>
</listener>public class ExampleConfigurator implements ApplicationConfigurator {
public void configure( ApplicationConfiguration configuration ) {
configuration.addEntryPoint( "default", ExampleEntryPoint.class );
configuration.addBranding( new ExampleBranding() );
// ...
}
}
The RWTServletContextListener needs to be registered so that RWT is
notified when the servlet context is created.
The remaining init parameter is used to specify a configurator, an
implementation of ApplicationConfigurator. This class is created and
its configure method is called before the application starts.
With the given ApplicationConfiguration object you can control all
aspects of the application.
Please read this FAQ entry for more details. We will integrate this information into the developer documentation before the 1.5 release.
In this milestone, we switched some more widgets to the new client/server protocol like Tree, TabFolder, Browser and ToolBar.
We're planning to complete this conversion before the end of this year. As the protocol stabilizes, we'll update the specification on the RAP Protocol wiki page.
With this milestone, all Ajax responses from a RAP server are now in plain JSON format. No JavaScript is included anymore. This makes the responses much more readable and eases debugging.
With this new protocol, it is now possible to develop alternative clients for RAP. The exact format is described in the RAP Protocol wiki page. Some details may still change until the release.
Since RAP 1.5 will be available together with Eclipse Juno, the target platform is now based on Eclipse 4.2 instead of 3.8. However, the RAP implementation of the Eclipse Workbench remains to be based on 3.x. But there are a couple of important changes in the target platform.
org.mortbay.jetty to org.eclipse.jetty.
Instead of two, Jetty now consists of seven bundles.
org.apache.felix.gogo.*) support it.
Please adapt your launch configurations to these changes as needed.
The RAP default theme is now an equitable theme, and it is no longer used as a fallback for custom themes. Instead of the default theme, all theming properties now have a default value which is used as a fallback in case the theme does not define a value for this property.
Unlike the RAP default theme, these fallback values will not change. They are chosen to be plain values without any effects, i.e. no gradients, rounded borders, or shadows, just plain black-and-white. With this change, custom themes will be more stable. Changes to the RAP default theme will not affect custom themes anymore.
The default values are still defined in the respective
<Widget>.default.css files, and the RAP default theme is now contained
in a file of its own.
For details, see
bug 363736.
The RWT.ACTIVE_KEYS constant has been
introduced in RAP 1.4
to allow for key bindings.
Now this constant can also be used to limit the keys that will trigger a key event on a
single widget.
This means that when a key-listener is attached to a widget,
it's now possible to choose beforehand which keys will trigger events.
This can drastically reduce the traffic caused by key-events.
For more details, see the JavaDoc on RWT.ACTIVE_KEYS.
The new constant RWT.CANCEL_KEYS can be used to specify a
list of keys to be cancelled.
Instead of dynamically cancelling events by setting the doit-flag to
false in a KeyListener, this allows to do the same thing in a
static way.
When CANCEL_KEYS are defined, this will suppress the default operation associated with these
keys, e.g. changing focus on TAB or closing a popup with ESC.
Note that some browser shortcuts can not be suppressed, like changing the browser tab with
CTRL+TAB.
Like RWT.ACTIVE_KEYS, this can be done either globally, using
Display.setData(), or on a
per-widget base
using Widget.setData().
For more details, see the JavaDoc on RWT.CANCEL_KEYS.
We decided to replace the support for dynamically vetoing key and traverse events
in favor of the static approach described above.
With this change, setting the doit-flag on KeyEvents and
TraverseEvents has
no longer any effect
in RAP.
As a replacement, the RWT.CANCEL_KEYS constant should be used.
JFace cell editors have already been adapted to this change.
We've introduced KeyEvents and TraverseEvents in RAP 1.2 to be
able to support JFace cell editors.
There were multiple issues remaining that we could never overcome,
such as synchronous HTTP requests not working correctly in some browsers,
or security-restrictions for certain keys for in others.
Over time, we've realized that dynamically preventable key and traverse events are not
going to work fully and reliably in all browser.
We dislike taking functionality away, but in this case we are convinced that the improvements are more valuable than the loss. We were able to heavily improve the key event handling and to fix several issues regarding missing events or wrong values. The change also allowed us to send key events in asynchronous HTTP requests in all browsers, making the client UI more responsive.
The key event fixes mentioned above also allowed us to repair our
ContentProposalAdapter implementation.
Now we can provide a fully functional content proposal that can be operated completely by
the keyboard on all browsers.
Combined with the RWT.ACTIVE_KEYS constant, the requests can be limited to
those needed for opening the content proposal.
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:
<em>,
<strong>,
<big>,
<small>,
<sup>,
<sub>,
<del>,
<ins>, etc.
<br/>
<img src="images/example.png" width="16" height="16" />, width and
height are obligatory
<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.
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.
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.
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.
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.
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 );
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 );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.
Finally, we support the SWT.ARROW style flag for Button.
This style is used together with one of SWT.TOP, SWT.BOTTOM,
SWT.LEFT, or SWT.RIGHT to create buttons with an arrow symbol.
Of course, the style of arrow buttons can be configured in a theme:
Button[ARROW] {
border: 1px solid #bdbdbd;
padding: 10px;
}
Button-ArrowIcon[UP] {
background-image: url( theme/images/arrow-up.png );
}
...
The Browser widget provides two methods to execute JavaScript,
execute() and evaluate().
Both methods are blocking and won't work with the new JEE_COMPATIBILITY mode.
Therefore, a new utility class BrowserUtil has been introduced to evaluate
JavaScript in a Browser widget in a non-blocking way.
Instead of waiting for the script to be executed, you provide a
BrowserCallback implementation that will be notified when the evaluation has
completed:
Browser browser = new Browser( parent, SWT.NONE );
...
BrowserUtil.evaluate( browser, script, new BrowserCallback() {
public void evaluationSucceeded( Object result ) {
}
public void evaluationFailed( Exception exception ) {
}
} );
The support for simple HTML markup has been extended to the List widget.
It can be activated in the same way like in Table and Label, using the constant
RWT.MARKUP_ENABLED.
Custom item height is supported too, using RWT.CUSTOM_ITEM_HEIGHT.
The theming for Shell and Composite now supports these additional
animations:
flyInTop, flyInRight, flyInBottom, flyInLeft,
flyOutTop, flyOutRight, flyOutBottom, flyOutLeft
In addition, Composite now also supports
fadeIn, fadeOut, slideIn, and slideOut.
The animations are shown when the widget either appears or disappears, respectively. Since the widget's children are animated together with its parent, it's now possible to animate any widget by placing it in a Composite. It should be noted that the animations may not run smoothly in older browsers, or when the Shell/Composite is very bulky. Using fadeIn/Our or slideIn/Out in IE7 or 8 can cause minor rendering glitches during the animation, depending on the contained widgets and their theming.
In 1.5 M3, we introduced a new API to define and start RAP applications programmatically. We've noticed that the interface names involved in this new API lead to confusion, therefore we decided to rename a couple of interfaces to make the API easier to understand and to use. This post explains the new API in more detail.
To define an application, you now have to implement the interface
ApplicationConfiguration:
public class SimpleConfiguration implements ApplicationConfiguration {
public void configure( Application application ) {
application.addEntryPoint( "/simple", SimpleEntryPoint.class, null );
application.addEntryPoint( "/other", AnotherEntryPoint.class, null );
}
}
When registered as an OSGi service, an application instance will be started from this
configuration by the org.eclipse.rap.rwt.osgi bundle.
Also, the param-name for registering an ApplicationConfiguration in a
web.xml has changed. It is kept in the constant
ApplicationConfiguration.CONFIGURATION_PARAM.
The JavaDoc of this constant contains a code example.
Alternatively, an application can also be started programmatically using an
ApplicationRunner:
ApplicationConfiguration configuration = new SimpleConfiguration();
ApplicationRunner runner = new ApplicationRunner( configuration, servletContext );
runner.start();Our source code has moved from CVS to Git. The CVS still exists but is now read-only. If you used to with RAP source code from CVS, check the source code page for the new repositories.
This list shows all bugs that have been fixed for this release.
The above features are just the ones that are new since the last milestone build. Summaries for earlier builds:
Copyright © 2012 The Eclipse Foundation. All Rights Reserved.