Grails, The Good and The Bad

As I’ve mentioned here before we’ve been using Grails to build the web front-end for Sierra as well as the Sierra REST API.  This week has provided a couple of great examples of the joys, and pains, of using open source software.  Let me start by saying that using Grails is mostly all joy, and not much pain.

While working on the administration console for Sierra this week I ran into a case where I needed to paginate a set of results.  Having built web applications for years now I have some pretty tried and true methods for doing this.  However, in the past while using other frameworks these methods have involved me writing a decent chunk of code.  With Grails that chunk of code is no longer needed.  Or, a least I don’t have to write it.  Let me show you a simple example.  Let’s say we have a “show” method on a UsersController that either fetches a single user (if we pass in an id), or returns a list of all users.  It might look something like this:

def show = {
    if (params.id && User.exists(params.id.toLong())) {
        def user = User.get(params.id)
        [user: user]
    } else {
        // default max num for the page to 10 if not specified
        if (!params.max) {
            params.max = 10
        }
        render view: "list", model: [userList: User.list(params)]
    }
}

Notice the call to “User.list(params)”.  This is passing in the URL parameter coming from the client into call to fetch the users.  If those parameters contain paging information then the list() method will fetch the proper subset of users.  I didn’t have to code the list() method.  Grails just gives it to me.

The last piece needed to get this working is a simple one line addition to your list.gsp file so that those URL parameters actually get passed in and the pagination controls get rendered.  That line looks like this:

<g:paginate controller="users" action="show" total="${User.count()}" />

That’s it! Done! We have pagination and it only took about 15 minutes (mostly spent reading documentation) where as it would have taken at least an hour had I coded it all myself (sorry, I’m slow).

Now for the “Bad”, or at least the not so pleasant.  I spent some time this week implementing a load balancing solution for the Sierra REST APIs.  While doing this I decided that I needed to externalize some of the Grails configuration.  When you create a Grails application your configuration normally lives in Config.groovy.  This is great to get started, but as your app matures you don’t want to have to recompile just to point at a new database, etc… Config.groovy gives you the ability to easily load external configuration files using a command like this:

grails.config.locations = ["classpath:${appName}-config.properties"]

If you do just this things work great, but I started thinking that I probably wanted things to work differently in my development environment than in my production environment in regards to loading external configuration.  Grails has thought about this desire and gives you the ability to define “environments” blocks within your Config.groovy.  I thought that using this along with loading external configuration would be the perfect combination.  Not so fast Jared.  It turns out that these two features don’t play nicely together.  I think this is a bug, or simple stupidity on my part.  I’m open to either option.  Using Grails 1.1.1 if you put a “grails.config.locations” definition inside of an “environments” block the external configuration will not be loaded.  I’ve logged the bug with the Grails folks here.

I wonder fun next week will hold?

Tags: bugs, grails, REST, SaffronSierra

This entry was posted on Monday, September 21st, 2009 at 9:36 am and is filed under SaffronSierra. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.