• Home
  • Blog
  • Wiki
  • Projects
  • Contact Us






When should we use the Grails flash ?

June 13th, 2010 By admin

Recently one of my clients asked me when it was appropriate to use the Grails flash for storage. I mumbled something about how you should use it when you needed to store some information that lives beyond the current request, but only as long as the next request. But I couldn’t provide him with a compelling use case to illustrate when the flash becomes really useful.  I promised to answer his question, and I figured that while doing so I’d make a blog post out if it.

So here’s the use case.  Say you have a book store app, which lists books for sale, and enables administrators to add books. Your BookController would likely support the following (psuedocoded) actions :

def list = {
    [ booklist: Books.list() ]
}

def saveBook = {

    Book b = Book(params)

    if (b.save())  {
        flash.messge = "Added new book to catalog: ${b.title}"
        redirect (action: list)
    } else {
        ....
    }
}

In the above psuedocode we assume that the saveBook action will be called when your users fill out a form with the new Book attributes, and select ‘Submit’. If the save is successful, then the flash is set as confirmation. However, this happens during the server’s processing of the browser request to the URI /yourApp/book/saveBook (in the saveBook action.)  Note that at the end of the saveBook action a redirect is issued to the browser, which causes the browser to issue a new request to your application at the URI /yourApp/book/list. If you had saved the confirmation message in a request attribute, that setting would be long gone by the time a user’s browser received the redirect (301) directive. But you cleverly used the the flash. As a result, Grails uses a trick (maybe saving the message as a session attribute and resetting it on the next request….? I’m not sure about this) to ensure that the flash message hangs around until the next request, and the next request only.

So what is the next request? Well, as the redirect suggests, it is a request that is satisfied by the ‘list’ action.  The list action simply populates the booklist model item with the list of Books to display and  renders the view  grails-app/views/book/list.gsp. A typical thing to include in such a .gsp is something like this:

[html]

 ...

 [div class="body"]
            [g:if test="${flash.message}"]
                [div class="message"]${flash.message}[/div]
            [/g:if]
            [div class="list"]
                [table]
                    [thead]
                        [tr]
                            [g:sortableColumn property="id" title="Title"...
                        [/tr]
                    [/thead]
                    [tbody]
                    [g:each in="${bookList}" status="i" var="bookInstance"]

                            ....

If you have a look at the g:if test=”… after the first div, you will see it references the flash message. When the gsp is rendered it will display the flash message “Added new book…” that was set in the previous request. This is quite handy. Of course you could provide this facility yourself… perhaps with a session attribute as I suggested above. But why bother when this is one of the many things Grails does for you ?

Share:
  • Digg
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • blogmarks
  • description
  • Furl
  • LinkedIn
  • Live
  • MySpace
  • Netvibes
  • Netvouz
  • NewsVine
  • Ping.fm
  • Pownce
  • Reddit
  • StumbleUpon
  • Technorati
  • Tumblr
  • TwitThis
  • Yahoo! Buzz
  • YahooMyWeb

Posted in Grails | No Comments »




No Responses to “When should we use the Grails flash ?”

Leave a Reply

  • Categories

    • Build Automation
      • Maven
    • Development Environment Tricks
      • Cygwin
    • Dynamic Languages
      • Groovy
        • Grails
    • Java
    • JQuery
    • Test Automation
      • Selenium
    • Uncategorized

  • Archives

    • June 2010
    • March 2010
    • January 2010
    • December 2009
    • November 2009
    • October 2009
    • September 2009
    • July 2009
    • June 2009
    • May 2009
    • April 2009
    • March 2009
  • Meta

    • Log in
    • RSS
    • Comments RSS
    • Valid XHTML
    • XFN
    • WP