Matthew Woodward // * CFML, Grails, and Java Developer
* Principal IT Specialist, US Senate
* Open BlueDragon Steering Committee Member
* All-Around Geek

The March edition of GroovyMag is available and includes an article I wrote entitled "Grails for Switchers," which is my account of what I learned while first learning Grails.
If you're at all interested in Groovy or Grails you need to subscribe to GroovyMag. It's a great way to learn more about Groovy and Grails and keep up with what's going on in the Groovy/Grails community.
grails install-plugin grails-uiNext, on any view page on which you wish to use any Grails UI resources, you have to indicate which resources you're going to use on the page. The nice thing about this is it will only load the JavaScript for the specific UI resources you need on each page. In the case of this example I'm only using a dialog box, so I have this line in the head section of my view page:
<gui:resources components="dialog" />Also in my head section I need to tell Grails I'll be using some AJAX on this page, so I use the javascript tag to load the Prototype library:
<g:javascript library="prototype" />With Protoype loaded, pulling the contact details to be shown in the dialog box is dead simple using the Grails remoteLink tag:
<g:remoteLink controller="person"
action="showDetail"
id="${person.id}"
update="personDiv"
onComplete="showPersonDialog();">${person}</g:remoteLink>
If you're not familiar with Grails, what this does is tells Grails to make an AJAX call to the person controller, call the action showDetail, and pass the ID of the person object. We'll see what's returned by the AJAX call in a moment. The update attribute of the remoteLink tag tells Grails what DOM object to update with the results of the AJAX call, and the onComplete attribute indicates a JavaScript function to call when the AJAX call is complete. If all I was doing was updating a DIV on the page I wouldn't need this, but since I need to show the Grails UI dialog box after I pull the contact details, I need a JavaScript function to handle that, so I added this to the head section of the view page:
<script type="text/javascript">
function showPersonDialog() {
GRAILSUI.personDialog.show();
}
</script>
Next, let's check out the showDetail action in my Person controller to see what it's doing when the AJAX call is made:
def showDetail = {
def personInstance = Person.get(params.id)
if (!personInstance) {
def message = "No person found with ID ${params.id}"
render(view:"personDetail", model: [message : message])
} else {
render(view:"personDetail", model: [personInstance : personInstance])
}
}
Here's the simple view that's rendered in the controller action above:
<g:if test="${message}">
<p>${message}</p>
</g:if>
<g:if test="${personInstance}">
<p>
<strong>${personInstance.firstName} ${personInstance.lastName}</strong><br />
${personInstance.email}<br />
Phone: ${personInstance.phone}<br />
Cell: ${personInstance.cell}
</p>
</g:if>
And finally, here's the code for the Grails UI dialog box and the DIV that is populated with the view above:<div class="yui-skin-sam"> <gui:dialog id="personDialog" width="400px" title="Contact Details" draggable="true" update="personDiv" modal="true"> <div id="personDiv"></div> </gui:dialog> </div>This is all pretty straight-forward. What was happening, however, is when the dialog box was shown, there was no CSS being applied to it. The YUI components that are used by the Grails UI plugin have stylesheets associated with them, but when I checked the source code of the rendered page they seemed to be getting included just fine, and as you can see above I wrapped the dialog box in a div with the correct CSS class, which is yui-skin-sam. At this point it's important to remember that when a Grails page is rendered it uses SiteMesh, which is basically a templating/page decoration framework. As many Grails applications do, I was using a main.gsp layout page, and each individual view page gets woven into this main template. Therein lies the problem. As I said above this was simple enough in the end but since it took me a while to figure out I thought I'd share. Even though the YUI CSS was being included in the individual view page with the dialog box code on it, for some reason the CSS wasn't getting applied. I decided to experiment and put the yui-skin-sam class in the body tag in my main.gsp layout page, and this solved the problem. In my case I didn't have any conflicting CSS involved so this solution didn't cause any issues, but if you have other CSS involved and applying a class to the body tag in the main layout page will cause issues, you can add the additional CSS references after the <g:layoutHead /> tag in the main layout page, and this will allow you to override any CSS that came earlier. With all this in place the Grails UI components are being styled correctly and they're extremely nice additions to any Grails app.
Wednesday, Feb 10, 2010Free Webinar: Getting Started with Groovy, Grails, and MySQL (February 18, 2010)
On February 18, 2010, join Scott Davis on a Sun/Oracle sponsored webinar: Getting Started with Groovy, Grails, and MySQL. We'll spend some time working with MySQL from Groovy 1.7 scripts (Sql.eachRow(), Sql.withBatch()). Then we'll switch gears and show you how easy it is to skin a MySQL database with Grails 1.2. Hope to see you there!
If you're interested in Grails this would be a great one to attend. Scott's a great presenter!
Grails is a Java- and Groovy-based web framework that is built for speed. First-time developers are amazed at how quickly you can get a page-centric MVC web site up and running thanks to the scaffolding and convention over configuration that Grails provides. Advanced web developers are often pleasantly surprised at how easy it is to leverage their existing Spring and Hibernate experience.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, Tropicana, and Taco Bell are all using Grails. Are you ready to get started as well?
The second edition of "Getting Started with Grails" in now available for free on InfoQ, or you can buy the print version for only $22.95. The first edition was great so I'm really looking forward to reading the update.
In one of our Grails applications we had to run a number of batch jobs. Nothing unusual and Grails supports it quite well with the excellent Quartz plugin.
But when we deployed application in production, we noticed that after running for some time, it consumed a lot of memory and JVM was spending all the time running garbage collection. The reason for it was that our jobs were quite long-running, taking several hours to complete, and Grails wasn’t really designed for such kind of use case.
But "not designed for" doesn't mean it's not possible, of course. Great info about how to clear out some of the things that will eat up memory over time in long-running Grails processes.
Presenter: Jeff Brown, SpringSource
Code Demo
Q&A
Presenter: Dave Klein
Custom Tags are Valuable
JSP Custom Tags are Painful
The Power of JSP Without the Pain
GSP: A Quick-Start Guide
What you can do in a GSP tag
Implicit Objects in a GSP Tag
Example Tag -- Output Groovy Group List
Example Tag With a Body
Using Custom Tags Instead of <g:if>
Testing Tags
A Sample Test Class
Namespaces
Distributing TagLibs With Plugins
Demo