JFace and its model-view controller

As we saw in the SWT introduction, the Standard Widget Toolkit renders our data. It does not organize it, transform it, neither it helps us to handle it. And that’s correct. As the name says, it’s a widget toolkit, and it’s what we should expect.
But in our road to Eclipse RCP, here’s another vital friend: JFace.
JFace is a lot of things -maybe too many- but today we’ll be talking about its model-view controller.
Just a little preface for who never really faced theory behind model-view controllers.
In an application you usually have complex information and “views” on that information. When you display data, in fact, you transform tokens of data to make them coherent with the way you want the data displayed. A model-view controller is a formal way to do this, to replace long, hardly reusable, buggy code.
Think of it: once you have an algorithm to navigate information (as it could be a table, a tree, a chain of links…) and some rules to display the tokens of data properly, you just need to glue it all up. Debug and changes become simpler then ever. JFace will do this for us.
The main concept is that to handle structured data, you need a viewer, something that wraps the widget and learns from us how to render the complex data the application uses. If our application (or a portion) uses “Violin” objects, our TableViewer should not require “strings”, but violins and an interpretation key for violins
This is how a model-view controller works. Defined a structure to navigate data, defined a rendering method for one item of data, you have all you need to display automatically any type of information.

A peek into the Standard Widget Toolkit (SWT)

Before we start the real thing about Eclipse RCP, I think it’d be useful to get a closer look to SWT, the Standard Widget Toolkit, that is the GUI toolkit Eclipse is based on. Apart from the Eclipse thing, SWT can be used standalone to build simple application GUIs, and this is what we’re going to talk about here. I’m going to give you an overview of its main features and limits, assuming that you already had some experiences with graphical user interfaces in Jaa.

The main difference between Java Swing toolkit and SWT is that the first one is entirely written in Java and most of the user experience is perfectly identical among different OS, while the second one is made up of two parts: a Java library and a system library. The Java library is (almost) the same among all systems, and the system library obviously is different from OS to OS. For this reason, SWT applications perfectly integrate in the operating systems environment, but the user may experience slight changes depending on the OS. That’s why a cross-check among different systems may be required.

What we’ll be doing here is an overview of what SWT programming means. I’ll put some bibliography to go into details inside the article.

For the following examples, we’ll be using Eclipse for the development process and I’ll assume that you’ve already taken my suggestion and you’re an expert already
Start a new Eclipse Java project and add a new Library variable to the classpath that contains every jar in your plugin directory with a file name containing “SWT”.

An RCP to rule them all – Introduction

Building portable user interfaces is not just a stressing and very little appreciated job, but also one of the hardest tasks. Toolkits are -most of the time- dumb, too complex, unpredictable and overthreaded.
Most of these toolkits can be divided in two categories:

• I can do anything, but a tremendous complexity makes me hard to understand and unstable when things get tough
• I can do very few things, with style and ease, but I follow an “obvious” guideline that can’t be extended

But toolkits are just a part of the game. In fact, most of the time, what programmers are actually looking for is a “rich client platform”.
Not just some functions and objects, but a tool to arrange space, manage interactions and set a functional standard.
I must admit I haven’t tried many platforms, but Eclipse RCP, for Java development, really really surprised me. It’s three years now I’m using it, and (except for some obvious “wouldn’t it be nice”) I wouldn’t change a thing.