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

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


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.

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.

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!

The site also takes advantage of several other plugins, including

• Spring Security
• UI Performance
• Recaptcha
• Build Test Data
• Test Code Coverage (of course)

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.