Grails pageScope variable in GSPs and TagLibraries

June 22, 2010 – 3:55 pm

Grails pageScope variable is available to you in Tag Libraries and GSPs and contains a wealth of state information. For instance, you can set an attribute in the model in a controller and then reference it in a TagLibrary through the pageScope variable without having to pass it through the tag attributes

Controller:

def myAction = {
    //...
    boolean readOnly = true
    render(view: 'edit', model: [bookInstance:book, readOnly:readOnly])
}

GSP:

    <g:myInputFieldTag name="title" value="${bookInstance.title}"/>

TagLibrary

def myInputFieldTag = { attrs->
    if (pageScope.readOnly){
        out << attrs.value
    } else {
        out << //...
    }
}

You can also use it within a GSP or to get access to variables you have set in a GSP or to store variables in page scope in a tag library.
Docs:
http://grails.org/doc/latest/ref/Tag%20Libraries/pageScope.html
and
http://grails.org/1.0-RC1+Release+Notes#Improved%20support%20for%20scopes

Grails Dependency Management – Setting the Ivy Proxy

June 18, 2010 – 11:07 am

When dealing with corporate firewalls and proxy servers, dependency management can be a pain. With Grails 1.3.1 I recently encountered an issue resolving dependencies that were not in a maven central repository. I had already done ‘grails set-proxy’ and that seemed to do the trick for the majority of the dependencies I needed, but these few turned out to be very elusive.

After some quick searching, I stumbled across a way to set the Ivy proxy through the ANT_OPTS environment variable. That didn’t do the trick, but passing those parameters to grails directly DID.

If you’re running Grails from the command line, you can do the following:

grails -Dhttp.proxyHost=your.proxyserver.com -Dhttp.proxyPort=80 clean

If you’re using Hudson (as I was), you can add two additional lines into the “Properties” box of your “Build with Grails” configuration

http.proxyHost=your.proxyserver.com
http.proxyPort=80 clean

Grails Dependency Management – Excluding dependencies

May 28, 2010 – 9:36 am

Sometimes you need finer control over the dependencies included in your build. In BuildConfig.groovy you can exclude dependent dependencies by using the ‘excludes’ keyword – for example:

dependencies {
        runtime (group:'org.apache.tika', name:'tika-parsers', version:'0.7'){
            excludes 'commons-compress'
        }
}

Building Grails Apps with SVN and Hudson and fighting with application.properties

January 27, 2010 – 5:24 pm

It’s incredibly easy to set up a Hudson project to build a Grails application with the available Grails plugin for Hudson.  Every once in a while, however, there’s a little problem that’s been nagging me – merge conflicts within that pesky little application.properties file.

There are several things that cause application.properties to get re-written by Grails, the most common of which for me is installing / uninstalling plugins.  Since this is a properties file, the order of the lines is unimportant (they’re just key value pairs, after all), until your build machine does an ’svn up’ and encounters all sorts of conflicts that can’t be resolved automagically.hudsonUseUpdate

There are two (well, OK, three) ways to workaround this:

  1. Tell hudson do to a clean checkout with each build.  To do this just make sure the “Use update” box is NOT checked under the subversion modules section of your build configuration.  This works well if your project is relatively small and you have a fast connection to your source code repository.
  2. Revert the application.properties file before the build happens.
  3. Stop using SVN.  Well, I don’t actually know if other SCMs handle this better, but it wouldn’t surprise me.  I certainly know of a few that handle it worse!

For the most part I’ve been using option #1 – until I recently added a very large project to the Hudson build…  The build time more than doubled – and that’s just unacceptable.

Enter Option #2.  In your build configuration, add an “Execute Shell” Build Step that happens BEFORE your Grails build that reverts the file so that the workspace always has the latest and greatest – without conflicts.

buildStep

Note that depending on how your checkout works, you may need to add the checkout path in front of application.properties, for example:

svn revert yourGrailsApp/application.properties

If there’s a better way, I’d love to hear it.  In the mean time, this extra little build step works great!

One week with WhenWorksForYou.com

July 13, 2009 – 5:25 am

Last week I launched http://www.whenworksforyou.com, a new Grails website that lets you coordinate schedules with other people to find the best date for your next event. Our first week provided lots of great feedback from users. One of the biggest gripes was not being able to subscribe to updates on an event. Well, thanks to the feeds and mail plugins, now you can! It was dead simple to implement, and now I can focus my attention on the next feature rather than having to re-invent the wheel on RSS and email.

The site also takes advantage of several other plugins, including

Thanks to all the plugin developers who took the time to build and document plugins for the Grails framework!

I also wrote one other plugin that wraps GreenMail and acts as a transient “Inbox” for sending emails during development. I’m putting the finishing touches on that now, stay tuned for more information.