Oliver's Place » Groovy

A simple GSP toolbar taglib for Grails

oliver — Wed, 13 Jan 2010 15:55:26 +0000

Did you ever had to implement a menu in Grails GSP where every link element should be seperated from its predecessor by a separator character and where some of the elements can be missing when certain conditions are not met (security etc)?

The part with the optional elements can turn the separator handling into a real mess. So today I decided to end this nonsense. The result is a tiny taglib which can be integrated into every grails project. The usage is pretty self explanatory:

And this would be rendered assuming the user has permission for both buttons:

^?View Code HTML

Delete|Lock

Tag Library Source:

^?View Code GROOVY

class MenuTagLib
{
  static namespace = 'mx'
 
  /** The toolbar container */
  def toolbar =
  { attrs, body ->
    def separator = attrs.separator ?: '|'
 
    // we'll be using this to keep track of our items
    def menuItems = []
    this.pageScope.menuItems = menuItems
 
    // this will execute the body, so that the items are appended obviously,
    // anything other than the item tags will not render correctly.
    body()
 
    // render every item and add a separator except for the last item 
    menuItems.eachWithIndex
    { item, index ->
      out << item
      if(index < menuItems.size() - 1)
        out << separator
    }
  }
 
  /** A toolbar item */
  def item =
  { attrs, body ->
    def itemContent = body().trim()
    if(itemContent) // only add the item if rendering evaluated to non-empty string
      this.pageScope.menuItems << itemContent
  }
}

Grails sanitized stracktraces

oliver — Sat, 10 Oct 2009 21:01:35 +0000

The other day I was writing a medium complex HQL query for a Grails App and no matter what the line executing the query would crash like this:

^?View Code GROOVY

java.lang.NullPointerException
	at $Proxy13.createQuery(Unknown Source)
	at com.acme.PerformanceService.makePerformanceSheet(PerformanceService.groovy:38)
  ...

So how the hell do we figure out what the problem given so few information? Turns out that grails sanitizes the exception stacktrace, resulting in better readability by removing a lot of clutter. Sometimes though this optimization will also hide some important details from you. Luckily we can still refer to stacktrace.log which usually resides in the project root folder in development mode. In this particular case opening the file reveiled this:

^?View Code GROOVY

java.lang.NullPointerException
	at org.hibernate.dialect.Dialect$3.getReturnType(Dialect.java:125)
	at org.hibernate.hql.ast.util.SessionFactoryHelper.findFunctionReturnType(SessionFactoryHelper.java:405)
	at org.hibernate.hql.ast.tree.AggregateNode.getDataType(AggregateNode.java:44)
	at org.hibernate.hql.ast.tree.SelectClause.initializeExplicitSelectClause(SelectClause.java:165)
	at org.hibernate.hql.ast.HqlSqlWalker.useSelectClause(HqlSqlWalker.java:727)
	at org.hibernate.hql.ast.HqlSqlWalker.processQuery(HqlSqlWalker.java:551)
	at org.hibernate.hql.antlr.HqlSqlBaseWalker.query(HqlSqlBaseWalker.java:645)
	at org.hibernate.hql.antlr.HqlSqlBaseWalker.selectStatement(HqlSqlBaseWalker.java:281)
	at org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:229)
	at org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:251)
	at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:183)
	at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:134)
	at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:101)
	at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
	at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:94)
	at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:156)
	at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:135)
  ...

Which almost instantly gave me the hint that something’s wrong with the aggregate part of my query:

^?View Code GROOVY

org.hibernate.hql.ast.tree.AggregateNode.getDataType

And indeed the problem was that I had ported an SQL Query to HQL and forgot to rename the sum() aggregate argument from the column name to the domain class property name:

sum(some_property) instead of sum(foo.someProperty)

Updating multiple page elements with Grails and Ajax

oliver — Mon, 20 Jul 2009 09:30:01 +0000

Every Web Application Project I’ve been involved in the recent past had one thing in common: the client demanded more and more rich-client features at an ever increasing pace – without committing itself to real rich-client frameworks such as Flex or Silverlight. This leaves us with Javascript / AJAX for implementing highly dynamic User Interfaces for Web Applications. A very common problem when working with Ajax is the requirement to update multiple parts of a page in response to a single request. This post aims to familiarize the reader with my own approach to this problem.

At its core my solution consists of just two functions – one running server side and the other executing on the client. The first function is intended to run on the server and is written in Groovy. It was originally written in Python for use with the Django framework and I’ve ported it to Groovy when I switched to Grails as my primary RAD Web framework. This function takes a map as argument and returns a JSON encoded map where the key is a valid jQuery Selector designating the targets for the update and the value is a map containing information how the matched elements should be modified and how the content for the update shall be produced. Don’t worry if you find this confusing at first. There’s a sample further down.

^?View Code GROOVY

def renderElementUpdateResponse(elements)
{
  def rendered_elements = [:]
 
  elements.eachWithIndex
  { k, v, i ->
    rendered_elements[k] = [:]
    rendered_elements[k]['mode'] = v['mode']
 
    // if content is a Map, feed it into g.render - using the key as template name and the value as model
    if(v['content'] instanceof java.util.LinkedHashMap)
      rendered_elements[k]['content'] = g.render(template: v['content'].keySet().toArray()[0], model: v['content'].values().toArray()[0])
    else
      rendered_elements[k]['content'] = v['content']
  }
 
  def tmp = ['updates': rendered_elements]
  render tmp as JSON
}

The second function is written in Javascript and responsible for applying the JSON wrapped HTML fragments to their designated HTML DOM Elements:

^?View Code JAVASCRIPT

