I'm working on another Grails application and am using the fantastic Grails UI plugin for a lot of the UI controls. Grails UI is a really nice Grails-friendly wrapper around the YUI components and includes things like a dialog box, calendar controls, a rich text editor, and a whole lot more. This was my first real foray into using this plugin, so I started with a simple modal dialog box that would show the contact information details for people in a simple list.

The main point of this post is to outline the simple resolution to the CSS issues I was seeing because it took me a while to figure out what was going on, but I thought I'd outline some Grails and Grails UI magic along the way.

First, in order to use the Grails UI plugin you of course have to install it, which is as simple as:

grails install-plugin grails-ui


Next, 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.

Grails 1.2 final was released today, and there's tons of great new features as well as numerous under-the-hood improvements that make it a very compelling release.

Since I'm relatively new to Grails I'm still wrapping my head around some of the new stuff, but here are some of the more interesting changes in 1.2 from my perspective:

• Performance Improvements
  Faster is always better of course, so the first thing that caught my eye was the performance improvements in GSP/SiteMesh and the tag library return types (default is now StreamCharBuffer, but tags can return object values too).
• Environments in Bootstrapper
  Not that this was a showstopper in previous versions of grails, but having to use a kludge or do a quick check of the state of your database to see whether or not you should crank out test data seemed a bit wrong since environment awareness is available elsewhere in Grails apps. Now that it's in the bootstrapper too we can do things the "right way."
• Per-Method Transactions in Services
  I haven't run into issues with this yet but I could see them coming, so it's nice that you can now declare at the method level whether or not something should be transactional.
• Named Query Support
  I'm still debating whether or not I think this one is a good idea, but it's certainly interesting. Named query support allows you to define named queries right in your domain classes, and these named queries can then be executed in the same fashion as dynamic finders. The really intriguing thing is that you can run dynamic finders on your named queries, which is tremendously powerful. On the one hand I'm thinking, "Queries in my domain class? That seems wrong." But on the other hand, when they're looked at as "customized dynamic finders," I suppose it's really no more intrusive than the dynamic finders themselves. And frankly given the power you can get out of this feature it's probably worth the small purity of architecture trade-off.
• Support for SQL Restrictions in Criteria Builder
  Much as I love GORM, sometimes it's simpler to throw some ad-hoc SQL at a problem. This is now supported in the criteria builder which should make lots of the "grab stuff then grab stuff from that stuff" type code disappear (if that made any sense!).
• GSPs are Pre-Compiled in WAR Deployments
  Small new feature, huge impact in my opinion. On Tomcat instances where we're running a few other apps (especially on 32-bit Windows servers … don't get me started), we noticed that Grails apps wouldn't start up due to out of memory errors that I strongly suspect were related to this issue. Pre-compiling GSPs reduces the amount of permgen memory space used on deployment.
• Tomcat is Now the Default Container
  I didn't have a problem with Jetty personally but since we use Tomcat in production it's nice it will be Tomcat in development as well. Note that you can still use Jetty if you like since all the container support is done through plugins. The Tomcat Plugin has a ton of cool additional features like JNDI support in Config.groovy for the embedded Tomcat instance, as well as remote deploy/undeploy scripts. Yes, you can do "grails tomcat deploy" to deploy your app to a remote server. Sweet.
• Named URL Mappings
  Very handy feature that lets you create URL mappings that may be linked to by name in the link tag/function. For example if you define a URL mapping with the name "fooBar" with attributes of foo and bar, your link tag in a GSP would be <link:fooBar foo="foo" bar="bar">Link to FooBar</link>
• Improved JSON Builder
  Some nice changes (and an under-the-hood rewrite apparently) here, but note this is a breaking change from previous versions. You can turn on compatibility if you don't want to re-write your code to take advantage of the new simpler syntax.
• Better Date Parsing
  One of the very few things I've run into in Grails so far that I thought to myself, "this could be simpler," is the way the date picker passes its params to controllers. Now it works like it should have all along.

Much more in this release so be sure and check out the release notes for all the details.

Kudos to everyone involved with this release! Can't wait to upgrade the current app I'm working on and give this all a whirl.