Monthly Archives: März 2009

Book Review: The Definitive Guide to Grails, 2nd edition

The Definitive Guide to Grails is an introductory book to the Grails web application framework. Being an introductory book does not mean that it is only suitable for Grails beginners. Even for more experienced Grails users this book is an invaluable resource. It is written by Grails project lead Graeme Rocher and contributor Jeff Brown, who are both with SpringSource.

The first few chapters (1-7) are dedicated to explaining the basic concepts of Grails: Controllers, Views, Domain Models, Internationalization. Even tough advanced users could easily skip them, they should really skim these chapters as they not only recapture the essentials of Grails in a very intuitive manner but also reveal new insights on how to approach certain classes of problems.

Starting with chapter 8, the subjects become more advanced, covering Ajax, Spring WebFlow, Security and Web Services. Other interesting chapters include GORM, mapping legacy databases with Hibernate and Plugins. The GORM chapter, for example, does an outstanding job explaining potential pitfalls when working with Grails‘ domain layer. The chapter on ‚Integrating Grails‘ explains how configuration and the command line system works which allows you to extend and customize the Grails build system – e.g., building a script to deploy the application directly to Tomcat. Another invaluable chapter introduces the reader to Grails‘ underpinnings, namely the Spring framework. This is by far not a complete introduction to Spring but it gives just enough knowledge to understand what’s going on under the hood and to leverage these internals in own projects or plugins.

Testing support is promoted to be one selling point for Grails but surprisingly, no chapter is dedicated to this topic. This however does not Western union locations mean that testing is not discussed at all. Rather, throughout the construction of the store example, aspects of testing the respective artifacts such as controllers, tag libraries, services etc. are explained. This is certainly a natural way of introducing the topic but makes it somewhat harder to use the book as a reference for Grails‘ testing mechanism.

To summarize, The Definitve Guide to Grails is a good introductory book with the potential to serve as a reference in addition to the official Grails documentation.

Some Lessons Learned from our First Grails Project

After we have discussed the main benefits and praises of Grails in the previous blog posts, let’s now have a look various lessons we have learned so far:

  • The domain-driven approach for database schema generation is fine for development purposes but as soon we go to production mode, we don’t want any automatic updates to happen to our database schemas – even with the liquibase or autobase plugins. We are still investigating on how to solve this problem but for the moment being, we just work with plain SQL migration files which update the schema from one version to the next.
  • Scaffolding is great but use it with care. Especially, before you start generating your controllers and views, be sure to customize the generation templates according to your needs. Otherwise, you will spend a lot of time tweaking the generated views or controllers to your needs. Of course you can regenerate them, but any changes you might have made to the views and controllers may get lost.
  • Updating from one Grails version to the next is straightforward, just run grails upgrade. However, it seems that this will overwrite certain files. We saw it happen to the main index.gsp and ivy.xml. In a toy application, it also seemed to have happened to and UrlMappings.groovy but we did not attempt to reproduce that. The takeaway message here is to always use a version control system and commit your latest changes before upgrading to the most recent Grails version.
  • We think the user guide is excellent and we could solve most of our problems with (re-)reading the appropriate section. Also, if you work with the latest betas and RCs, be sure to browse the detailed change logs for each release as this gives you the feeling which issues have been fixed and which issues remain.
  • The community is pretty strong. The blogosphere is buzzing at full steam, producing several interesting blog entries per day. It’s recommended to subscribe to the blog aggregator to stay up to date. Blog posts are great resources, and occasionally reading them will allow you to learn „along the way“. Also the mailing list archives contain tons of useful information and, last but not least, the bug tracker will keep you informed about current issues and possible workarounds.

We have learned quite a lot in our first project but we’re not finished yet. Some of the things need to investigate further might be the following:

  • Database migrations, as mentioned previously.
  • Continuous Integration with Hudson.
  • Creating and maintaining a private plugin repository. This is necessary to share common code parts between different applications without releasing them to the public (because we simply cannot opensource all of our code). Using a repository also eliminates manual installation of custom plugins which anyways gets in the way since Grails 1.1 automatically resolves plugin dependencies. Sadly, the user guide does not go into details about creating and maintaining plugin repositories.

Final remarks.
If you ask both of our developers if it was easy to pick up Grails, both will answer with an enthusiastic yes! Sure, you will be a bit unproductive at the beginning, but as you get along with experimenting and reading the excellent documentation your speed will increase. In the end, we are glad we have chosen Grails for this project because it has allowed us to quickly deliver initial results to the customer and we would not have been nearly as productive with the Struts framework which we use for

Modeling Domains in Grails

After we have discussed several aspects of the Grails framework in our previous blog post, it is now time to say a few words about domain modeling.

