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.

I originally implemented this as an example of how JavaScript applications can be embedded in RAP as custom widgets. So if you have a similar scenario, you could also use this project as a template. The editor is fairly customizable, read the README for details. You can get the code on GitHub.

• Some keys that didn’t work at all (like arrow-keys in Firefox), work fine now. This also fixes the JFace Content Proposal.

• Several non-alphanumeric keys had the wrong keycode,  those are fixed.

• Key events are no longer blocking the UI when sending the Ajax request to the server.

• There is now a feature called “active keys”, which makes it possible to drastically reduce traffic traffic.  It was already present in RAP 1.4, but has been greatly improved.

• Another new feature is called “cancel keys”. It allows to suppress the browsers and widgets default operations associated with any given key.

• The “cancel keys” replace the now-defunct support for the doit flag on key events.

The Active Keys

One practical problem with key events was the high amount of network traffic they can generate, one request per pressed key. Especially when you add a listener to widgets like Text, there may be hundreds of requests per user per minute – even if only a few of them are relevant to your applications logic. To counter that, “active keys” allows you to limit the number of requests to the server to only those that are actually necessary. You simply attach a list of key combinations to the widget that has the key listener, and subsequently RAP will only fire key events on this widget that match any of the given combinations.

Example:

widget.setData( RWT.ACTIVE_KEYS, new String[]{ "ALT+SHIFT+X", "F1", "/" );
widget.addKeyListener( new KeyListener(){ ... } );


The widgets and browsers behavior is not changed by this at all. Also, even if you would handle all active keys the same way in the listener, it would be good practice to still explicitly check the pressed key and modifiers on the event itself – especially if you are working on a multi-platform project. Then this approach is also Single Sourcing friendly.

Though the example limits the active key to the given widget, this feature can also be used to implement global key bindings. Just add the list to the display instead to a widget. RAP will send key events for these keys, no matter what widget is focused. (This aspect of  “active keys” already worked in RAP 1.4). Typically you want to use this feature together with a display filter, so you can also process them globally.

Example:

display.setData( RWT.ACTIVE_KEYS, new String[]{ "CTRL+X","CTRL+Y","CTRL+Z" );
display.addFilter( SWT.KeyDown, new Listener(){ ... } );

The Cancel Keys

One issue specific to keyboard shortcuts in web applications  is that you are basically sharing your pool of possible key combos with the browser itself. For example, “CTRL+F” will bring up search dialog in almost every browser, so you can’t just use it to do the same in your application – you would have both dialogs pop up at the same time. Up until now RAP supported the doit flag on key events, which made it possible to suppress not only widget-specific behavior (like in SWT), but also some browser-native shortcuts. However, depending on the browser this was working only for some keys and shortcuts.

As time went on the doit support became an obstacle to us RAP developers. It was originally implemented to better support JFace cell editors. This worked well, but outside that use case it had – as mentioned – some limitations. It also prevented us to fix a number of bugs for key event handling, so for the first time in RAP history, we decided to remove a feature. It was not an easy decision to make, and we only did it after we had a solid replacement.

This replacement is called “cancel keys”. It works pretty much like “active keys”, and can also be combined with that. Like before you attach a list of keys or key-combinations to the widget, and those will all be “prevented”. That means that while the widget is focused, whatever the pressed keys default action is will not happen. This is true for all RAP widget behavior, as well as for most browser features. (Some browser features can not be prevented, like CTRL+TAB for switching tabs, or ALT to focus the menu bar.)

Example:

widget.setData( RWT.CANCEL_KEYS, new String[]{ "CTRL+F", "CTRL+T" );

You can also change the set of cancel keys at any time. All keys not on the list will still work, even if they are part of a listed combination. If the widget from the example is a Text, pressing only “F” or “T” will still insert that character into the field. Again, this feature also works globally when setting the list on Display. You should keep in mind though that the user might be accustomed for certain shortcuts to trigger the default action, like CTRL+T to open a new browser tab, and might not appreciate it when its completely “overwritten” in your application. If you want your code to also work in SWT, you still need to set the doit flag to false.

Showcase

You can see those features in action in our updated demo on the “TableViewer” page. For example, pressing “CTRL+F” will switch to the filter textfield, and from there “Escape”, “Enter” or the down-arrow key will focus the Table again. You’ll notice that your browsers search field will not pop up if you press “CTRL+F”, as long as the table is focused. If you use Firebug or any other debugging tool, you can also see that no requests are sent if any other keys are pressed.

For the applications user to actually use the keyboard controls, he first has to know they exist. So as a UI designer/developer, you might want to place some hints. In the case of our demo I simply placed a short help-text below the Table in a small, grayish font, so it doesn’t distract form the rest of the UI. If there are too many shortcuts to list them all, the Link widget could be used in a similar manner, directing the user to a more comprehensive help dialog.

I measured the time needed to create 200 Buttons in RAP 1.4 and RAP 1.5M3, and it shows a considerable performance boost (at least for the browsers i tested). One reason for this is that we changed from quirksmode to standard rendering in IE9, which among other things, finally allowes us to use its new HTML5-features (in this case SVG and CSS3). I expect another little boost with IE10, which has even more CSS3 support.

However, what i did not expect was a significant improvement in any other browser, in this case Google Chrome. This is likely due to the implementation of the JSON-based RAP-protocol. It remains to be seen how this develops, as work on the protocol is still going on. Currently eval() is used to parse the JSON. In the final release we will probably use other methods, such as the native JSON-parser present in many modern browser. Older browser may gain only little or no performance.

What is really awesome though is the improvment of the GC/SWT-Canvas performance in IE9 (and only IE9). Drawing in browser (without any plug-ins) used to be a real pain. While other browser adopted the HTML5-Canvas and SVG standard very early on, Microsoft stubbornly stuck to its horribly old VML implementation, making my work needlessly hard. One of the main problems with VML is that it gets exponentially slower the more elements you draw, from about 200 elements on it’s almost painful to watch. But this is 2011, HTML5 is all the buzz, and even MS could no longer ignore it. IE9 now has a decent HTML5-Canvas implementation that we use in RAP 1.5, and it shows:

The fine print:
These results were achieved on my Windows 7/64bit Intel i5 2,4 GHZ laptop. No other systems or browser were tested. Measurement was done using JavaScript. The 32bit version of IE9 was used. I did only 3 iterations each, but the deviance was relatively small. The results in the final RAP 1.5 release my be very different due to ongoing development. You can check out the code i used here.

Unlike other frameworks, RAP does not rely on pre-rendered images to create those effects. Instead it does all the rendering itself based on CSS declarations, using multiple browser-native technologies for drawing. Up until now this always involved several complex vector-graphic operations. However, this is 2011, and support for mordern web standards is becoming widely available. By using the CSS3 capabilities of modern browsers, we no longer need to use any vector graphics in Safari, Google Chrome and Firefox 4+. Internet Explorer 9 will follow soon.

Of course, RAP will continue to support all its theming features (including shadows) in browsers without CSS3 capabilities. Shadows and CSS3-support will be part of RAP 1.4 M7, coming on May 7.

[ Download ] (You also need RAP 1.4M4.)

Creating custom-widgets for RAP is no easy task. You need to be familiar not only with Java and JavaScript, but with a lot of RAP’s complex internals as well. It’s a lot of work, even if you simply want to integrate an existing javascript-application or library.

That’s now a lot easier, using the much improved browser-widget. We recently added some missing features, tested different scenarios and fixed known bugs. This makes it an ideal platform to insert javascript-based applications with almost no overhead for the programmer. You simply call JavaScript from Java and vice versa! And the bonus: these custom-widgets can (under certain conditions) also run in RCP, as demonstrated here.

The widget is currently hosted at github, so feel free to check it out, use it in your application or fork it to add your improvements. Also check out Holger Staudachers carousel widget for RAP to see another example.

“Traditional” custom widgets for RAP are by no means obsolete with this, as they still have certain advantages (slightly better performance, themeability, can use rap client components). But for the cases mentioned above, the browser widget can make your life much easier!

Happy Holidays!

Therefore we now integrated the core functionality needed for such animations into RAP. Since the existing client-implementation of RAP was not written with such a feature in mind, it was considerable effort to do this without changing much of the existing code. And for the same reason, there are currently some limitations on what we can do with this feature. However the groundwork is done, and we hope to expand on that in the future.

Just like with gradients and rounded borders before, you can expect the number of supported widgets and effects to grow. You should keep in mind though, that this feature is meant only for subtle animations that seamlessly integrate into the UI. We can and will not turn RAP into some kind of multimedia powerhouse where everything is moving all the time.

For now, “Button”, “Menu”, “ToolTip” and “Shell-DisplayOverlay” each have one effect that can be enabled. This is done using RAPs CSS-theming, not Java, as this kind of animations are mainly eye-candy and don’t add any functionality. The syntax for this is based on a small and easy-to-use subset of the CSS3 working draft for animations. For example:

Button[PUSH] {
  animation: hoverIn 350ms ease, hoverOut 600ms ease-in;
}

This generates a faded hover-effect for buttons.

Animations work on all browser supported by RAP, but might not run smoothly on very old machines. They will be part of the upcoming 1.3M7 build. To see what we can do for now, check out the new “Theming”-Page in our examples-demo.