Duncan Sommerville - Developer Thoughts

Grails From Basics - Using an IDE

2010-05-01T21:42:00.023+01:00

My last post got us up and running with a trivial application using the command-line - although not particularly exciting it is important to understand how to interact with Grails from the command-line, especially when debugging.

However, we can make life much easier for ourselves by leveraging an Integrated Development Environment (IDE).

There are many to chose from, but the predominant Java-orientated ones are:

IntellijIDEA

Eclipse

Netbeans

I have limited experience with IntellijIDEA, but have heard good reports (although I'm also told that it's quite resource-hungry). I did use Eclipse a few years ago and liked it, but the integration with Grails was quite painful at the time.

This led me to Netbeans, which I rather like - I have seen it steadily improve over the last couple of years and, while it appears to be regarded as a bit of an underdog, I think its integration with Grails is first-rate.

The main thing missing from Netbeans in terms of Grails integration (this applies to all the other IDE's as well) is the inability to run an application in 'debug' mode directly, although I believe it's on the Netbeans roadmap.

If you need to step through the code in 'debug' mode you need to run the application from the command-line using 'grails-debug run-app' (rather than 'grails run-app'). This will run the application, but with a listening TCP/IP socket on port 5005 to which Java debuggers can attach.

Consequently you can 'attach' Netbeans to the running process and set a breakpoint - this works, but is somewhat tedious and makes debugging things like startup issues very difficult. However, we're getting ahead of ourselves - more on debugging applications later...

Netbeans gets my vote - as such I will use it as the IDE for the remainder of these Grails' posts, but I'll be very interested to receive comments about other IDE's.

So, lets re-create our 'library' application using Netbeans instead of doing everything via the command-line.

Delete the contents of the 'GrailsDemo\library' directory if you wish (although Netbeans will create our new project in a separate directory). However, if you want to completely re-create the 'library' project you will need to delete the contents of the following directory:

%HOMEPATH%\.grails\1.2.2\library

Alternatively you can simply create the Netbeans project with a slightly different name, although I do think that it's important to know how Grails works under the bonnet and know where all its files reside.

If you haven't done so already download and install Netbeans 6.8 or later with Groovy support - this is included in the 'Java' and 'All' downloads (I tend to simply download the 'All' distribution, then disable those elements that I'm not interested in during the installation).

Once installed start Netbeans and allow it to check for and install any updates (force it via Help menu and Check for Updates option, if necessary), then create a new project:

FileNew Project...

Select a Cateory of 'Groovy' which has only one type of Project - a Grails Application:

Click the 'Next' button and set the Project Name to 'library' and click the 'Finish' button:

This will invoke 'grails create-app' on the command-line after which Netbeans will provide you with a Output pane in the bottom-right corner of the console output and a breakdown the project hierarchy on the top-left:

I tend to turn off the Navigator pane (bottom-left) as it's not particularly informative with the Groovy language due to its dynamic nature - this gives you more space to navigate the various artifacts.

Expand the folders in the Project pane - you will see files exist under the following:

Configuration

Message Bundles

Views and Layouts

Web Application

This arrangement is very similar to the Grails directory structure and is easy to navigate:

However, while it is intuitive the layout isn't exactly the same which can thrown you off - it also fails to give you access to everything in the Grails hierarchy (in particular, the 'templates' directory if you install this plugin, which we'll come on to later).

If you wish to view the files and directories click on the Files tab which does give direct access to the exact directory structure and files therein:

It's also worth checking out the Services tab - this is where the servlet containers (Jetty, Tomcat, Glassfish, etc) are listed and can be controlled, as well as integration with other external services such as MySQL and Hudson:

Finally, it's also worth knowing where Netbeans stores configuration options relating to Groovy and Grails - go to the Tools menu and click on Options; you then need to click on the Miscellaneous button followed by the Groovy tab:

Although not particularly intuitive the good news, as you will see, is that there are very few options. The main one to watch is the Grails Home path - make sure you update it if you download and unzip a newer version of Grails later on, as it overrides the GRAILS_HOME environment variable...

Now that we've explored Netbeans a little and created our application let's start creating our artifacts (ie a Domain Class and associated Controller) as we did in the previous posting, but this time through the Netbeans interface.

First of all we need to create a Domain Class called 'Book' that exists in the 'com.example' package - right-click on the Domain Classes folder and select New followed by Grails Domain Class...

Specify the Artifact Name of 'Book' and Package of 'com.example', then click Finish:

As before, our Domain Class has now been created with skeleton code - note that Netbeans has provided the output from the command-line in the Output pane on the bottom-left:

We can now edit our class as before:

Notice the syntax-highlighting provided by Netbeans - keywords are in blue, variables are in green and the toString() method has been highlighted in bold.

So far so good - we now need to create a Controller so that our users can interact with the Domain Class. As you might expect, right-click on the Controllers folder, select New then Grails Controller....

Enter the Artifact Name (which is still Book, rather than BookController; Grails will append the 'Controller' bit to the class and filename for us) and use the same Package name of 'com.example':

Netbeans will invoke Grails on the command-line (and again, you can view the output as it happens in the Output pane on the bottom-left) to create a new Controller called BookController with skeleton code:

