What is obvious to one person often is not to others. For the GR8 conference, it is necessary to have a separate home page by region, as well as having a default home page when no region is specified. All of these are database driven. So, I created a HomeController and created two views: index and show. The index view is the default page and will show information for all conferences. The show view will show specific data for each of the GR8 conferences. I knew I would have to use URL mappings, but I am the type of person who does not read the assembly directions when he brings home the box from Home Depot. Handling the default view was very simple and only required the mapping:

"/"(controller:'home', action:'index')

My first thought about handling the region specific mappings was not nearly as successful. It was my thought to take the default controller/action/id mapping:

"/$controller/$action?/$id?"()

and add a closure wherein I test the controller value to see if it happened to be one of the region codes. One of my iterations looked like this:

"/$controller/$action?/$id?" {
    if ('$controller' == 'us') {
        controller = 'home'
        region= '$action'
        action = 'show'
    }
    else {
        "/$controller/$action?/$id?"()
    }
}

This didn't work too well and I quickly abandoned this path. I thought I might be relegated to statically defining the region mappings like so:

"/us" {
    region = 'us'
    controller = 'home'
    action = 'show'
}

Well, this will work, but I wanted something more dynamic. I didn't want to have to repeat the above block for each region, let alone for each variation of upper and lower case letters. Note, though, that an arbitrary variable, region, was set here. This is a nice thing to remember. Arbitrary variables are available as part of the params. So, I changed the block of code above to:

"/$region" {
    controller = 'home'
    action = 'show'
}

This worked great for mapping the various regions, but it has a glaring weaknesses. It overrode the default controller/action/id mapping when only a controller was specified in the URL. The controller name would be interpreted as a region, the request would be processed by the HomeController, the region looked up and not found and end up being redirected to the index view. Enter constraints. By adding constraints to the above, the region mapping is only triggered when the constraints are true.

"/$region" {
    controller = 'home'
    action = 'show'
    constraints {
        region matches: /(U|u)(S|s)|(E|e)(U|u)|(A|a)(U|u)/
    }
}

The only drawback to this is that if we ever want to add or change a region code, the pattern will have to be changed. Since this is something that should only change infrequently, it is a small price to pay. The pattern allows any combination of upper or lowercase letters for any of the three region codes: US, EU, and AU.

There is one more caveat, and that is a design choice I made and others may not. If some Grails smartypants thinks he will trick the system by entering the URL path /home/show thinking that he will cause problems will be redirected to the default home. Similarly, entering path /home/eu will get a page not found view. I don't care to try to handle these. People that behave will never have these issues.

Great stuff! Now to upgrade all my projects. This, along with the Groovy 1.6 upgrade sure is a great one-two punch!

In my previous post, I spoke of having forgotten to change the test environment settings when I configured for SQL Server 2005. There really was another solution. The out of the box definition of DataSource.groovy defines the driverClassName, username and password in the outermost dataSource closure. Any or all of these attributes can be moved into the various environment dataSource closures. By doing this, you can have different logins/passwords per environment, or even have different databases, if you wish (though I cannot imagine why you would want your database to differ across environments).

This was a relatively simple task to do, though I ran into one gotcha (mainly because I was not paying attention). Here are the steps followed:

1) Created database MyDb using MS SQL Server Management Studio Express

2) Added user MyUser and defined a password. Roles were specified as: db_datareader, db_datawriter, db_ddladmin. The first two allow reading and updating of data. The last allows creation of tables and other DDL commands.

3) Downloaded jdbc driver. http://www.microsoft.com/downloads/details.aspx?FamilyId=C47053EB-3B64-4794-950D-81E1EC91C1BA&displaylang=en

4) After executing the archive and extracting to the drive, copy sqljdbc.jar to [APPLICATION_HOME]/lib.

Changed [APPLICATION_HOME]/grails-app/conf/DataSource.groovy as follows:

1) Set dataSource pooled to false

2) Set dataSource driverClassName to "com.microsoft.sqlserver.jdbc.SQLServerDriver"

3) Set dataSource username

4) Set dataSource password

5) Set environments.development.dataSource dbCreate to "update"

6) Set environments.development.dataSource url to "jdbc:sqlserver://localhost:5356;DatabaseName=MyDb"

The port in the url defaults to 1433. I am using a non-standard port number.

I created a domain with no implementation and defined an integration test. Here is the gotcha. When I ran the integration test, it dumped for not being able to find a suitable driver. I had only changed the development dataSource in DataSource.groovy. Once I updated the test dataSource, the tests ran properly.