Grails part 1 – basic components and concepts

I feel guilty now. I really acted like a fanboy when, in the previous article, I just proclaimed the superiority of the Grails platform, rather than giving useful information.

So here’s what I’m going to do right now. I’ll try to create a sequence of articles describing the key “start points” of Grails. Hints trying to help you  understanding where to start your study. Each article will have some requirements and difficulty I’ll set at the beginning.

Requirements: basic programming, basic web programming, some database programming
Difficulty: introduction 

But let’s start right now, shall we? What I’d like to do today is to name some key components/concepts that will recur during the series.
If you have no idea of what a concept refers to, you should do a little google search before you proceed to the next step, but do not go too much in detail now, let’s just overview the whole thing.

Model View Controller or MVC
I have some sort of mania for this pattern… If you’ve never heard of the MVC pattern, then you really should start googling around now, but in a few words, a MVC is a pattern that should help you separating the model (data retrieval/modification mechanisms and business logic) from and the controller (describes the interaction between the components and the flows) from the view (presentation of the data) as much as possible. Each section should be able to do their job without being involved in the development of the others.
In this way:
- the model part will be in charge of implementing the business logic that regulates the access to the data, and performs the necessary transformations and calculations;
- the controller describes the flow of the interaction between the external agents (user or program), the model and the view;
- the view will create a proper presentation of the data that the controller made available, describing a paradigm the external agent (user or program) will use to interact back with the underlying controller.
It’s not a feature of a programming language, it’s a strategy and some frameworks (like Grails) not only help you applying it, but kinda force you to do so. Some other frameworks show a very weak separation between the model and the controller .
Some web developers working on small projects might not have used one, but MVCs are slowly being adopted also for tiny applications.
What you normally expect from a MVC framework is a specific way to write the flows in the controller and a specific language to write the view (to express the formatting of a variable, to iterate over a collection etc.).
In the Grails world, the model must be written in Groovy (a highly productive dynamic language, very close to Java) and the view in Groovy Server Pages (GSP), a very expressive “design” language.

Object Relational Mapping or ORM
If you come to me for an advice, make sure you have no line of SQL in your code, that is something that would turn me into a beast. Unless it’s very needed (see performance or some unidentified major reason) developers (and web developers) should have abandoned the direct use of SQL long ago.
ORM  is a technique that should improve the way software interacts with RDBMS, reducing the distance between the code and the data. How does this happen? Well, from the developers point of view, what happens is that you don’t really have to deal with tables, columns etc. anymore as tables are mapped to objects. Developers never actually see tables or the technical aspects of data retrieving, update and insertion.
One beautiful side effect of this approach is that since developers do not care much about the underlying database, multiple “dialect” connectors can be written so that from the software point of view, which database plays with its data, is not-a-software-problem.
This topic really requires some background in relational databases, so if you feel a little weak on this topic and your memory links words like “transactional”  to Skyrim, then some more study could help
Grails offers you a superb integration of a persistence layer named Hibernate (how persistence relates to ORM is something you should concentrate your study on). In very few words, this tool offers you the ability to connect to most databases, define schemas and run queries without really worrying about tables and SQL itself. Hibernate can be used in any Java application, but the Grails integration is something that will shock you, even if you already know the tool.

Test Suite
Unit testing and integration testing is what save you from the worst shit ever. Or at least it tries, since you’ll likely be writing your tests yourself!
Could sound boring (and it is) and some might consider it something “added to” the Grails platform, but believe me, it’s not. In these days I’m discovering myself how immense can be its help in fixing ugly code.
Grails offers you two ways of testing your work.
- Unit testing: a very clean way to test your units of code singularly. In short, imagine you could split your code in units as much independent from each other as possible (aka. good code) . Now imagine that you could associate to every unit, another piece of code that tests it with various input sets knowing already what result to expect (unit test). Now when you make some modifications to that code, you can quite be sure that if it passes the tests, the code is not losing compatibility with the previous version! If you don’t know what I’m talking about, see the links at the end of the article.
- Integration testing: a intriguing way to test entire procedures or sequences in an environment the resembles a full running environment. For example, this allows you not only to verify how the Encoder class encodes the user password, but also how the full login process works in all the various contexts.

These are the concepts behind the major key components of Grails.
If you want to follow the path of Grails, I think you should make sure that you already know what these concepts are about, at least for what concerns the theory.

Here some useful links:

Model-View-Controller
- High level explanation http://en.wikipedia.org/wiki/Model_view_controller  .
…further readings…
- Some more reading on how to use Spring MVC outside the Grails framework http://static.springsource.org/spring/docs/current/spring-framework-reference/html/mvc.html

ORM
- High level explanation http://en.wikipedia.org/wiki/Object-relational_mapping
- Data modeling http://www.agiledata.org/essays/dataModeling101.html
…further readings
- Hibernate… of course http://www.hibernate.org/

Unit testing

- More than sufficient http://en.wikipedia.org/wiki/Unit_testing
- JUnit http://www.junit.org/

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.