Setting up Grails directories to NOT use default user home folder

I have my user home folder at work mapped to a network drive. It is incredibly slow. Unfortunately many applications use home folder as the default dumping ground. The same applies to Grails. It puts it’s cached files, ivy dependencies and who knows what else in there.

It is not a straight forward to change that location and to be honest, not very well documented.

Anyway, here is the best possible solution I managed to find on my Windows box:

  • in folder : %USER_HOME_FOLDER%/.grails create file called settings.groovy
  • in settings.groovy file add line: grails.dependency.cache.dir= “path/you/want” – this is for the Ivy downloaded cache dependencies
  • in settings.groovy file add line: grails.work.dir=”another/path”
  • a system variable called: GRAILS_AGENT_CACHE_DIR to another location you would like.

These settings made Grails stay away from my mapped network home folder.

Greg

Post-Redirect-Get pattern with Grails

In this post I would like to share with you a very common pattern used in web application development and how I implemented the pattern in my Grails application. Let’s start with a simple explanation of the pattern and what is it useful for.

Post-Redirect-Get

Post-Redirect-Get refers to the flow or process that web applications follow. When user submits the form in the browser the information is typically send with HTTP POST method to a web server. Application processes the information and sends back the response. Response is sent in a form of redirect to another view. Browser loads new state from web server using GET method.

Post-Redirect-Get pattern

Some of the benefits of using this patterns are:

  • Pressing refresh button in the browser will not cause duplicate form submission. The most annoying dialog box asking you if you want to resubmit your form will be gone.
  • Bookmarking result page would be possible.
  • Pages with forms submissions will be gone from your browser history.
  • Nice and clean separation of the HTTP methods that change state of an object (POST, UPDATE, DELETE) from non-destructive, read-only methods (GET).
  • Easier to test response, as all you need to check is the redirection. Typically when form is submitted successfully it will redirect to different page then failed submission. To test the behavior it is enough to test the redirection.

With the pattern in mind and the benefits let us try to look at the concrete FooBar example.

Grails example

I assume you know what Grails is. I’ve created a project and created domain object called Foo. The only property it has is a String, Bar that cannot be blank.

package post.redirect.pattern
class Foo {
  String bar
  static constraints = {
    bar blank: false
  }
}

Foo controller with two methods responsible for creation of new object.

class FooController {
…
def create() {
  def instance = new Foo(params)
  if (flash.model){
    instance = flash.model
  }
  [fooInstance: instance]
}
def save() {
  def fooInstance = new Foo(params)
  if (!fooInstance.save(flush: true)) {
    flash.model = fooInstance
    redirect(action: "create")
    return
  }
  flash.message = "Hooray, you did it!"
  redirect(action: "show", id: fooInstance.id)
}
…
}

When user submits the form and the object is invalid, the browser is redirected back to the form instead of rendering the form with error messages.

There is an extra check to see if user arrived on this page after unsuccessful form submission.

I used flash to store invalid object between pages, so the user could get feedback on what is wrong with provided values.

If you want to try on another example, the easiest way is to create a domain class and generate the scaffolding for it. You can try the browser behavior on generated code.Try refreshing the page after form submission (valid and invalid), try to navigate between pages using Back and Forwards buttons of your browser, try to bookmark the submitted page.

Later, go and modify the code, replace renders with redirects and see browser behavior after that.

Summary

This is all there is to it. It’s rather simple and easy to follow pattern with number of benefits. Grails makes it a doodle to implements,. Have fun redirecting.

Greg

Unit testing Grails controllers with duplicate form submission check functionality

I’ve been doing some Grail 2.0.1 development recently. I like the maturity of framework and the ease of doing things.

One of the things Grails comes with is a simple way of avoiding duplicate form submission. Have a look at the code bellow:

def myControllerMethod(){
  withForm{
    render “theGoodStuff”
  } .invalidToken {
    render “theBadStuff”
  }
}

That’s the controller bit. In your view you need to enable use of that feature by passing useToken parameter to form tag:

<g:form action=”myControllerMethod” useToken=”true”></g:form>

It looks very simple and elegant. However when we would like to test the controller we need to make sure we match the token when calling the method.

Documentation on testing Grails application and this particular functionality contains the way of doing so, however I found it not working with Grails 2.0.1.  Not much was blogged about it so I looked through the mailing lists. I found one trail and a bug report for this issue.

Anyway, to make it work, the piece of documentation from Grails, version 1.4.x explains how to do it, and it works.

In controller test method we need to place this code:

…
def token = SynchronizerTokensHolder.store(session)
params[SynchronizerTokensHolder.TOKEN_URI] = '/myController/myControllerMethod’
params[SynchronizerTokensHolder.TOKEN_KEY] = token.generateToken(params[SynchronizerTokensHolder.TOKEN_URI])

controller.myControllerMethod()
…

Happy testing. Greg

Useful links:

http://grails.1312388.n4.nabble.com/grails-2-0-testing-controller-with-withForm-invalid-notation-td4316150.html
http://jira.grails.org/browse/GRAILS-8504
http://grails.org/doc/1.4.x/guide/9.%20Testing.html
http://grails.org