In Grails, the domain model is the skeleton of the application, as in all the other languages, but in case of Grails, there’s even more emphasis on that. Your POJOs (here POGOs) take place in the domain folder, and will immediately give the definition of the database layer: all table will be generated based on them. You have to define here the relation between classes with static mappings. Some years ago everyone (sorry for those who did not) started the design of an application with the schema, the n:m, n:1, relations, struggling for hours, spending days to achieve the optimal database model, and then one could start the domain model. If you use Grails, the story ends here because the framework takes care of defining the Hibernate mappings based on the domain class definition. So, no more manual mapping of your domain objects to the database schema – which is of course still possible if you need to work with a legacy database schema. This is a nice thing since we can really concentrate on the domain and business logic.

Whats also very useful is the ability to define constraints on the domain, right inside the class where they belong to: just define static constraints. Grails has some predefined constraints like credit card numbers, email addresses and URLs, length of fields, etc., which are the most necessary ones in an average application) but one can create custom validators as well. Our application has a slightly complex domain model and we think the validators are quite handy. Any change can be accomplished without rewriting large parts of the program.

All these convenience features have saved us a lot of time on the database definition and the dynamic finder methods have saved a lot of time in providing Create-Retrieve-Update-Delete facilities. This has proven to be essential, because as we all know, the only constant is ‚change‘ – not only change in technology but mainly in requirements. Nowadays most of the complexity comes from the special requirements, complicated domains, and not from the technical side.

Our current project is a perfect example here: its concept is far more complicated than the technical issues. To handle this complexity we still need an extensive set of design practices, techniques and principles, an approach, a way of thinking like domain driven design. Also we should test our domain model with simple unit tests. Grails pushes us to this way, since at the time of the domain class creation, it also generates us a unit test for that class. As a generally accepted principle we always suggest to follow test driven development. In this project we try to follow these techniques, although we have a stronger rule that sometimes overwrites the others, called common sense…

A First Grails Project

It has been almost a year since we got Grails on our Radar for the first time. After playing around with the framework for a while we decided to evaluate it in more depth. After we’ve been busy with for
a long time, we recently decided to implement a small application for one of our customers in Grails to get some hands-on experience outside a pure lab setting.

While we’ve not finished it yet, we can already share some experiences with it.

Project setting

The application is a rather small but still fairly complex project. It will allow our customer to upload an input file and to perform some quite sophisticated analysis on the input data. He can then compose the final report which can be downloaded again. Because this is an internal application, we cannot currently give more details about it.

There are mainly two developers working on the project, one full-time and one part-time employee, none of them had real Grails experience: the first one had never worked with Grails while the second one had made a very simple toy project and had studied the documentation as well as followed the blogosphere quite a bit.

Since we started the project in late January, with the Grails 1.1 release expected for Q1/2009, we decided to start development on Grails 1.1-beta1 and have successfully upgraded to almost each intermediate beta or release candidate. There were very
few bugs that turned out to be show stoppers for us and we are still impressed by the amount of improvements and bug-fixes that make it into each release.


Grails is fairly easy to pick up, if you have some Java and web application experience. The main language used to create the applications is Groovy ( which is very close to Java and therefore is very easy to learn. It has some nice syntactic sugar that simplifies development quite a bit. The rest of our experiences can be summarized as follows:

  • Views and Layout: Grails uses Sitemesh as its view component. Sitemesh applies a decorator philosophy to the views. You can think of it as a reverse include: it’s not the layout file that indicates which content will be included but it’s the content file which
    determines in which layout it will be embedded. The views are located per convention and are automatically resolved for the respective controller and action. This means that there’s almost no configuration necessary which is certainly a big plus over Struts tiles which requires quite a lot configuration work. Groovy Server Pages, or GSP, is the Groovy counterpart to JSP. We found it easier and more flexible to work with than JSP. GSP comes with a ton of useful predefined tags and it is very easy to build own tag libraries as needed (but don’t call your TagLib call it FormTagLib because this will interfere with the builtin form tag).
  • Controllers: with respect to controllers, Grails follows a very Rails-like approach. Assume you have a controller named UserController with an action named login, then this action will be accessible under /appname/user/login. No configuration there. If you come from Struts 1 development, you know what a relief this is because there you will wire each and every action in struts-config.xml. But still, if the Grails default schema won’t fit to your needs, you can easily define custom URL mappings.
  • Deployment: there is no need to set up a complex build system. Just type grails war and a production-ready .war file will be built. If you need to configure several environments with different settings for the database and so on, this is also no problem. However, we still need to investigate on how to set up a more automated build process which can automatically tag releases in our repository as we currently can do with our Maven-based build process for
  • Running on your development machine: Here Grails wins completely over other frameworks which will need a relatively complex server and IDE setup. For example, to run our application on a development machine, you must install a Tomcat instance, configure the Eclipse IDE with the correct plugin and JVM parameters and so on. If you are lucky, you are ready to start after 20 minutes but it can also take significantly longer. In contrast to this, we can get our Grails-based application up and running on any development machine in approximately five minutes. Assuming that Grails is installed on the machine, just check the project out from the repository and type grails run-app. Thanks to the Ivy plugin the required dependencies will be installed automatically and in Grails 1.1, also the Grails plugins will be resolved automatically. That’s really a big timesaver!