Here are some of the more noteworthy things available in RAP 1.1 (June 25, 2008) which is now available for download.
This list shows all bugs that were fixed.
CVS Reorganization |
Since the number of RAP projects has increased in the past,
we decided to reorganize the structure of our source code repository
to make it more concise.
Thus we started to introduce different subfolders.
Besides the
The CVS reorganization is an ongoing effort and is scheduled to be finished shortly after the RAP 1.1 release. If you want to stay tuned, you can set yourself CC to bug #201257. The team project sets provided here are in sync with the current CVS structure. |
Support for Custom Widget Id's |
In RWT, each widget has an automatically generated, unique widget
id that associates the server-side object with its client-side
representation.
In order to use automated UI tests, now the generated id can be overridden programmatically. With code like this: Button button = new ... button.setData( WidgetUtil.CUSTOM_WIDGET_ID, "org.sample.LoginDialog#okButton" );and the system property org.eclipse.rwt.enableUITests turned
on, the button can always be identified by its custom id. The test
scenario can remain unchanged even if the UI changes.
See this bug and the JavaDoc for WidgetUtil#CUSTOM_WIDGET_ID and
WidgetUtil#ENABLE_UI_TESTS for further information.
| |
  |   | |
Browser#execute() |
The org.eclipse.swt.browser.Browser#execute(String) method
was implemented. This method allows to execute a script containing
JavaScript commands.
Please read the JavaDoc for further details. | |
  |   | |
Display#readAndDispatch() |
To more closely align with SWT and solve the problems with the
existing mechanism for blocking UI operations, RWT new provides
Display#readAndDispatch() and Display#sleep() .
The new implementation now strictly follows the apartment threading model. This means that the life cycle is handled by a single thread, spanning the lifetime of a session. As a result, all phase listeners and application code are executed on this thread. Note, that the readAndDispatch() loop runs in the process action phase, however this is generally transparent to the application developer. Please be aware that this comes at the cost of a small API break.
The
If you are using RWT directly, you also need to code the typical event loop in your entry point:
| |
  |   | |
Table keyboard navigation |
The table widget now supports keyboard navigation. Using the
Up , Down , Home ,
End , PageUp and PageDown
keys works as expected.
| |
  |   | |
UI Styling API |
Support for background images
The methods Control#get/setBackgroundImage() allow to
set background images on almost all controls.
Support for transparency
Semi-transparent Shells
| |
  |   | |
Theming Variants |
It is now possible to define variants of widget types that can be
styled separately. As an example, an application that uses PUSH
buttons in a special side bar can define a variant "side-button" and
apply a different styling to these buttons. This styling only
applies to the buttons belonging to the variant and does not
affect any other PUSH buttons in the application.
The variant is set using the widget user data
( | |
  |   | |
ISettingStore |
There is a new subsystem in RWT that allows to persist user-specific
settings:
It is also possible to load specific settings independently from cookies:
Note that the setting store subsystem is used by the new ScopedPreferenceStore implementation of the workbench.
See API documentation for more information. | |
  |   | |
Mouse Events |
RWT now has support for MouseEvent s. Calling
addMouseListener on a Control will notify you about
mouseUp , mouseDown and
mouseDoubleClick events.
Please be aware that, despite the complete API, there are still some limitations that will be addressed in the future. | |
  |   | |
RWT Split-up |
RWT has been split into a host bundle and qooxdoo 0.7 fragment.
This was done to enable us to start working on the upcoming
qooxdoo 0.8 version.
This split-up will also allow interested parties to develop other
client-side implementations for RAP in the future.
Developers who work against CVS have to check out the fragment
org.eclipse.rap.rwt.q07 and include it in their launch
configurations.
Note: Customize your build process so that
the | |
  |   | |
Theming |
Support for theme files in CSS format
RAP supports theme files in CSS syntax now. CSS theme files for RAP must be valid CSS 2.1 files, except for a couple of RAP specific properties and pseudo classes. The following is an example for a simple CSS theme file: * { backgound-color: white; } Button[PUSH], Button[TOGGLE] { border: 2px solid blue; color: rgb( 17, 23, 103 ); background-color: #f9f9f9; } Button[PUSH]:hover, Button[TOGGLE]:hover { background-color: white; } The support for the new syntax is just the first step towards a more flexible theming. Internally, the theming engine is still based on the old properties. As an effect, only a subset of the flexibility provided by CSS is already supported. For more information on the topic, have a look at the RAP Help. Developers are encouraged to write CSS theme files now. The old property-based theme files are still supported but considered deprecated. |
Image Decorator Support |
JFace now contains class The workbench now provides the extension point
| |
  |   | |
Support for activities |
The RAP Workbench now supports the org.eclipse.ui.activities
and org.eclipse.ui.activitySupport extension points. You
can control the visibility of views, editors, perspectives, menu and
toolbar items using activities and trigger points. See the extension
point documentation for details.
| |
  |   | |
RAP HttpContext | The RAP servlet now uses its own HttpContext implementation. This allows other servlets to map to that context too. This enables the possibility to share the same session instances between those servlets and the RAP servlet for data exchange. | |
  |   | |
ScopedPreferenceStore |
The RAP workbench provides now
org.eclipse.ui.preferences.ScopedPreferenceStore that
allows to read and set user-specific preferences using the
preference mechanism provided by org.eclipse.core.runtime .
The base of the storage mechanism is a subsystem of RWT represented
by org.eclipse.rwt.service.ISettingStore .
The session aware
org.eclipse.jface.preference.IPreferenceStore can be
retrieved using the method
org.eclipse.ui.plugin.AbstractUIPlugin.getPreferenceStore .
See API documentation for more information. | |
  |   | |
Import-/Export Wizards |
RAP supports now Import- and Exportwizards by providing
the extension points importWizards and
exportWizards . See also ActionFactory.IMPORT
and ActionFactory.EXPORT for opening the import-/export
wizard.
| |
  |   | |
Eclipse 3.4 Adoption |
The RAP counterparts of JFace, Workbench, Forms and Databinding
have been migrated to the 3.4 code base.
During this effort, we tried to achieve feature completeness as far as possible to get a clear picture of what is needed to enable single sourcing of the RAP and RCP Workbench in the future. Here are some of the more noteworthy things that are now available:
|
RAP JUnit |
RAP provides an equivalent to the "PDE JUnit Tests" to allow to run
tests that require an OSGi environment up and running.
The snippet below shows how a RAP JUnit test case looks like.
To compile such a test, the containing plug-in needs a dependency on
In order to run a test, choose Run As > RAP JUnit Test from the editors' context menu. public class RapJUnitTest extends RAPTestCase { public void testOpenView() { try { IWorkbenchPage page = getPage(); page.showView( "org.eclipse.rap.demo.DemoTreeViewPartI" ); } catch( PartInitException e ) { e.printStackTrace(); } assertEquals( 1, getPage().getViewReferences().length ); getPage().hideView( getPage().getViewReferences()[ 0 ] ); assertEquals( 0, getPage().getViewReferences().length ); } private IWorkbenchPage getPage() { IWorkbench workbench = PlatformUI.getWorkbench(); IWorkbenchWindow window = workbench.getActiveWorkbenchWindow(); return window.getActivePage(); } } RAP JUnit supports only the 3.x Test Runner at the moment. |