function applyElementUpdates(transport)
{
  var updates;
 
  if (transport.updates)
  {
    updates = transport.updates;
    var scripts = new Array()  // need to queue initializers until all updates are done
 
    for(target in updates)
    {
      if(updates[target]['mode'] == 'execute')
      {
        code = updates[target]['content']
        scripts.push(code)
        continue
      }
 
      var targetNode = $(target);
      var newContent = updates[target]['content'];
      var oldContent = targetNode.html();
 
      switch(updates[target]['mode'])
      {
        case 'replace':
          targetNode.html(newContent);
          break;
        case 'insert':
          targetNode.html(newContent + oldContent);
          break;
        case 'append':
          targetNode.html(oldContent + newContent);
          break;
      }
    }
 
    // now run initializers
    for(i in scripts)
    {
      code = scripts[i]
      eval(code)
    }
  }
}

So how do you use it? Below you find all necessary code artifacts for implementing the described technique in arbitrary Grails application. Please note that this sample uses jQuery for carrying out the actual AJAX request but it would be trivial to port this over to any other decent Javascript Framework like MooTools, Prototype or YUI.

Let’s begin with the GSP page in /views/test/index.gsp:

^?View Code ASP

<%@ page contentType="text/html;charset=UTF-8" %>
<html>
  <head>
    <g:javascript src="jquery-1.3.2.js" />
    <g:javascript src="applyElementUpdates.js" />
 
    <script type="text/javascript">
    $(document).ready(function()
    {
      $('#btnClickMe').click(function()
      {
        $.ajax(
        {
          url: '${createLink(controller: 'test', action: 'update')}',
          type: "POST",
          dataType: "json",
          cache: false,
          async: true,
          success: function(data, status)
          {
            applyElementUpdates(data)
          }
        })
      })
    });
    script>
  head>
  <body>
  <input type="button" id="btnClickMe" value="Click me"/>
  <br/><br/>
  <div id="div1">div>
  <div id="div2">div>
  body>
html>

The controller in /controllers/TestController.groovy:

^?View Code GROOVY

import grails.converters.JSON
 
class TestController extends BaseController
{
  def index =
  {
  }
 
  def update =
  {
    def model = [a: 1, b: 2]
 
    // Note: renderElementUpdateResponse is supposed to be implemented in BaseController
    return renderElementUpdateResponse(
    [
      '#div1'   : [ 'mode': 'replace', 'content' : [ 'fragment1': model ] ],
      '#div2'   : [ 'mode': 'append', 'content'  : [ 'fragment2': model ] ],
      '__init__': [ 'mode': 'execute', 'content' : 'alert("The page has been updated")' ]
    ])
  }
}

The call to renderElementUpdateResponse needs some explanation. Let’s step through the arguments line by line.

^?View Code GROOVY

 '#div1': [ 'mode': 'replace', 'content' : [ 'fragment1': model ] ]

“[ 'fragment1': model ] ]” is the only relevant part on the server side. It means “render the GSP template /views/test/_fragment1.gsp, pass it the variable model as the model and store the resulting string as the content for the update. On the client side it tells the applyElementUpdates() function to replace (mode: replace) the output for this line in all elements with id=”div1″.

^?View Code GROOVY

 '#div2': [ 'mode': 'append', 'content' : [ 'fragment2': model ] ]

Works basically the same as the previous line only that id=”div2″ is targetted and rendering /views/test/_fragment2.gsp will produce the content which is going to be appended to the target element rather than replacing it.

^?View Code GROOVY

 '__init__': [ 'mode': 'execute', 'content' : 'alert("The page has been updated")' ]

In addition to updating DOM elements we can also send code to the client which is run after all elements have been updated. Such fragments are called initializers and are identified on the client by their mode attribute which must be ‘execute’. This sample also demonstrates that fragment content can be specifed directly (alert(“The page has been updated”)) instead of being produced by rendering a template. Please note that the selector (‘__init__’) is unused in this case. The sole reason for chosing that id was to emphasize the purpose of this fragment.

The final missing bits are the aforementioned Grails templates which are going to producing the content for the updated elements.

The fragment for updating the first div in /views/test/_fragment1.gsp:

^?View Code ASP

<span>Value of A is ${a}span>

The fragment for updating the second div in /views/test/_fragment2.gsp:

^?View Code ASP

<span>Value of B is ${b}span><br/>

Finally, opening the example page on your browser and clicking the button results in the following actions:

The div1 element gets updated with the HTML output of rendering /views/test/_fragment1.gsp against the simple model. The contents of div1 are replaced
The div2 element gets updated with the HTML output of rendering /views/test/_fragment2.gsp against the simple model. The HTML is appended to the div rather then replacing the contents.
An alert box is displayed

That’s it folks. I hope you found this post useful.

Using GIT with Grails UI-Performance Plugin

oliver — Thu, 18 Jun 2009 18:16:53 +0000

I’ve been doing a serious amount of Grails Development lately and if there’s one Grails Plugin I consider mandatory for any serious production deployment then it is the UI-Performance plugin by Burt Beckwith. One of the features of the plugin that reduces server load is versioning and far-future “Expires” and “Cache-Control” headers for static resources.

Each time you generate a new WAR for deployment, a new version is applied to all image, .js, and .css files so files can be cached forever. The next time you deploy a new version of your application, all of the resource file names will have changed, so only then will files be requested. The default process for determining the version is to look at the version of the root project folder in the Subversion metadata files. Since I’ve switched to GIT for all my projects a while ago the plugin would fallback to “System.currentTimeMillis().toString()” to compute the version.

My solution is to include the following line in my projects Config.groovy:

^?View Code GROOVY

uiperformance.determineVersion = { -> "git rev-list --max-count=1 HEAD".execute().text.trim() }

This allows the HEAD commit SHA1 hash of the current branch to be used as the uiperformance version for deployment.