Groovy

Grails Goodness: Change Version For Dependency Defined By BOM

Posted on by  
Hubert Klein Ikkink

Since Grails 3 we use Gradle as the build system. This means we also use Gradle to define dependencies we need. The default Gradle build file that is created when we create a new Grails application contains the Gradle dependency management plugin via the Gradle Grails plugin. With the dependency management plugin we can import a Maven Bill Of Materials (BOM) file. And that is exactly what Grails does by importing a BOM with Grails dependencies. A lot of the versions of these dependencies can be overridden via Gradle project properties.

To get the list of version properties we write a simple Gradle task to print out the values:

Continue reading →

Groovy @CompileStatic vs. Grails new @GrailsCompileStatic

Posted on by  
Albert van Veen

Grails is built on Groovy which is known as a dynamic language. The dynamic nature of Groovy offers a lot of powerful features but also defers the detection of errors from compile time to runtime. To shorten the feedback cycle for your code Groovy has a handy annotation which will make sure that your classes is are statically compiled. This will give you fast feedback for a lot of mistakes and you also will benefit from the increased performance offered by the static complication. Unfortunately in Grails this annotation prevents you from using the very useful dynamic GORM methods like list(), get() and the dynamic finder methods. Groovy does not recognize these Grails methods during compile time; see the example below.

@CompileStatic
class BookController(){

     def save(){
       //This will successfully compile
    }

    def get(){
       Book.findByName(params.name)
       //this will throw a compile error since the findByName method is not known
       //at compile time
    }

    @CompileStatic(TypeCheckingMode.SKIP)
    def delete(){
       //by setting the TypeCheckinMode, this method will be skipped
    }
}

Continue reading →

Grails Goodness: Unit Testing Render Templates from Controller

Posted on by  
Hubert Klein Ikkink

In a previous blog post we learned how we can unit test a template or view independently. But what if we want to unit test a controller that uses the render() method and a template with the template key instead of a view? Normally the view and model are stored in the modelAndView property of the response. We can even use shortcuts in our test code like view and model to check the result. But a render() method invocation with a template key will simply execute the template (also in test code) and the result is put in the response. With the text property of the response we can check the result.

In the following sample controller we use the header template and pass a username model property to render output.

Continue reading →

shadow-left