This milstone adds quite a few nice features like bézier curves for Canvas, background-position and -repeat for CSS theming, and (especially) improved multi-tab browsing: It is now possible to host multiple UI-Sessions within the same HTTP-Session, meaning that there are no more tricks required to use multiple tabs with RAP applications in the same browser. Lets look at an example how multiple browser tabs can be used within a RAP application by integrating it with the markup and BrowserNavigation features.

Assuming our application lets the user select a person from a database to edit, the typical setup would be a TableViewer that opens a Dialog on a DefaultSelection event. We want to give the user the additional option to open this dialog in a new browser tab. This tab may run the same EntryPoint, or in this case one designed for this specific purpose only.

We create a TableViewer with markup support:

viewer = new TableViewer( parent );
viewer.getTable().setData( RWT.MARKUP_ENABLED, Boolean.TRUE );

Then we insert a link in the last cell of each row, whereby “edit” is the name of another EntryPoint:

viewer.setLabelProvider( new CellLabelProvider() {
  @Override
  public void update( ViewerCell cell ) {
    Person person = ( Person )cell.getElement();
    switch( cell.getColumnIndex() ) {
      case COLUMN_FIRST_NAME:
        cell.setText( person.name );
      break;
      case COLUMN_PLACE_OF_BIRTH:
        cell.setText( person.nation );
      break;
      case COLUMN_LINKS:
        String url = "edit#person/" + persons.indexOf( person );
        cell.setText(  
          "<a href=\"" 
          + url 
          + "\" target=\"_blank\">edit</a>" 
        );
      break;
    }
  }
} );

In the other EntryPoint, we add deep-link support like this:

BrowserNavigation bn 
  = RWT.getClient().getService( BrowserNavigation.class );
bn.addBrowserNavigationListener( new BrowserNavigationListener() {
  @Override
  public void navigated( BrowserNavigationEvent event ) {
    String state = event.getState();
    if( state.startsWith( "person/" ) ) {
      int index = Integer.parseInt( state.substring( 7 ) );
      editPerson( persons.get( index ) );
    }
  }
} );

Done. You could also use the URLLauncher service to open the tab without using a “real” link.

The Vision

My idea was to create a highly modular and especially flexible client that supports only a minimal subset of RAP features, but can very easily be extended and customized. RAP 2.0 introduced a simple JavaScript API for creating custom widgets. This client would go one step further and also allow you to change the presentation of existing widgets to your liking (also using JavaScript). For that you don’t have to implement a new Java API, the client-server communication is already in place, as is the internal logic of the widget (like selection management). Also, the widget will still be single-sourcing capable. Any RAP widgets or features that you might miss in the client you should easily be able to implement yourself after reading the documentation. It would basically be a D.I.Y. RAP Client construction kit, and not a replacement for the full-blown existing WebClient.

Another noticeable feature of this client would also be its ability to adapt to (and take advantage of) different environments. This would also mean that it breaks with RAPs paradigm of looking and working identically on all supported browsers. If you want to take advantage of exciting HTML5/CSS3 features you can but it won’t work/look like the same older browser. You could also create a very different presentation if you are on a touchscreen device, or if you want to optimize for performance on older hardware. You could even create a presentation built entirely on SVG, or for other environments than a browser, as long as they run JavaScript.

By the way, most custom widgets and ClientScripting components written for the default WebClient should also still work with this client.

So I went ahead and built a proof-of-concept/experimental version of this web client for RAP. It currently supports 5 widgets and is appropriately titled “RAP Lite”. The code can be viewed here. You can also download it and run the demo but remember that this is strictly a research project and only barely functional.

What can it currently do?

First of all, here are two screenshots of the Demo application included:

The screenshot on the left is the default WebClient, while the one on the right is RAP Lite. The first 5 buttons all only change the Label at the top.
So far it looks and works mainly in the same way, except that RAP Lite starts up faster.

“Visit the other side” brings a List widget to the front using a nice CSS3 animation in the latest FireFox and Chrome browsers:

Clicking on “Scroll” will animate the scroll position of the List to a random value. In a modern browser the scrollbar is a subwidget (iScroll) that looks the same on any OS. Let’s compare that with IE8:

In IE (on the right), the List now uses the traditional OS-native scrollbar without animation because the iScroll widget is not supported in IE. Also, the gradients are gone because RAP Lite will not go to the same lengths as the default client to render them. Lets modify the demo to tell the client to use another presentation for buttons:

