Ralf is a software engineer with a history as Eclipse committer and project lead.
In recent years, he devoted himself to JavaScript technologies and helped pulling off the Tabris.js project.
Ralf holds a Master’s degree from the University of Tübingen.
Today, we’re proud and happy to announce the release of Tabris.js 2.0. This release makes Tabris.js even simpler to use, yet more flexible and powerful than ever, all while adding support for a completely new mobile platform.
The Tabris.js 2.0 release is now less than a week away (July 18). During the last preparations, we’re counting down the 10 new features in 2.0 that we’re most exited about. Number 3 is a brand new file system API.
Tabris.js 2.0 is just two weeks away, and the development team is taking this ramp down time to reflect on the release and highlight the features we’re really excited about. A new major release gave us the opporuntity to update the API. We have been designing APIs for Widget Toolkits for over 10 years, and in that time we’ve learned a lot. In Tabris 2.0, we’ve modernized our API to fit better with the modern language features available in JavaScript and TypeScript. Here are some of the most notable changes.
There have been many notable changes to the Tabris.js codebase since Beta 2, and today we are happy to present the first release candidate of Tabris.js 2. In the last six weeks, we’ve been focused on finalizing the API for Tabris.js 2.0. But we also deliver some nifty new features, a performance improvement, and a useful addition to the developer console.
The latest version of JavaScript (ES2015, or commonly called ES6) is packed with modern features, including classes, lambda expressions (“arrow functions”), block scoping, template strings, and much more. Using a transpiler like Babel, you can use these features in your Tabris.js app today.
Some time ago we’ve created a draft for a Chart widget for RAP, based on the famous D3.js. Together with one of our partners, we decided to carry this work forward and make it available in the RAP Incubator.
When you need rich text editing in a RAP application, things are getting easier. You may know that there is a RichText component in the RAP Incubator. It’s around for a long time and we found it’s time for this component to graduate.
Some languages, such as Arabic and Hebrew, are written from right to left. The different reading direction not only affects texts, but most UI elements. Preparing software for use in those languages obviously requires a lot more work than just translating texts. We’re currently adding right-to-left (a.k.a. “RTL”) support in RAP.
The dynamic typing in JavaScript allows for more flexibility, but it comes at the price of weaker tool support. Explicit type definitions in your code can support editors to provide more exact suggestions as you type …
Imagine you’ve just published a new version of your app when you discover a critical bug that will render the app unusable for half of your user base. The fix may be simple, but rolling out another version takes some time for app store review and users to install the update. With Tabris.js, you can now deploy hotfixes to your users immediately, without having to wait for an update.
This week, the third major version of RAP, the Eclipse Remote Application Platform, has been released. As a major release, RAP 3.0 cleaned up deprecated API, allowing us to change and to optimize internals. I’m happy to report that we achieved a significant performance boost compared to 2.3. Before I go into details, let’s look at some results.
Today, the RAP project delivers the final milestone build on the way to RAP 3.0. With this new major release, we clean up deprecated API, include some new components, optimize performance and modernize the framework to make it ready for 2015.
When you test components of a RAP application, you have to simulate the environment that RAP UI code normally runs in. Thanks to a new API, this becomes easier in RAP 3.0.
Warning! This article is outdated and might not represent the current state of Tabris.js.
Often when I use SWT templates in a presentation, some people look amazed, so I thought it’s worth sharing. If you write SWT code and don’t know these templates yet, you may be wasting time typing the same code over and over again.
When you build jars that are supposed to work with a specific JRE version, it’s not sufficient to set the correct compiler level. Even if the compiler creates byte code for a particular language version, your code may accidentally use API that is not available in the class library of this Java version, and the compiler will not notice this.
If you still find yourself defining methods like this
public String[] getParameters();
in an interface, you should think again. Arrays are not just old-fashioned, there are good reasons to avoid exposing them. In this article, I’ll try to summarize the main drawbacks of using arrays in Java APIs.
Yes, we love building modular web applications, if they just were easier to deploy on a server! Wrapping OSGi applications in WAR files, apparently still the most popular deployment option for RAP, results in a complicated setup: a web app containing an OSGi runtime together with all bundles, configuration, and a bridge servlet that delegates requests to the embedded OSGi - that’s hard to build, hard to change, and hard to debug. Why can’t we just throw our application bundles into a webserver and simply turn it on?
Looking back on another eventful year for the RAP project, today we’re proud to publish the results in a new release, RAP 2.2. Let’s have a look at the highlights:
When you run JUnit tests that open windows and dialogs, all these windows pop up on your screen like fireworks, making your desktop unusable for minutes.
Earlier this year I’ve introduced Minimal JSON, a slim and fast Java library for reading and writing JSON. In contrast to object mappers such as Gson or Jackson, Minimal JSON does not more than reading a JSON text into a memory-efficient Java representation that can be accessed, modified and serialized to JSON again. You can see some code examples on the project page.
In the RAP project, reading and writing JSON are critical operations, since the server processes and creates JSON messages for a large number of clients at a high rate. For this reason, we need something fast for this job. When we switched to JSON, we included the org.json parser, which is reasonably small but not famous for its performance.
Today’s our big day: RAP 2.0 is being released. Here’s my last post in this RAP 2.0 series. In my first post, I wrote about the new JSON protocol and how it connects the half objects on client and server. The question is, can you leverage this protocol for custom add-ons? You can, using the new Remote API. I saved this topic until last. It’s my favorite because I’m excited about its potential to make RAP more extensible.
While we are waiting for the RAP 2.0 release to be published on Monday, I’m introducing you to the most important changes in this major release. For today, I’ve picked a slightly trickier part of RAP: the server push. RAP has built-in server push support, and a brand new push API in 2.0. Let me use the opportunity to shed some light on this topic.
RAP 2.0 is approaching and I want to explain the most important changes in this short blog series. The key innovation of RAP 2.0 is its support for alternative clients. Today I’d like to introduce you to the new Client API that lets you find out which client is currently connected. This interface can also be used to access some of the client’s specific features.
There’s only one week to go until the RAP 2.0 release. In this short blog series, I’d like to introduce you to the most important changes. Besides the new protocol, the main theme in RAP 2.0 is the consolidation of our APIs. After six years of RAP 1.x, it was time for a cleanup. In this post, I will explain the foundation of the RAP 2.0 API.
After more than six years of RAP 1.x, we will release version 2.0 on February 11. As the version number suggests, there are some substantial changes in this release. During the last few days before the release, I will guide you through the most important changes in RAP 2.0. It’s not so much about new features, but also about some realignments we made and the ideas behind them.
The RAP team has been working hard over the last weeks and made another milestone build for RAP 2.0 available today.
During the last weeks the RAP team has been busy lifting RAP’s client-to-server communication to the JSON protocol. That was a lot of work, and we finished it just in time for Kepler M2. With this milestone, the migration to the new protocol is eventually complete. All communication uses JSON now, and no undocumented HTTP parameters are involved anymore.
Just in time, the first service release for RAP 1.5 has been published on Friday.
In Java, every object has a method hashCode that is simple to understand but still it’s sometimes forgotten or misused. Here are three things to keep in mind to avoid the common pitfalls.
Update: It turned out that there is already a solution to the problem described here. The bundle org.eclipse.equinox.supplement exports the packages needed by equinox.common. This bundle is available from https://download.eclipse.org/equinox/. If you want to run Eclipse databinding, simply inlude this bundle and org.eclipse.equinox.common and you’re set. You can disregard the solution explained below. Thanks Pascal Rapicault for the pointer.
Eclipse 4 is the new platform for application development in Eclipse. We already succeeded to run e4 applications on RAP two years ago, but then we got sidetracked by other efforts. Now that Eclipse 4.2 has become the primary development stream in Juno, it’s time to have another look at the topic. Last Friday I met with Lars Vogel, author of the first book on Eclipse 4, to find out how much effort it would be to run an E4 application on RAP.
We’re proud to announce that a new RAP release is now available for download. Together with Eclipse Juno, RAP has just published it’s version 1.5.0.
Composite repositories make it easy to maintain different versions of a software in a single repository. The idea is to have one public p2 repository that delegates to a number of child repositories. Once you have a new build, you can easily add it to the composite repository and remove some obsolete builds. The child repositories can be anywhere, but it’s simple to keep them in subdirectories. Here’s an example:
RAP 1.5 includes a new API to define and start RAP applications programmatically (up to RAP 1.4, this was only possible using Eclipse extensions or web.xml properties). With this new API, RAP can also be used for leightweight applications based on OSGi, but without the entire Eclipse stack, even with other OSGi containers like Apache Felix. Also traditional web applications, that use RWT as a library without OSGi, benefit from the new API.
The RAP 1.5 M6 milestone build is packed with new features, especially for Trees and Tables. But most notably, you can now use HTML markup in Tables, Trees, and also in Labels:
Besides all the Java code in the RAP project, we also have more than 250 JavaScript files which total up to 75k lines of code. For such an amount of code, you should have some kind of code analysis that detects common coding problems like unintentional global variables. We use the JSEclipse plug-in for JavaScript editing which detects some, but not many JavaScript problems.
In the RAP framework, the widgets in a website are remotely controlled by the web server. The server does this by sending messages to the client in response to Ajax requests. Until now, those messages used to contain proprietary JavaScript that has been evaluated by the browser. Apart from the drawbacks of using eval to process server responses, this tightly couples RAP to its default browser client. The messages were so specific that only this client could understand them.
If you’re interested in the latest news on RAP, consider joining us at EclipseCon Europe next week in Ludwigsburg. There are quite a number of RAP talks this year:
Update 2: The new interfaces have been renamed again in RAP 1.5M7. Please refer to this post for the details and check out the updated code example.
The Enron Corporation was the American energy company that was involved in accounting fraud which led to the Enron scandal in 2001. During the investigation, large parts of the company’s email conversations were published. The result is that a huge, real-life data set including more than half a million emails from 150 Enron executives came into the public domain.
One of the new things in RAP 1.4 is the FileUpload widget in RWT, that replaces the old Upload widget from the sandbox. And there’s some more new upload stuff in the RAP Incubator. Here’s how to use the new features to upload files with RAP 1.4.
Support for key bindings (bug 282449) has been one of the most requested features for RAP. So I’m happy to say that since 1.4 M5, RAP implements the JFace key bindings API, provides the org.eclipse.ui.bindings extension point, and enables most of the default workbench key bindings. As a result, you can now use most* of the key shortcuts of your application also in the browser–if your application uses the workbench. But many use RAP without using the workbench. So how can you enable key bindings in a plain RWT application?
Another milestone build on the way to RAP 1.4 is available: RAP 1.4 M3.
After another 6 weeks of working hard towards the Helios Release, we are one step closer. RAP 1.3 M7 for Eclipse 3.6 is out. From the new features, here are my personal top three:
Here’s a nice Helios feature that comes in handy when you often work with multiple workspaces simultaneously (as we recommend for developing single source application with RCP and RAP). If you do, you probably know this which-is-which guessing when looking at your taskbar (or window switcher):
Would you like to get an overview of the best features in RAP in 5 minutes?
We try hard to enable a “sexy” look and feel for Rich Ajax Platform (RAP) applications. However, without rounded borders and gradients you can hardly create a website that look modern. Take this dialog as an example:
Enabling RCP applications to work with different locales is an essential requirement for server-side Eclipse setups. Multiple users are accessing the same instance of a running application concurrently, and each one should see the UI in his preferred language. Providing a server-side platform, the RAP project faced this problem too and we needed to find solutions to support multiple locales.
Did you notice that two out of the three finalists for the Eclipse Community Awards in the category “Best Commercial Equinox Applications” are based on RAP? One is a web-based customer relationship management system called PIA, a SaaS application for small and medium businesses.
The Eclipse RAP project has set out to realize the idea of “single sourcing”, i.e. to develop software for different target platforms from a common code base. The increasing popularity of mobile devices presents new challenges to this approach. In Version 2, the RAP project is open for interchangeable clients and thus accounts for this development.
