Tuesday, 25 May 2010


We have been using the grails web framework for some time now. Our use of grails is however not very mainstream.

Our applications are typically composed of a number of REST based web services that are consumed by the website. This means that the website has no persistence requirements as that is all handled by the web services.

We are therefore not using GORM at all, which is an area of grails that brings great productivity boosts. Added to that many of the plugins available for grails assume persistence is available.

We really like the idea of composing web applications using plugins and can see grails making good advances in this area, particularly in 1.2. We also love GSP and the ease by which tags can be created and of course Groovy.

Based on our experiences and the fact that the next core grails release is likely to be Q2 2011, we are now investigating what it would take to produce a system which is tailored to our style of development using backend REST services.

Part of this is looking at how the whole process of dispatching requests works and the possibility of including this in a Groovy DSL. Something along these lines:

.execute {
model.dashboard = adminService.dashboard
"admin.dashboard" // return the view name
.onServiceNotAvailableException {

This gets all the information that is relevant to the processing of a request in one place. With spring applications, and even grails, when you are working on a single controller, there can be quite a lot of jumping around between files, this avoids that.

As long as the inline closures in the DSL do not get too big this will present most of the relevant information in 1 file. I don't think the code will be too big - (you don't put logic in your controllers do you?)

As well as supporting basic mappings to controllers, we could also support pattern based matches such as /admin/user/edit/{id}. The named parts would be made available to the closures in the same way that grails / spring does.

Supporting wildcards would allow us to apply some features to groups of urls. e.g.


Another requirement we often have is to change URLs for some content. Typically this would be handled by a 301 redirect using mod_rewrite. We could support this in the DSL. e.g.


It is still very early days, but once we have any code, we will be putting it up on github. Stay tuned..