Now RAP Lite uses the native HTML form elements for push buttons, which aren’t as flexible, but look somewhat better than flat rectangles.

Finally, lets have a look at a cool feature that I didn’t mention before at all: The ability to run RAP Lite inside of a traditional, static HTML website:

This is not RAP running in an iframe. Instead, there is a simple script within that static HTML site that assigns the RAP application a div to run in. However, that’s not all. Let’s assume you want to embedd RAP in your website, with some static content between the RAP components. You can do that too. The button at the bottom of the demo opens another Shell which now looks like this:

Notice that the text flows around the new Shell, and even adapts when it changes it size.

How does it work?

RAP Lite can be separated into three layers (+libaries):

The first layer provides the core infrastructure for communicating with a RAP server. The code is taken directly from the existing WebClient and could be used to build any kind of JavaScript-based RAP client on top. (This is not quite the case yet, but almost).

The second layer provides the widget data models and internal logic, and connects the models with the first layer. It does not, however, include any HTML/CSS rendering or DOM event handling. As such it should, like the first layer, be able to run in any JavaScript environment, even non-browser.

The third and final layer does the actual presentation. Each widget model is assigned one or more (alternative) views that can render their content. The views use HTML templates and/or subwidgets (standalone widgets not based on a model) to generate the widget representation. DOM Events are pre-processed by the view, then forwarded to the model. The theming is applied using central CSS rules generated at runtime, and every view can contribute it’s own rules. Most changes in the model are either reflected by adding/removing CSS classes, or by re-rendering all or most of the HTML. While more incremental changes may be more efficient in some cases, this approach keeps the code very simple and the number of DOM operations small.

What does it all mean?

There are currently no concrete plans for a more “official” version of this client. The fact that is’s based on underscore.js sadly means that it can not become part of the RAP project for legal reasons. However, if I’m ever involved in creating another web client for RAP, it will most likely look a lot like this experiment.

If you are writing unit tests for your Java code, then you should also write them for any other code you wrote for the same project. Otherwise these tests only give you a false sense of security. RAP 2.0 provides a new JavaScript API to extend the framework with custom components, as you can read here. Using third party JavaScript libaries (jQuery, D3, etc) or widgets/applications (like GMaps, CKEditor… ) makes the task manageable even if you are not an HTML/CSS/JavaScript expert. But what about tests?

As Java/RCP/RAP developer you may be used to JUnit, and perhaps Mockito (if not: read this). Now, Java/JavaScript differences aside, I like Jasmine even better. I used it to test my JavaScript code when porting the CKEditor add-on for RAP (demo, download) to RAP 2.0. In this article I will use this project to demonstrate one way to use Jasmine with RAP.
You can look at the editors Java implementation here, and at the JavaScript code we want to test here.

Remote API Basics

To fully understand the examples i’ll show here, you should be familiar with the RAP Remote API, but you’ll get the gist of it either way. If you want, you can jump straight to the next chapter.

A brief introduction to Remote API is also given here. Basically, each side (client and server) have one “half” of the custom widget, and a representation of the other side’s “half” as an instance of RemoteObject:

Therefore RAP includes a RemoteObject implementation for Java and one for JavaScript. The main difference is that the server can create new remote objects…

Connection connection = RWT.getUISession().getConnection();
RemoteObject remoteObject 
  = connection.createRemoteObject( "MyWidget" );

… while the client can only get existing ones:

  var remoteObject = rap.getRemoteObject( widgetInstance );

In addition, the Server can also receive remote operations via the remote object, while the client object has to implement methods (especially setter) that can be directly called by the framework.

Typically, a simple custom widgets client-side life cycle looks like this:

• The client component has to register a TypeHandler (once). This is basically the glue between your custom widget and the framework. The type handler consist of a factory for the client object, and a list of properties, methods and events it supports.
• The server side creates an RemoteObject instance. With this, a “create” operation is send to the client and invokes the type handler’s factory.
• Using the id of a Composite (which the server typically provides in a “set” operation), the custom widget can obtain the client side instance and attach itself to it: rap.getObject( parentId ).append( htmlElement );
• All invocations of “set” or “call” on the server side RemoteObject will cause the matching methods of the client widget to be called. To send messags back, the client widget can itself obtain a RemoteObject to send operations to the server.
• When the server remote object is destroyed, so is the client object.

Jasmine at a glance