As before, we need to replace the Controller code with a single statement that tells Grails to 'scaffold' everything for us:

That's everything in place - run the application by clicking on the green arrow icon on the top toolbar. Alternatively you can press <F6> or go to the Run menu and choose the Run Main Project option.

Netbeans will effectively issue a 'grails run-app' command, with the output appearing in the bottom-right Output pane - once the server has been started Netbeans should launch your default browser and open a new Tab or Window at the appropriate URL for your running application.

To stop the application switch back to Netbeans and click the square red button on the left of the Output pane. You can also view all running services by clicking on the Services tab (top-left) and expanding the Servers, then Jetty icons and right-clicking on the 'library' service.

So, we now know how to create a trivial Grails application using an IDE - future postings will start to delve into some other practicalities such as unit-testing, altering the scaffolding, persisting data (so we don't lose it all every time we stop the application) and stepping through code with the debugger.

Keep watching this space...

Grails From Basics - First Application

2010-04-27T21:48:00.019+01:00

Yesterday I covered the basics of getting your environment set up and ready to run your first Grails application.

We'll now step through creating an application using the command-line, which is quite straightforward.

First of all we need to create a 'workspace' directory (I've created one called 'GrailsDemo' under 'MyDocuments') then change into that directory and type the following:


grails create-app library

What Grails actually does is create a directory heirarchy that is largely empty but with directories that will hold our classes, controllers, services, tag-libraries, etc. Some of these directories (most notably the 'grails-app/conf' directory) will be populated with default configuration files:

As the name implies, our sample Grails application is going to be an online library system that allows us to build up a database of books together with associated authors, publishers, and so on - this also ties in quite closely with the examples provided in the main Grails documentation.

We could run this right now, but the application wouldn't actually do anything as we've not yet defined any classes...

What we need to do is define our first Domain Class; a Domain Class is simply a regular Groovy class (Plain Old Groovy Object or POGO) that resides in the 'grails-app/domain' directory. Any class that is found in this directory (or subdirectories) will be persisted by Grails to some sort of underlying database.

For our example application we will start by simply creating a Book domain class:


grails create-domain-class com.example.Book

Note the use of 'com.example' before the class name - this is simply a fully-qualified class name that prevents the name of our Book class from clashing with Book classes defined anywhere else in the system - you would normally use your own domain-name (in revese) here:

This command will create the 'com/example' directory structure under 'grails-app/domain' for us and create a file called 'Book.groovy' with skeleton code inside:

We need to edit the skeleton code to something meaningful - for now we'll simply add a single String property called 'title' and place a 'constraint' on it that says that it cannot be blank. We'll also create a toString() method (that simply returns the 'title' string) which Grails' scaffolding can make use of - more on all this later:

So far we have defined our Domain Class (Book) but we also need to create a Controller that will interact with our users. The Controller will handle user requests and manage instances of our Domain Class for us - in other words the Controller will allow us to create, read, update and delete (CRUD) instances of our Domain Class called Book:


grails create-controller com.example.Book

Without a Controller our users can do nothing:

As with the Domain Class, this command will create the 'com/example' directory structure under 'grails-app/controller' for us and create a file called 'BookController.groovy':

Again, the file will be created with skelton code:

Grails offers something called 'scaffolding' to get you up and running as quickly as possible - this means that although we do need to create a Controller, we can tell it to 'scaffold' the usual create, read, update and delete operations for us via a single line of code:

Grails uses 'convention-over-configuration' to assocate the BookController controller class with the 'Book' domain class, as they both have the same prefix - you can change this if desired, but it's likely to make things confusing...

We now have everything in place to try our first run of the library application - give it a go:


grails run-app

Note the URL in the last line; open your favorite browser and enter that URL in the address-bar - you should see something like this:

Click on the link below 'Available Controllers' and have a play - you should find that Grails has created a set of Views that will interact with our BookController, both based on 'scaffolding':

The only two hints we had to provide were:

The toString() method in the Book class
The def scaffold = Book line in the BookController class

Grails does the rest for us!

To terminate the application simply press <CTRL>+<C> in the command window:

The covers the absolute basics of creating a Grails application. Next time we'll create the same application using an IDE, rather than doing everything from the command-line - this should help to illustrate just how much easier using an IDE makes things.

Grails From Basics - Environment

2010-04-26T21:47:00.011+01:00

I've been meaning to do this for a while, but I wanted to put together a series of posts that help people get started with Grails, even when they have limited experience of J2EE and surrounding technologies (such as Spring and Hibernate).

There is now an increasing amount of documentation surrounding Grails, much of it excellent (I'm a particularly big fan of Grails in Action). However, lots of the artciles assume a base level of knowledge and experience with Java, Groovy, Spring, Hibernate, etc.

When I first started using Grails I had very little experience with many of these, apart from standard JDK - as a result I struggled with the learning curve to get up to speed with so many different technoligies all at once.

Grails does a fantastic job of hiding the complexities of many of these underlying technoligies through its adoption of 'convention-over-configuration', but inevitably there comes a time in any non-trivial application when you need to pull back the covers and change the default way Grails does things - this is where I started to find things quite challenging!

Consequently these articles will start by assuming you know relatively little about Java, J2EE, Groovy, Grails, Spring and so on, although I will assume the following:

That you have some programming experience.

Ideally Java, Ruby or similar, but any modern object-orientated language should do.

It would also be an advantage if you were familiar with the Model-View-Controller design pattern.

This is the architecture on which Grails is based.

That you can download, install and configure applications on your computer.

We will create a simple project using Grails in these posts - my environment will be based on a completely clean Windows XP Pro (SP3) desktop. I realise that this is a bit boring and somewhat dated, but it's still very common and provides a well-supported platform on which to build our project - it'll also minimise environmental distractions. Feel free to use a different operating-system, but you're on your own in terms of configuring it.

For this first post we'll simply get things set up - to start with we need to download a number of applications and packages:

Java SDK

J2EE SDK

Grails

Netbeans

MySQL Server

MySQL Connector/J

Tomcat

Console2

Please don't be put off - you don't need to download and install all of these right away and don't worry too much about getting the exact versions either:

The first thing you'll need to install is the Java JDK, followed by J2EE. Once these are in place you will need to unzip the Grails download to a suitable place - I usually place it in a directory called 'grails' from the root of the drive:

Once unzipped you need to set a couple of environment variables:

JAVA_HOME

GRAILS_HOME

Set JAVA_HOME to the directory in which you installed the JDK and GRAILS_HOME to the directory into which you installed Grails:

That should be it - open a command-print (Start -> Run -> cmd) and type the following:

java -version

If Java is setup correctly you should get some sensible output telling you about the version of Java that you're using:

Following this type the following to check Grails:

grails -version

Grails doesn't actually recognise the '-version' switch, but if everything is setup correctly you should see something sensible output, including information about the version of Grails that is installed:

If you try to run Grails without setting the environment variables you will see something like this:

That's all you actually need to get started - in the next posting we will step through creating an application via the command-line, after which we'll change to using an Integrated Development Environment (IDE) which makes life much easier - this is there Netbeans comes in.

Upgrading to Grails 1.2

2010-01-08T11:58:00.002Z

We have recently upgraded two of our main projects from Grails 1.1.2 to Grails 1.2.0, which for the most part went very smoothly.

However, we did notice a couple of oddities with one of the projects:

The main index.html page contained code similar to the following:
```
 <g:isNotLoggedIn>
  ${response.sendRedirect(createLink(controller: 'login', action: 'auth')}
 </g:isNotLoggedIn>
```
This was throwing an exception for some strange reason, which we traced to the createLink() tag library - we solved the problem by replacing the createLink() with a string:
```
 <g:isnotloggedin>
  ${response.sendRedirect('login/auth')}
 </g:isnotloggedin>
```
Although not particularly elegant, it solved the problem - perhaps someone can suggest why createLink() should have stopped working?

The other problem we encountered was when trying to untar a TAR'd file, which resulting in a ClassNotFoundException. It turns out that this library was provided through ant-1.7.0.jar which was part of the Grails 1.1.2 distribution, but this no longer appears to be the case. Finding and adding ant-1.7.0.jar to the lib folder of our upgraded project solved the problem. Again, I'm not sure why this JAR has been dropped - perhaps someone can comment?

GroovyMag

2010-01-07T09:54:00.002Z

I am astonished and humbled to have been listed as a UK blogger in the excellent GroovyMag (Volume 2, Issue 3, January 2010, Page 4).

For those who are not aware, GroovyMag is a monthly magazine that contains various articles about Groovy, Grails and related technologies (Grails Plugins, Griffon, Scala, etc). The magazine is published and downloaded as a ZIP file that contains the main magazine in PDF format, together with source-code to accompany relevant articles.

Recent articles that I have found particularly useful and/or interesting include:

Building a Grails portal (Volume 2 - Issues 8, 10, 12)
Goldilocks and Grails Logging (Volume 2 - Issues 7, 8)
Enterprise Development with Groovy & Grails (Volume 2, Issue 11)

Clearly, there are lots of other excellent articles - those above are simply some that stood out for me.

Both my team and I use Groovy and Grails on a daily basis and have had many successes to date. However, working with emerging technologies is not without its frustrations, with Grails in particular giving us many headaches.

One of the biggest challenges when working with any new technology is finding accurate and up-to-date documentation - this is steadily improving and I thoroughly recommend both Groovy in Action and Grails in Action, which have effectively become our bibles. However, this is where blogs and online forums can prove invaluable and is why I have tried to contribute.

I must confessed to not having had the time to post many articles recently, but will certainly start doing so shortly - watch this space!

Grails 'metadata' from within HttpSessionListener

2009-10-15T09:34:00.005+01:00

I needed to extract the application-name during execution - under normal circumstances this can be achieved as follows:


 String appName = grailsApplication.metadata['app.name']

However, I recently needed to extract the application-name from within an implementation of the HttpSessionListener interface (which does not support inject of the grailsApplication object). This was part of resource releasing once following a session timeout.

Access to the same object can be achieved from within a SessionListener via the ApplicationHolder class:


 import org.codehaus.groovy.grails.commons.ApplicationHolder
 
 ...
 
 String appName = ApplicationHolder.getApplication().metadata['app.name']

Determine Base-Directory from Running Grails Application

2009-10-15T08:48:00.009+01:00

It's been a while since I've had chance to post, so here are a couple of short articles to get back into the swing of it.

First off, here's how to determine the base directory of a running Grails application:


 String dir = grailsAttributes.getApplicationContext().getResource("/").getFile()

The grailsAttributes object is available in all Controllers, but is not directly available in Services (nor can you inject it).

Should you need to to determine the base directory from within a Service (or access grailsAttributes etc) you need implement the ApplicationContextAware interface:


 import org.springframework.context.*
 
 class MyService implements ApplicationContextAware {
   ApplicationContext applicationContext
 
   ...
 
   String dir = applicationContent.getResource("/").getFile()
 }

Grails & MySQL Tables

2009-10-01T21:33:00.008+01:00

Discovered a 'gotcha' today with Grails when using it to create tables in a MySQL database - we had the following entry in our DataSources.groovy:


 development {
  dataSource {
   dbCreate = "create-drop"
   url = "jdbc:mysql://localhost/mydb"
  }
 }

Nothing obviously wrong with that - except that MySQL will use its default 'engine' to create the tables.

This is typically the MyISAM engine which offers fast reads, but no transaction protection.

The reason MySQL defaults to this engine is that it is often used to hold large amounts of relatively static and read-only data (a product list for a website for instance), often as part of a LAMP deployment. Such read-only deployments do not require transactions.

You can check which engine is associated with each table in MySQL via the following statement:


 SHOW TABLE STATUS;

If MySQL is creating your database tables with the MyISAM engine, then the following statement in your Grails Services will have no effect:


 static transactional = true

As such, Grails methods such as user.discard() appear not to work - the update has already been written to the database and cannot be rolled back.

This can also adversely affect Integration Tests if they try to roll-back database updates as part of a test-case scenario (in readiness for subsequent tests). You expect the test-case to have discarded whatever test data was written to the database, only to discover that it still exists!

The solution is quite easy - you need to add a dialect statement to the dataSource to tell MySQL to use a different engine; one that offers transaction protection, such as InnoDB:


 development {
  dataSource {
   dbCreate = "create-drop"
   dialect= "org.hibernate.dialect.MySQLInnoDBDialect"
   url = "jdbc:mysql://localhost/mydb"
  }
 }

The InnoDB engine also has the advantage of providing row-level locking (whereas MyISAM locks the whole table for each insert or update) and it also enforces foreign-keys constraints.

Consequently, web-applications with medium-to-large volumes of data are likely to perform faster if a transactional engine such as InnoDB is specified when using MySQL.

Note that you could also change the default storage engine used my MySQL via the my.cnf file:


 default-storage-engine=innodb

Custom Validation Messages in Grails

2009-09-23T20:41:00.002+01:00

Grails stores its validation messages in a set of external files that can be found in the grails-app/i18n directory - there are several files, with each file targeting a different language.

This means you can internationalise your application with relative ease, by adding messages to these files in the appropriate language and having Grails select the appropriate language at runtime (or per session).

You can also add bespoke validation messages that override the 'default' messages provided. For example, the messages.properties file contains lines such as:


 default.blank.message=Property [{0}] of class [{1}] cannot be blank

This means that if one of your classes fails validation because a field is empty, then a message saying something like the following is added to its errors property (and typically displayed through a flash message):


 Property [password] of class [user] cannot be blank

This is OK during development, but is not going to be particularly friendly for your average user - thankfully you can override these default messages on a class-by-class basis, so you user sees messages such as:


 Password required

However, it can be very difficult to find documentation on what the 'identifiers' of these messages should be (the bit on the left-hand side in message.properties).

The format of each identifier is:


 ${class}.${property}.${error}

Unfortunately the ${error} section does not directly match the existing contents of the messages.properties file or the labels used within the contraints section of your domain class.

The list below shows the available ${error} properties to use when defining your own validation messages:

blank
email.invalid
not.inList
matches.invalid
maxSize.exceeded
minSize.notmet
nullable
size.toobig
size.toosmall
unique
url.invalid
validator.error

Consider the following domain-class as an example:


 package com.example.myapp

  class User {
    String username
    String password
    String emailAddress
 
    static constraints = {
      username(blank:false, unique:true)
      password(blank:false, minSize:6)
      emailAddress(blank:false, email:true)
    }
  }

This means that we can define bespoke messages in message.properties as follows:


 user.username.blank=Username required
 user.username.unique=Username must be unique
 user.password.blank=Password required
 user.password.minSize.notmet=Password is too short
 user.emailAddress.blank=Email required
 user.emailAddress.email.invalid=Email not recognised

One final note: If your class is declared within a package, you do not need to specify the full class name.

Using the Grails SpringSecurity Plugin

2009-09-22T20:52:00.006+01:00

Many web-applications require users to authenticate at some point - this can be for many reasons, but typically includes access to a privileged area, retrieval and management of that user's profile and to track behaviour and preferences for marketing purposes.

Creating a simple login form and forcing users through it is relatively straightforward in Grails by creating a SecurityFilters.groovy under the grails-app/conf directory, as described by this tutorial.

However, there are plugins available that provide additional capabilities such as registration forms, 'captcha' controls, support for OpenID and LDAP integration, to name but a few.

There are two Grails security plugins that seem to dominate in popularity at the moment:

Spring Scurity (aka ACEGI)
JSecurity

Of these I have only used Spring Security in anger, so can't really comment on JSecurity, but I have seen good reviews - my impression is that it offers slightly less features, but is easier to implement and maintain as a result.

Having said that, I have found the Spring Security plugin to be more than adequet for my own needs and relatively straigtforward to implement - here's a quick overview and a brief introduction on how you might configure it:

First off, you need to install the plugin:


  grails install-plugin acegi

Your next job is to create what are called the 'authentication domains', of which there are three:

Authority
Person
Requestmap

These are domain classes in the usual sense - they exist in the grails-app/domain directory and get referenced by the underlying authenticateService that is installed as part of the plugin.

You can create these new domain classes, based on the class-names above, as follows:


  grails create-auth-domains

However, you can pass parameters to this command if you wish to create classes with alternative named - perhaps names that align more closely with your business-model and/or design - for example:


  grails create-auth-domains User Role UrlMap

The above will create the same three classes, but with different names:

User -> Person
Role -> Authority
UrlMap -> Requestmap

Behind the scenes the plugin also creates a file called SecurityConfig.groovy under the grails-app/conf directory which defines how our custom class-names above (User, Role, UrlMap) related to the classes expected by the plugin.

You need to be careful here - the temptation might be to start editing these classes so they contain properties that exactly match your design, especially within the User (Person) class.

While there is nothing stopping you from adding new properties, be cautious about renaming existing properties, as the underlying authenticateService specifically expects some of them to exist.

In particular, do not change the following properties:

User (Person)

username

passwd

enabled

Role (Authority)

authority

UrlMap (Requestmap)

configAttribute

Also note that the 'relationship' properties (those named via the hasMany and belongsTo statements) cannot be renamed - this can produce classes that look slightly odd:


  class User {
    static hasMany = [authorities: Role]
    ...
  }

  class Role {
    static hasMany = [people: User]
    ...
  }

As you can image this also leads to a database schema that is not particularly obvious - in particular you end up with a join table called role_people that actually relates to the user table.

The next step is optional, but I recommend it to start with to get you up and running quickly:


  grails generate-manager

This creates both the controllers and the views for each of the domain classes created by the create-auth-domains command.

You can replace the Role and UrlMap controllers with basic scaffolded versions if you prefer, but leave the User controller alone. Likewise, you can remove the generated Role and UrlMap views and rely on Spring scaffolding to create them on demand, but once again, leave the User views alone.

You may also notice that some new views are available under a new directory of grails-app/views/login - these are the default login forms provided by the plugin.

Once the plugin has been installed and the appropriate class, controllers and view generated (as above) you can configure it as follows.

First you need to create a Role (Authority):


  http://localhost:8080/myapp/role/create

Set the authority property to ROLE_USER or similar (ie ROLE_ADMIN, ROLE_SUPPORT, etc). Note that the 'ROLE' prefix is important and is expected by the controller.

Next you need to create an UrlMap (Requestmap) entry:


  http://localhost:8080/myapp/urlmap/create

Set the url property to the URI that you wish to protect access to - for example, if we had a class called Book that we wanted to protect, we might set the url property to:


  /book/**

This matches everything under the book URI, which covers the list, create, edit and delete actions.

Then set the configAttribute property to a comma-delimited string of authority values defined earlier in the Role (or Authority) class - in our case this is ROLE_USER.

The plugin will now ensure that anyone wishing to access the /book URI (and anything below it) must have the ROLE_USER role.

Finally, we need to create a user account:


  http://localhost:8080/myapp/user/create

The Spring Security plugin will reference the username, password and enabled fields when authenticating users.

The base of the form also displays a list of available Roles with checkboxes next to each one - this allows you associate a User with one (or more) Roles. Once the user is created, try and access the Book URI:


  http://localhost:8080/myapp/book/

You should find yourself redirected to the login form provided by the plugin where you need to enter the username and password entered when you created the user.

Assuming valid details are provided the ROLE(s) associated with that account are checked - if one of these roles matches the UrlMap entry for the /book URI the permission will be granted.

This covered the basics of getting up and running with the Spring Security plugin for Grails - I have only really skimmed the surface and the above illustrates just one possible way of configuring the plugin

Please reference the tutorials for further information.

Mapping Natural Keys using GORM

2009-09-21T20:44:00.004+01:00

I needed to use GORM within Grails to map a legacy database today.

This in itself isn't particularly difficult, however there's quite a neat trick available when you need to map a 'natural key' onto the internal id field required by GORM.

The table in question was called users and took the following form:


login     varchar(20) not null primary key,
password  varchar(20),
full_name varchar(20)

I know - a good example or how not to implement a database schema. Nevertheless, this is what I was presented with...

Forgetting the natural 'natural-key' field (login) for a moment, the Grails domain-class took the following form:


class User {
  String password
  String fullName

  static constraints = {
    password(nullable:true,maxSize:20)
    fullName(nullable:true,maxSize:20)
  }

  static mapping = {
    table 'users'
    version false
  }
}

So far so good - both the password and full_name columns are varchar types, which map to Strings via GORM. They can both be nullable (yes, really) and I have added a max-size constraint for input validation.

Note that I do not need to include these properties in the mapping section, as password matches its column name and GORM will automatically translate the field called fullName to a column called full_name.

I then used a mapping closure to map to the users table (plural - otherwise GORM would look for a table called user). We also need to indicate that the version column does not exist in our legacy database.

Now the clever bit - we map the id field within GORM to a transient field, then use a custom getter and setter to control it.

This gives us the following:


class User {
  String id
  String password
  String fullName

  static transients = ['login']

  static constraints = {
    id(unique:true,blank:false)
    password(nullable:true,maxSize:20)
    fullName(nullable:true,maxSize:20)
  }

  static mapping = {
    table 'users'
    id column: 'login'
    version false
  }

  void setLogin(String login) {
    id = login
  }

  String getLogin() {
    id
  }

  String toString() {
    id
  }
}

We have created a transient field called login - this simply means that it will exist within our domain object, but will never be persisted to the underlying database. The domain class now effectively has a virtual property called login that is set via setLogin() and returned via getLogin().

So when we create a new User object, complete with a login property, the setter will automatically update the [persistent] id property instead. GORM will then use the id property and map it to the underlying login column within the database table.

This really can be life-saver when using Grails to communicate with legacy databases

Initial thoughts on jQuery

2009-09-18T16:32:00.010+01:00

I am very new to jQuery but have already had a 'eureka' moment while reading about what it is and why you might want to use it.

Briefly, jQuery is a free and open-source JavaScript library designed to make life easier when implementing client-side controls using JavaScript. However, this simple explanation belies a subtle but immensely important principle - separation of concerns.

Just as HTML and CSS each have separate responsibilities when rendering a web-page (HTML dictates the structure of the page, while CSS controls its presentation), so too is the case with jQuery - its responsibility is to control the behaviour of the page, removing the need to embed JavaScript events within HTML markup.

For example, consider the following traditional HTML snippet:


  <a href="" onmouseover="alert('Pop!');">Surprise</a>

This is rather spurious, but you get the idea - we have a link which pops up a message box when the mouse goes over it.

The problem is that we have JavaScript embedded in our HTML markup - a bad idea.

Sure, we could move alert('Pop!'); to an external JavaScript file and reference it via a <script> tag in the header - this is an improvement, but we still need the onmouseover attribute to exist as part of our HTML in order to link the JavaScript to our field.

jQuery provides a way of avoiding this - our HTML no longer requires events to be associated with specific elements:


  <a id="surprise" href="">Surprise</a>

Note that we have added an id attribute which can be referenced both from CSS and jQuery - we now need to add our JavaScript to the <head> of the page as follows:


  <script type="text/javascript" src="scripts/jquery-1.3.2.min.js"/>
  <script type="text/javascript">
  jQuery(function() {
    $("#surprise").mouseover(function() {
      alert('Pop!');
    });
  });
  </script>

The first line includes the jQuery library, while the rest implements our event.

Don't worry about the syntax for now - what we're doing here is attaching a function to the mouseover event on any DOM object that has id of 'surprise' (since it's an id reference, there can only be one).

As expected, our function once again displays our popup alert, but without any dependency on the HTML markup - good separation of concerns!

Hanging Indents with CSS

2009-09-18T16:01:00.016+01:00

We had a need to create hanging indents for paragraphs recently, which turned out to be relatively straightforward through a combination of using text-indent and padding-left properties:


  .hang {
    padding-left: 2em;
    text-indent: -2em;
  }

Paragraphs can then have the hang class applied in order to be presented with hanging indents:


  <p class="hang">
    Lorem ipsum dolor sit amet...
  </p>

Rember This Milk

2009-09-17T11:57:00.004+01:00

A recent posting from Smashing Magazine pointed me towards Remember The Milk, which is an online task and time-management application.

I have to say I'm impressed - and on several levels.

First of all it's free - a paid-for 'pro' upgrade is available (US$25 per year) which gives you some extra features such as iPhone and iPod support as well as synchronisation to Blackberry devices etc, but the 'free' version is certainly not lacking.

Secondly it works very well - you can create tasks easily and categorise them under groups like 'personal', 'work', etc and set appropriate attributes for each task such as due-date and time, repetition, notes and location. You can also assign arbitrary 'tags' to a task, which allow you to group and explore tasks in an abstract manner.

All of this is very nice, but not particularly new - the likes of Google and Yahoo have offered online calendars and task-lists for quite some time now.

However, one of the things that sets Remember The Milk apart is the easy integration with other applications and devices. In my case I needed to integrate with the Lightning add-on to Thunderbird which proved almost trivial.

Task lists within Remember The Milk are each supported by an iCal interface - you can either reference a single interface that contains all your tasks (regardless of category) or you can reference just a single category.

This means that I can link my email client at work to just my 'work' category and my home email-client to just my 'personal' category.

Another thing that sets it apart is the ability to 'share' a task-list with known contacts so more than one person can see and change your tasks (consider a PA, for example). You can also 'publish' a list, which gives read-only access to either a set of contacts or the general public.

The final thing that impressed me about Remember The Milk is the design of its user-interface, which is about as forgiving as possible and a great example of how a web-based user-interface should be implemented.

For example, when registering for the first time fields get validated as you type, rather than upon final submission of the form. Another example is that dates can be entered in as free-form text and are interpreted sensibly - this allows dates such as 'tomorrow', 'end of month', '5pm' and so on. All of this follows the Forgiving UI Design Pattern.

A similar principle exists when entering new tasks - you can use a shorthand to specify the date and tag(s) of a task all in one go - for example:


Meet Sally for Lunch ^12pm #personal

The above creates a new task called 'Meet Sally for Lunch' that is scheduled for 12pm today (the '^' prefix) with a tag of 'personal' (the '#' prefix).

I've only highlighted some of the features here - there's lots more the service can offer (offline support, for instance), but take the time to have a look, if only to see a good example of user-interface design.

Terminating a Servlet

2009-09-16T13:48:00.025+01:00

I needed to terminate a Java Servlet recently if a startup condition failed - my initial approach was:


    System.exit(-1)

However, this terminates the entire servlet-container (Jetty, Tomcat, Glassfish, etc) together with any other servlets that may be running within. What I wanted was to just terminate the servlet in question...

As usual, the answer is relatively straightforward - you need to throw a servlet exception - at first glace this can be achieved using javax.servlet.ServletException.

The servlet-container will catch this exception and gracefully terminate the servlet without affecting any other running servlets.

However, there is also an UnavailableException (a subclass of ServletException) that is more appropriate for indicating mis-configuration, etc. Interestingly, this class can be used to indicate both 'permanent' and 'temporary' unavailability, with permanent unavailability meaning that the servlet cannot recover.

If an permanent UnavailableException is thrown during the init() method, the servlet will never enter into service. Alternatively, if the exception is thrown during normal processing, the servlet-container will remove that servlet instance and create a new one in its place.

If a temporary UnavailableException is thrown the servlet-container will generate a HTTP 503 message, with the Retry-After header set to indicate to the client how long the service is likely to be unavailable for. Note that thowing a 'temporary' UnavailableException during the init() method prevents the servlet from entering into service - as with a 'premanent' exception above.

In my case I wanted to indicate 'permanent' unavailability, which is based on the following snippet:


  import javax.servlet.*

  if (true) {
    throw new UnavailableException("Startup condition failed")
  }

Groovy Array of IP Addresses

2009-09-16T13:32:00.007+01:00

I had a requirement to return all the IP-addresses allocated to a host recently, which proved relatively straightforward once I'd figured out how to cast a List object to a String[]:


import import java.net.InetAddress

String[] ipAddresses(String hostname) {
  List list = []

  InetAddress.getLocalHost().getAllByName(hostname).each { addr ->
    list << addr.getHostAddress()
  }

  list.toArray(new String[list.size()])
}

Trying to return a String[] gave me a bit of a headache - the problem is that Groovy does not let you dynamically add entries, as you can with a List or Map.

The solution (as shown above) was to dynamically populate a local List, then create a String[] of the required size and populate it via toArray() to convert [and return] it.

Creating MD5 Digest in Groovy (or Java)

2009-09-15T15:48:00.018+01:00

There is a quick-and-dirty way to generate MD5 digests in Groovy (or Java):


import java.security.MessageDigest

MessageDigest digest = MessageDigest.getInstance("MD5")

digest.update("encodeMe".bytes)

BigInteger big = new BigInteger(1,digest.digest())
String     md5 = big.toString(16).padLeft(32,"0")

The above encodes the candidate string "encodeMe" to an MD5 digest.

If there are any Grails users reading, please note that you can simply use one of the built-in codecs:


 String md5 = "encodeMe".encodeAsMD5()

Hopefully this will be if use to someone.

Visual Browsing

2009-09-15T08:39:00.005+01:00

No sooner had I published my previous post on browser trends than I see the BBC reporting on both Google's new Fast Flips approach to browsing the Internet, as well as an article on the Bing search-engines 'visual' search capabilities.

Both of these approaches provide a visual representation of articles, with Fast Flips also categorising the content for easy navigation - this is not dissimilar to the innovative approach seen with the Cuil search-engine which aims to provide a 'magazine-style' presentation of results, complete with thumbnail images. Indeed the whole 'magazine-layout' approach to presenting content appears to be becoming increasingly popular.

An important quotes from one of the BBC articles is ...consumers can process results with images 20% faster than text only results. This could explain one of the underlying factors driving browsing habits toward increasingly visual representations - it also ties in with the whole Web 2.0 concepts of both data-aggregation and rich user-interfaces.

At the time of writing the Bing visual interface appears to be unavailable, so I cannot comment on specifics, other than to say that the approach sounds both interesting and exciting.

Google's Fast Flick service was operating, but currently appears to offer no obvious customisation options that allow registered users to tailor the content and/or layout (please post a comment if you are aware how to do this).

Consequently the content appears to be biased towards US interests at present. However, when you login a message appears stating that Fast Flip may use your email address to personalise your experience on their website, so presumably you need to start using the service in order for it to start making recommendations etc.

Having said that, this is still classed as a laboratory project so I'm sure these features will improve over time.

Browser-Related Statistics

2009-09-14T21:03:00.009+01:00

A colleague pointed me to the W3Schools Browser Statistics page recently, which I was completely unaware of.

A quick check shows some fascinating insights into past, present and future adoption of browsers and the operating-systems used to manage them. For instance we can see that Internet Explorer is rapidly losing market-share, with just 39.4% as at July this year, compared with 51.7% in 2008 and 57% in 2007.

Meanwhile both Firefox and Google's Chrome browser appear to making steady inroads, increasing their market share by between 5-7% - indeed, it would appear that Chrome is starting to gain real acceptance.

What did surprise me though, was the operating-system statistics (for those not in the know, browsers typically provide a User-Agent string as part of each HTTP header when connecting to a web-server - this allows the server to respond in the best possible manner to the client).

The operating-system statistics appear to show that Linux still has a very small market-share of only 4.3% (July) and this appears to have increased only slightly over recent years. Conversely, it would appear that Mac operating-systems are making good progress and apparently out-pacing Linux.

Be careful what you read though - I can think of many reasons for this apparent surprise; first it could be spot-on - perhaps Linux isn't making as much progress as its advocates would like to think...

However, it could also be that Linux is still regarded and used primarily as a server operating-system, often providing just a command-prompt for Systems Administrators (consider Ubunut Server Edition for example); as such users will never browse the Internet from a server - a bad practice in any event. Conversely, both Windows and Mac computers predominately host desktop operating-systems and are pre-shipped with browsers.

Another possibility is that Linux browser-implementations set the User-Agent string to some other operating-system in order to minimise compatibility issues. This is easily done and many browsers allow advanced users to change this setting so that servers will think the client is using some other browser.

I will be keeping on eye on these statistics in future - especially the trend towards Chrome. Like many others I tried it, liked it, then went back to the comfort zone (Firefox in my case).

There have been some very innovative approaches to browsers and browsing presented over the last year and it'll be interesting to see what dominates. The Flock browser is also worth a look and both the Cuil and Bing search-engines are gaining in popularity.

Agile Development - Efficiency Metric

2009-09-14T13:23:00.006+01:00

I read this article by Grant Joung recently and would suggest that the principles appear sensible and are worth trying.

We have been using User Stories Applied by Mike Cohn as a general guide to adopting an Agile approach to software development recently (a great book and starting reference that is easily digestible, by the way).

At present I am managing a small Agile project that is based on 2-week iterations with weekly progress meetings - so far things have been going well and I have created both Velocity and Burndown charts.

However, we recently had a public bank-holiday and some members of staff had taken a couple of days off, resulting in an slightly erratic Velocity charts and making it awkward for me to get a good handle on how well the team was performing.

Grant's suggestion is to create a new metric called Efficiency and then graph it:

 E = V/R

 E = Efficiency for the iteration
 V = Velocity for the iteration
 R = Total number of person days worked on the team for the Iteration

By tracking the number of man-days actually worked in a given iteration against the velocity achieved we were able to produce an Efficiency graph that was noticeably different to the Velocity graph - in our case it actually showed the team's efficiency decreasing slightly over time, while the velocity appeared to be gradually increasing!

This is actually an accurate refection of what is happening on our project - we are evaluating a new technology and the developers are getting slightly bogged down by some of the technical issues while at the initial stage of learning. I would expect our Efficiency chart to stabilise shortly and then start to gradually increase as our developer gain increased expertise with this new technology.

Also note Grant's suggestion about creating a 'benchmark velocity' to help predict future progress - it is too early for us to say if this works for us just yet, but the principle appears sound.

Cascading StyleSheets - Separation of Concerns

2009-09-13T22:54:00.010+01:00

I have been spending the last few days getting back up to speed on the use of Cascading Style Sheets (CSS).

This technology is closely related to HTML and essentially controls how a web page is displayed within a browser. Unfortunately CSS has traditionally been the poor relation to HTML, with many developers under-utilising it and mistakenly using HTML to control some (or all) of the rendering of a web page, such as using tables to manage layout, etc.

HTML and CSS demonstrate one of the most important design considerations of any software development project - "separation of concerns". Each technology has a distinct responsibility; HTML should only be used to structure the content on a web-page, while CSS should only be used to control the rendering of that page, formatting it into something that is visually acceptable and pleasing to the user.

This ensures that the content/structure of a web-page is independent from its presentation; by using cascading stylesheets the content can be formatted appropriately depending on the device - for example the way a page is displayed on a regular screen and browser (Firefox on a 1024x800 display, for example) can be completely different from the way the page is displayed on small PDA or iPhone screen by a less popular browser.

By relying entirely on CSS to control the rendering of a web-page, developers can also make their sites 'skinable'. In other words they can completely change the look/feel of a site simply by changing the styleshet referenced by the web-page - the page itself doesn't have a change at all. This is invaluable when faced with demanding clients who may not know what they want until the see it and it offers significant advantages for the maintenance of a site.

Websites should be designed first and foremost with structure in mind - consideration should be given to the order in which articles on a given page are presented, together with legal and accessibility considerations. Making this content look nice is a "separate concern" whose responsibility lies with cascading style-sheets.

I will discuss CSS in more depth in future posts, but for now the take-away message is "separation of concerns" - avoid using HTML to control the rendering of a web-page. This means that your HTML pages will look very basic and unappealing when viewed without an attached stylesheet, but this is a good thing - it means your page is accessible, skinnable and maintainable.