Here's a list of the most noteworthy things in the RAP 2.0 M3 milestone build which is available for download since November 16, 2012.
Based on the new Client API that has been introduced in M2, some existing API has been transformed into client services.
Allows to use the browser's history for navigating within the application. This replaces the IBrowserHistory interface and RWT.getBrowserHistory(). Example:
BrowserHistory history = RWT.getClient().getService( BrowserHistory.class ); history.createEntry( "main", "Main View" );
Used to configure the confirmation dialog that can be shown before the user leaves the application. It is no longer possible to do this in a branding. Example:
ExitConfirmation confirmation = RWT.getClient().getService( ExitConfirmation.class ); confirmation.setMessage( "Where do you think you're going?!" );
The event system in RWT has been completely re-written. For historical reasons, the implementation was based on typed events like SelectionEvent with untyped events built on top. This “inverted” design caused several problems that are now fixed (see bug 334028).
With the new implementation, the design follows the structure of SWT.
Typed and untyped events work exactly like in the original.
This also allowed us to provide some missing API:
All typed events have a
time field that reflects the time an event has occurred.
MouseEvent has a field
count that allows to distinguish single and double clicks.
Custom widgets can now use the protected method
Widget #removeListener( int, SWTEventListener ).
The UICallBack is RAP's mechanism to enable “push” UI updates to the client. The implementation of this mechanism has been simplified and made more robust (see bug 382613). As an effect of this change, the client will now be notified of a session timeout when the UICallBack is enabled (bug 388280).
Moreover, the resource manager does not close input streams anymore after registering a resource, as it did in 1.5 (bug 347615). Please double check that you're closing your input streams correctly.
The ResourceManager API has been reduced to the necessary minimum. If you've used a method that has been removed, the advice above should help you to adapt your code to use one of the remaining methods instead.
The IResource interface is now only used in the extension point org.eclipse.rap.ui.resources and has therefore been moved to the bundle org.eclipse.rap.ui.workbench. The methods getCharset() and getOptions() have been removed because of the changes described above.
For resources that are registered in an ApplicationConfiguration, the method Application.addResource(…) now accepts a ResourceLoader instead of IResource.
Until now, entrypoints could be registered with a name in an entrypoint extension. Those entrypoints had been available at a URL with the default servlet name “rap” and a URL parameter “startup” pointing to this name, such as:
http://hostname/webapp/rap?startup=foo (OBSOLETE)Since RAP 1.5, entrypoints can be registered by path. For example, an entrypoint that is registered with the path
/foowill be available at:
The old approach had a number of drawbacks. It lead to odd URLs, that follow a convention you had to know. A typo in the entrypoint name resulted in an HTTP 500 instead of a 404. Even if you mapped a custom path to the entrypoint in a branding, the “rap?startup=” URL would still work.
Thus we decided to remove the support for entrypoints by name completely in RAP 2.0. From now on, entrypoints can only be registered by path. The default servlet name “rap” and the parameter “startup” are not supported anymore.
In your entrypoint extensions, use the attibute path to specify the URL path for the entrypoint. The old attribute parameter is not supported anymore. Here's an example plugin.xml snippet:
<extension point="org.eclipse.rap.ui.entrypoint"> <entrypoint id="example.entrypoint" class="example.MyEntryPoint" path="/example" /> </entrypoint> </extension>
This change also affects applications that use IApplication as entrypoint. To make an application available at a certain path, add a parameter named path to your extension:
<extension id="example.app" point="org.eclipse.core.runtime.applications"> <application thread="main" cardinality="singleton-global" visible="true"> <run class="example.Application"> <parameter name="path" value="/example" /> </run> </application> </extension>
Since entrypoints are now always registered by path, there is no need for an entrypoint-to-path mapping in a branding anymore. Therefore, we removed the attributes servletName, defaultEntrypointId, and the element associatedEntrypoints from the branding extension point. A branding can now be bound to an entrypoint by setting the new attribute brandingId.
<extension point="org.eclipse.rap.ui.entrypoint"> <entrypoint id="example.entrypoint" class="example.MyEntryPoint" path="/example" brandingId="example.branding" /> </entrypoint> </extension>
To bind a branding to an IApplication, add a parameter brandingId to the application extension point.
<extension id="example.app" point="org.eclipse.core.runtime.applications"> <application thread="main" cardinality="singleton-global" visible="true"> <run class="example.Application"> <parameter name="path" value="/mail" /> <parameter name="brandingId" value="example.branding /"> </run> </application> </extension>
For exit confirmations, the new client service ExitConfirmation should be used as explained above. The attribute exitConfirmationClass is no longer supported by the branding extension point.
With these changes, we also removed the branding API from RWT, namely the classes AbstractBranding and Header. We don't expect that anyone was using these classes. In plain RWT applications, entrypoint properties can be used for branding.
This list shows all bugs that have been fixed for this milestone build.
The above features are just the ones that are new since the last milestone build. Summaries for earlier builds:
To assist you with the migration from RAP 2.x (or 1.x) to 3.0, we provide a migration guide.