Grails part 2 – Setting up the environment

Requirements: basic Eclipse usage
Difficulty: introduction 

So before we go any further, I’d like to help you setting up a correct environment to use for developing a Grails application.
What you absolutely need is a Grails environment. Everything in Grails can be done using its console. Still, I strongly suggest you to use the Eclipse integration plugins, or the “Spring Tool Suite” from SpringSource, a branded Eclipse distribution especially designed to work with Spring based products (such as Grails, indeed).

Let’s start with the very necessary now. Download Grails from here: http://www.grails.org/Download
I’ll be using Grails 1.3.7 because I really hadn’t time to transition to 2.0 but I don’t think the differences actually impact the basic usage, so it’s up to you.
Once you download and unpack Grails in a convenient position, we’re ready to set up the client.
For this tutorial, we’ll be using STS as it’s the easiest way to get started.
You can download it from here:

http://www.springsource.com/developer/sts

Once you’re done with downloading and unzipping, you should find yourself with a Spring-branded Eclipse installation.

Note: this branded version of Eclipse aims to help in the development process of any Spring based application.

As STS gives you the basic dependencies to use any of the products of the Spring ecosystem, you now have to actually install the “Grails plugin”. As usual (if you’re not used to using Eclipse… your problem!), Help -> Install new Software -> (search for Grails) and finally install the plugin.

You’re almost set to go! Once Eclipse relaunches, go to “Preferences” , search for “Grails” and create a variable item pointing to the location where you unzipped your instance of the Grails platform.

Now you really are set to go

Yet another JVM programming language : XTEND

Hello!

Since this is my major trend these days, here’s another language for the JVM! Err… nope, not exactly. The language subject to our attention is a clean, fast language that then gets converted to Java language!

Endorsed by the Eclipse Foundation  -people we like and respect-, XTEND includes all the must-have functionalities these new languages must have.
No intention to be mean… but the syntax looks quite like Groovy, but hey… I always agreed with the thesis that every good idea should be copied to extend the benefits of a great improvement, and I’m not going to regret it now!

Sure thing the Eclipse support is gorgeous.

Give it a look, it’s pretty neat!

http://www.eclipse.org/Xtext/xtend/

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.