The Jasmine project site already gives a good tutorial, so I’ll try to keep this short. Jasmine allows for Behavior-Driven Development (BDD), which is similar to Test-Driven Development (TDD). It basically means that your tests will read like a “story” written in plain English. (Or any other language, if you’re crazy.)

For example, a traditional test in JUnit…

public class Math_Test extends TestCase
  public void test_RoundsUp2Point5() {
    assertEquals( 3, Math.round( 2.5 ) );
  }
};

… may look like this in Jasmine:

describe("Math", function() {
  it("should round 2.5 to 3", function() {
    expect( Math.round( 2.5 ).toBe( 3 );
  });
});

As you can see it’s not that different at first, except it’s easier to describe what exactly you are testing. The “describe” function seems similar to a test class (it is called a “Suite”), “it” to a test method (actually a “Spec”), and “expect” looks a bit like Mockitos “verify”. The “setUp” and “tearDown” methods in JUnit would be “beforeEach” and “afterEach” functions in Jasmine.

However, the advantage is that unlike JUnit tests, “describe” functions can be nested. And what I personally love about that, is that each can have it’s very own beforeEach/afterEach functions, and they are executed for all the “describe” functions the “it” is in. That made my tests a lot more readable. In JUnit I would often have a lot of similar setup code at the beginning for each test, and multiple asserts the end. Sure, there ways to reduce it, but I think it’s a pain. My Jasmine Specs on the other hand are usually around three lines only.

What to test?

There may be several parts to your JavaScript component. The RAP type handler has little to no logic of it’s own, and would require a “real” RAP client to be tested. Therefore we omit it, and only test the widget “class” itself.

If your custom widget is basically a wrapper for an existing JavaScript app (like CKEditor), then you might want to test only the wrapper. If so, you can also replace the app with your own mock, though you have to know the app’s API really well for that to work. In my case, I first did a untested prototype to figure out how to get the CKEditor to cooperate with RAP. Then I started again from scratch, writing tests first using a CKEditor mock I created myself.

If you are writing the entire widget yourself, you should of course test all of it, not just the part that connects to RAP.

Setting Up Jasmine with a RAP enviroment

Download the Jasmine Standalone Release and unzip it to a folder in your test project. You don’t need the included examples, so delete the src and specs folder. Open the SpecRunner.html in an editor. We are interested in the <script> tags only. Remove those that point to the deleted files. Then get the “rap-mock.js from our GitHub repository and include it with a new script tag. This is key, as the file contains a mock implementation of the RAP JavaScript API, so that your custom component can be tested outside an actual RAP application.

Below the rap-mock.js, add the JavaScript file(s) from your own RAP JavaScript component. If they are in another bundle, it may have to look like this:

<script 
  type="text/javascript" 
  src="../../com.eclipsesource.widgets.ckeditor/src/resources/handler.js">
</script>

Finally, create a new JavaScript file like “CKEditorSpec.js” and also include it in the HTML file. This is where we will put the tests.

The rap mock is initialized automatically by including the file itself, but to be sure that everything is reset with each test, your outmost “beforeEach” should look like this:

 beforeEach( function() {
  rap = new RapMock();
} );

In addition to the official API of the “rap” object, this one has two fields “fakeRemoteObject” and “fakeComposite”. Like “rap” itself, they are only empty implementations of the RemoteObject and Composite types, which are returned if rap.getRemoteObject() or rap.getObject() (respectively) are called. That makes it a lot easier to test interactions with these objects later on. (Note that it always returns the same instances, but since they dont have any state it shouldn’t matter.)

My First Spec

Since variables have function scope in JavaScript, and all Suites and Specs are functions, you can freely define variables within any suite and share them with the contained Specs. I would suggest to do so for your outmost Suite for the instance of your custom widget. For me, it looks like this:

describe( "eclipsesource.CKEditor", function() {
 
  var editor;
 
  var createEditor = function() {
    editor = new eclipsesource.CKEditor( { "parent" : "w2" } );
  };
 
  beforeEach( function() {
    rap = new RapMock();
    editor = null;
  } );
 
  afterEach( function() {
    editor = null;
  } );
 
  ...
 
} );

I’m not creating an instance in the outer Suite because we will sometimes need to do some setup before calling the constructor. This is where spies come into play. Remember, our rap mock (and in this case CKEditor mock) does absolutely nothing itself (except preventing crashes). To write meaningful tests, we need to spy on it.

Spies replace methods with stubs, which can later be checked for invocations Mockito-style. They can also return any value, capture arguments, or execute arbitrary code. Read more about them here. Spies are automatically removed after each it.

Now we dive right into it, and test that the widget adds itself (specifically it’s element) to the parent:

  describe( "The Constructor", function() {
 
    it( "should get a Composite with the parent id", function() {
      spyOn( rap, "getObject" ).andCallThrough();
      createEditor();
      expect( rap.getObject ).toHaveBeenCalledWith( "w2" );
    } );
 
    it( "should add an element to the composite", function() {
      spyOn( rap.fakeComposite, "append" );
      createEditor();
      expect( rap.fakeComposite.append )
       .toHaveBeenCalledWith( editor.element );
    } );
 
  } );

It is a common pattern to prefix “private” fields of JavaScript objects with a “_”. For the CKEditor wrapper I completely abstained from creating private fields and made everything “public”, including the HTML element. If I hadn’t, I would either have to access a private field, or examine the contents of the element that was given to the fake composite. Since i’m not interested in testing the CKEditor itself, I chose this simpler solution.

Most other aspects of the constructor and the editor/wrapper are tested in similar ways, as you can read in the full Spec file. However, there are a few more special cases I like to discuss in detail.

Testing events

The CKEditor wrapper registers events listener on the CKEditor itself and on the “rap” object, e.g. to check for changes before a request is send to the server. There are various ways to test them. The “cleanest” one would likely be to obtain the listener with a spy and execute it:

describe( "The send listener", function() {
 
  var onSendListener;
 
  beforeEach( function() {
    spyOn( rap, "on" ).andCallFake( function( event, listener ) {
      if( event === "send" ) {
        onSendListener = listener;
      }
    } );
    createEditor();
  } );
 
  describe( "of an editor that has not changed", function() {
 
    it( "sends nothing", function() {
      spyOn( rap.fakeRemoteObject, "set" );
      onSendListener();
      expect( rap.fakeRemoteObject.set ).not.toHaveBeenCalled();
    } );
 
  } );

With the “beforeEach” function this does not bloat your code all that much, but it’s still a couple of lines. So instead I simply made the listener “public” (like with the HTML element) and called it after checking it was registered. This is part of the “contructor” Suite show above:

it( "should add a send listener", function() {
  spyOn( rap, "on" );
  createEditor();
  expect( rap.on ).toHaveBeenCalledWith( "send", editor.onSend );
} );

Now I can simply invoke editor.onSend whenever I want, since I now it has been registered with the RAP client, which I trust to work correctly. But, there is one important bit: You should not simply write editor.onSend(), because this would mean that editor will be the context (this) of the invokation. This is not automatically given when working with JavaScript callbacks, and I know it is not the case with rap.on. (To see how I solved that issue for the CKEditor, look at the bindAll function in the source code.) Instead, you can write editor.onSend.call();, which executes it without context.

The Clock makes “tick”

A common issue with JavaScript testing are asynchronously executed function. This custom widget has one of those for setting the editors font, which happens with a small delay using the JavaScript setTimeout function. This means I can not simply call editor.setFont and check the results right away. Jasmine includes two different solutions for this issue. If you want or need your test to emulate the actual runtime scenario, you need to wrap the code of your Spec in runs and waitsFor functions.

Since I use only a mock CKEditor I had no such requirement, and used the alternative: Simply mocking the JavaScript timer.

describe( "The setFont function", function() {
 
   var body;
 
   beforeEach( function() {
    jasmine.Clock.useMock();
    createEditor();
    body = editor.editor.document.getBody();
    spyOn( body, "setStyle" );
    editor.setFont( "13px Arial" );
  } );
 
  it( "calls body.setStyle on a ready event", function() {
    editor.onReady.call();
    jasmine.Clock.tick( 0 );
    expect( body.setStyle ).toHaveBeenCalledWith( "font", "13px Arial" );
  } );
 
} );

Feedback…

…would be welcome, especially if you have trouble writing tests for RAP custom widgets. I did not touch on some topics like sending events to the server (which the CKEditor doesn’t do), or how to test DOM changes, but that would have completely burst the scope of this article. (I sometimes have issus keeping things short…) Also, on testing the server side: RAP includes a Fixture (not official API) which allows testing the Remote API, but we might change it soon, so I didn’t want to write about it now. If you are curious, look at CKEditor_Test.java.

Final Words

Jasmine is awesome. Go use it for something.

What are Mnemonics?

Should you not know, Mnemonics are the characters that get underlined in some widgets (especially the menu bar) if you hold down the ALT key. Mac users may scratch their heads right now, because those aren’t supported in OS X. Their exact behavior differs a bit between the other platforms, but as long as you hold ALT and press of the underlined character on your keyboard, the widget gets selected. What I like about that is that, unlike normal shortcuts, you do not need to remember Mnemonics, and they can change all the time depending on what’s on screen.

Mnemonics in RAP 2.1M1

As of M2 (or the current nightly build), RAP will support Mnemonics on Menus, Buttons, ToolItems, TabItems, Labels and Groups. (Also CTabItem and CLabel.) To enable them, you first need to set the modifier that makes the Mnemonics visible. While you could use ALT, it’s strongly discouraged, because that would activate the actual Mnemonics of your browser with unpredictable results. I recommend using CTRL+ALT, and reserve CTRL and CTRL+SHIFT for global shortcuts/Key Bindings. The combo can be set with just one line:

display.setData( RWT.MNEMONIC_ACTIVATOR, "CTRL+ALT" );

Now all you need to do is to put a “&” before a character in a widgets text, and you already have a working Mnemonic. Example:

tabItem.setText( "Tab Item &1" );

Since this is a relatively complex new feature, I would love for developers to grab RAP 2.1M1 when it’s available next week and try it in their application so that we can get some feedback.

Coming soon: Full Accelerator support.

When you look at our New and Noteworthy log for RAP 2.0 RC1, you’ll notice that we are going to live up our new name: The brand new RAP “Remote” API on Server and Client makes custom widget development much simpler than it ever was. This is also the first time we publish official JavaScript API, making JavaScript components much more future-poof.

This build also introduces simplified EntryPoints, which can safe you a nice bit of typing when starting new RWT applications or snippets:

public class HelloEntryPoint extends AbstractEntryPoint {
 
  @Override
  protected void createContents( Composite parent ) {
    Button button = new Button( parent, SWT.PUSH );
    button.setText( "Hello World!" );
  }
}

We encourage everyone to download and install RC1, and report any issues you may find to the RAP Newsgroup or Bugzilla. RAP 2.0 will be released on February 11.

The client service API accounts for that. In RAP 2.0, the client is represented by a class implementing the Client interface (WebClient by default). An instance of this class can be obtained from RWT.getClient(), which selects an implementation that matches the currently connected client. This implementation then provides the client services via the getService method. For example:

MyService service = RWT.getClient().getService( MyService.class );

If the client connected to the current session supports the service, an instance is returned, otherwise null. (Also, within one session it will always return the same instance for the same service.) If you can be certain that the service is supported by all clients you are targeting, you can use it immediately, otherwise you should check for null first.

Right now, all services that are part of RAP are supported by the WebClient at all times. Some of them provide features that already existed in RAP 1.x in some form, some of them are completely new. There will certainly be even more in the future, especially ones that are based on HTML5-only features. As such, their availability at runtime may depend on the currently connected browser.

For now there is:

• ClientInfo: Provides you with the clients timezone offset and locale setting.
• BrowserNavigation: Allows you to support the browser’s back/forward button and deep linking.
• ExitConfirmation: Lets you set a message that is displayed if the users tries to close the window or navigate to another website.
• UrlLauncher: Open any given URL without leaving the application or influencing the client. May be used to open other websites, view files, start mailing or calling a specific person. May also support opening save dialogs in the future.
• JavaScriptLoader: This new feature allows the server to add JavaScript to an already running client. The service also keeps track of which files have already been loaded. This makes it easy to develop custom widgets/components that are loaded as they are needed, keeping the initial loading time for the user as short as possible. (Fittingly, we also introduce a new custom component API in 2.0).
• JavaScriptExecuter: This service allows you access the client directly. If there is a simple, client-related task that RAP does not provide any Java API for (yet), this may be a way around that. Of course one should be very careful with this feature. Using it incorrectly may disrupt or even crash the entire client. Just make sure your script can not throw any exceptions and does not mess with any clients internals.

Update: You can try all services in the updated Controls Demo.

I did all my testing with the upcoming RAP 2.0M3 on a 64Bit Intel version of Windows 8. I currently have no WinRT tablet available for testing.

IE 10, Desktop mode

RAP basically runs like it would on IE9. That means that it takes advantage of modern features like HTML5, but not to the same degree as on Firefox and Chrome/Safari. One shortcoming of IE9 was its limited support of CSS3, which is why RAP used some SVG in the UI to compensate for that. Since IE10 is currently running as IE9, this is still the case.

After 5 minutes of hacking I got RAP to only use CSS3 in IE10. While it generally works, there seems to be an issue with gradients having an incorrect orientation. If it turns out to be an easy fix, we might be able to render the UI with CSS3 only in RAP 2.x/IE10.

IE 10, App mode

For IE to run in app mode, it has to be set as the default browser. It took me a while to figure that out. It’s like IE is offended that I dared to install another browser.

The UI seems to work like in desktop mode, but we are here to look at the controls. Using the mouse already causes some issue: Usually a right-click is used to bring up the URL-bar, which is hidden by default. However, that does not work while running a RAP application. It should not be hard to fix, assuming there is a way to detect IEs app-mode with JavaScript. Using fingers (swipe from bottom) or keyboard (CTRL+L) works fine though.

Running fullscreen, the RAP theming fits quite well with the metro design.

Using fingers to press buttons and menus, or select items also works flawlessly, as does editing text. Double-tapping zooms into the application, a feature which we usually suppress on iOS and Android to allow quick selections and double-clicks. Touch-scrolling does not work at all except on multi-line textfields. Dragging any other items (like scrollbar thumbs) is also not possible.

RAP already supports all of this on iOS and Android (within limitations), but that code was written specifically for webkit browser and does not seem to work on IE10. We will likely have to put some effort into getting IE10 to the same level. Amusingly, the IE10-gesture of swiping left/right to navigate back/forward works very well with the more advanced BrowserHistory feature of RAP, as can be tested with the Examples Demo.

Google Chrome 23

Even though RAP does not detect Chrome on Windows as a touch-enabled browser, touch-controls work pretty good. Even scrolling trees and tables works, which was a huge issue on Android and iOS. Double-tapping does not zoom, but correctly fires a double-click event.
Fixing the touch-detecting in RAP improves the touch-scrolling a bit, but changes nothing else.

Firefox 17 beta

Firefox is also not detected as a touch-device. Emulating simple clicks works fine, but that’s about it. Clicking in textfields does not bring up the keyboard. Touch-scrolling works, but is very much broken. However, since this version of Firefox is not yet a “real” Windows 8 app, let’s hope for an improved version soon.

Conclusion

Overall RAP is usable with touchscreens on Windows 8, though not quite yet at the same level as in iOS. However, support is noticeably better than it initially was with the first iOS/Android devices, so it should be not quite as hard for RAP to get there.

Here are some simple ways to automate how you deal with whitespaces in Eclipse.

First, if you don’t want to have trailing spaces in your java code (why would you), you can remove them automatically:

If you use JSDT, there also is an option available to turn this feature on for javascript.

Second, if you want to be sure not to miss any unwanted whitespaces, you can configure Eclipse to show them as characters. Since doing this for all whitespaces can make the code harder to read, you can choose to show only those you don’t want to have in your code:

This setting affects all text files, including java, javascript and HTML. Sadly, there is no option yet that shows only two or more enclosed spaces.

In my opinion, even with a complex piece of software like RAP, a good documentation should make it easy for any seasoned Java developer to pick it up and quickly use it to its fullest. I think we are a lot closer to this now. And best of all, the guide can finally be viewed on the RAP homepage.

Here are some of the major additions:

• New chapters “Setting up the Eclipse IDE” and “Installing a RAP Target“, explaining in more detail and simple terms the different ways to to setup the IDE and target platform.
• There is a new section “RAP Widget Toolkit”. It explains what RWT is, what it can do more than SWT and what its limitations are. There are also detailed discussions on key and mouse events, and on the different scopes used in RAP.
• Certainly among the most important additions: The article “Choosing an Application Setup” explains the different modes and environments RAP can run in. “Application Configuration” and “RWT Standalone” (and the retained “Branding”) then build on that and go into more detail.

Most of the other articles have also been slightly revised.

These changes are part of an ongoing effort to improve the environment and overall presentation of the RAP project. You might have noticed that the RAP homepage has been improved several times in the last months, (adding some content to the landing page just a few days ago), and the Wiki was also cleaned up a bit. Finally, we plan to blog and twitter more to keep everyone up to date and interested.

As you can test for yourself, the difference between server-side and client-side validation is quite noticeable.

When using ClientScripting, you will need to know very little JavaScript, and all API is as close to SWT as possible. The project has a wiki page with all further information you might need (including where to get the code). Note that you need RAP 1.5M6 or newer to use it. If you try it out, please consider giving some feedback, report bugs or file enhancement requests.