volume two | issue three | march, 2009

in this issue :

AJAX
Forms In Grails

Grails in a J2EE world

Groovy Under the Hood
New GORM features in Grails 1.1
Plugin Corner • Community News
From the editor... Editor
Michael Kimsal

News Editor
Dave Klein
We’ve had quite an eventful February to report on here
Contributors
at GroovyMag! Mo Sayed
Shawn Hartsock
I’m happy and excited to announce the pending launch Kirsten Schwark
Bashar Abdul-Jawad
of a sister publication for GroovyMag - JSMag. As you Dave Klein
might be able to deduce, JSMag is a magazine in the
same vein as GroovyMag, but targetting the JavaScript developer. Regardless Graphic Designer
of your chosen server-side technology, nearly all web developers these days Sara Smith
sara@groovymag.com
have some interaction with JavaScript. We’re hoping to bring the same level
of quality and coverage to the JavaScript world as we’ve been doing to the
Groovy world for the past several months. Please visit http://jsmag.com for more
information and to watch for the launch in early March.
volume two | issue three | march, 2009

in this issue :

During the last month we’ve added two technical editors to our production AJAX
process, and I believe you’ll notice a difference. Initially I’d been doing all Forms In Grails
the editing myself, but quickly realized that, well, I don’t scale. Bringing in
professionals was well received by this month’s contributors, and is something
we’ll be continuing on in our efforts to bring you the best quality Groovy
magazine we can.
Grails in a J2EE world

This month’s issue sees some new faces as well as some more familiar ones. Groovy Under the Hood
New GORM features in Grails 1.1

Bashar Abdul-Jawad gives us an review of some of the new GORM features Plugin Corner • Community News

in Grails 1.1. Mo Sayed walks us through using AJAX and Grails together
for a seamlessly updating UI experience. As usual Dave Klein brings us the CONTENTS
latest news from the Groovy community, as well as walks us through the Help Page 3
Balloons plugin, showing you how to bring a little extra touch of help to your AJAX Forms with grails
Mo Sayed
users.
Page 13
Grails in a J2EE World
Our last two pieces are both “first installments.” Kirsten Schwark brings us Shawn Hartsock
part one in a two part series which details just what exactly it is Groovy is
Page 15
doing when it’s compiling down to Java. i have to admit this one was just a bit Groovy Under The Hood-
over my head, but the early reviewers gave it good reviews, and I hope you Part I
Kirsten Schwark
will enjoy it and learn something as well. Shawn Hartsock is back with an
introduction to his series on “Using Grails in a J2EE World”. Shawn will be Page 24
detailing the integration strategies he’s using in the real world to bring peace New GORM Features
in Grails 1.1-
and harmony (or at least some sanity) to his daily work life in the hopes that it Part I
will help you with your integration efforts. Bashar Abdul-Jawad

Page 31
Enjoy! Groovy User Groups
Glen Smith and Peter Ledbrook

Page 32
Plugin Corner
Dave Klein

Page 34
Community News
Dave Klein

2 • groovymag • volume two | issue three | march, 2009 (c) 2009 GroovyMag
 AJAX Forms with Grails

By Mo Sayed

A common requirement for Web applications is to capture user To demonstrate these features, we'll develop a hypothetical
input typically by using HTML forms. Forms are common, and conference registration form as shown in figure 1:
can range in application: registration, ordering items, surveys/
questionnaires, and entering business data. Constructing HTML Figure 1: Basic registration form
forms is not difficult but deserves serious consideration during the
design stage. Poorly designed interfaces can significantly impact
usability and potentially drive traffic away from the web site/
application. Badly designed forms are usually confusing, cluttered
and overly complex. Some of these issues can be avoided by
following simple design guidelines; capturing only pertinent data,
not requesting duplicate information and so forth.

Superior form design can be achieved through the use of AJAX

(Asynchronous Javascript and XML technology). AJAX is best
known for its ability to perform server-side processing and page
updating without the need for form submission. AJAX has its share
of critics and supporters; however, through careful and judicious
use, it can enhance the usability of your Web application. Benefits
of AJAX include improved usability, a slicker user experience,
and more intuitive forms. In this article, we examine five ways to
use AJAX to help develop interactive Web-based forms. You will
learn how to implement the following AJAX-based features:

Feature 1 (dynamic validation of text fields) enables users
to validate text field entry without form submission.
Feature 2 (autocomplete) helps users quickly enter data into
a text field by offering suggestions as they type.
Feature 3 (chained selects) links up two distinct but coupled
HTML select elements, so that the values displayed
in the second element reflect the selection made in the first.
Feature 4 (form toggling) displays distinct form elements
based upon the value of a form control like a select
element.
The form consists of a series of HTML elements allowing
the registrant to input a number of different data. This form
looks simple, but it actually suffers from a number of usability
problems.
The first problem is that the 'Username' field requires the registrant
to provide a unique value, one which has not already been assigned
to a previous registrant. For example, there may be an existing
entry for a common value such as "John Smith". This is problem-
atic since it will require the registrant to submit the form in its
entirety in order to obtain validation on the server. This could lead
to numerous cycles of form editing and resubmis-sion before a
unique value is entered.

Feature 5 (inline editing) allows the user to edit a data entry The second usability problem involves, the 'Country' field. This
on the page and have it validated and updated in the field is a select element populated by a list of world countries.
database without actually submitting the form. Unfortunately, this list is quite large and the regis-trant will need

3 • groovymag • volume two | issue three | march, 2009

 Groovy Under The Hood-
How Your Groovy Class
Becomes Java Bytecode – Part I

By Kirsten Schwark

Groovy is a dynamic language that
runs on the JVM. This means your
Groovy code must be translated
into Java bytecode in order to be
executed on the JVM. So how
does the Groovy compiler take
seemingly non-Java functionality
like dynamic method invocation
and implement it in Java? This
article will attempt to provide a
little insight into the magic under
Groovy's hood by lifting it slightly
and peeking inside.
Part I of this article will examine
how Groovy generates Java
bytecode from your Groovy class
and how the basic class concepts
are translated into Java bytecode.
Part II will delve more into the
default implementation of some of
Groovy's dynamic features.
Why Look at How a Groovy Class Becomes a Java Class?
The Groovy language is for the most part a superset of the Java language. This means
generally you can take your Java code and run it in Groovy. We've all seen the Groovy
demonstration that takes a Java source file, renames it .groovy and runs it in Groovy. The
Java class is not idiomatic Groovy, but it is Groovy nonetheless. Since Groovy can be
viewed as effectively an extension of Java, many Groovy constructs and features must be
'translated' into Java code in order to run on the JVM.
While Groovy appears interpreted, Groovy is in fact a compiled language that gets compiled
into Java bytecode that is then run on the JVM. When you run your Groovy program or
script, it is being translated into Java bytecode in memory and executed on the JVM.
Why is it worthwhile for a Groovy developer to have a basic understanding of the Java
code that is being generated from their Groovy code? Here are a few reasons:
Seeing the Java code that Groovy generates gives one an appreciation of the true
beauty of the Groovy language. Groovy is able to capture the essence of Java without all
the scaffolding and seeing how the compiler is able to generate the scaffolding from the
essence gives a true appreciation for the Groovy language.
Seeing the Java code generated by the Groovy compiler shows how dynamic
behavior can be realized in a static environment.
Knowledge of how your Groovy code becomes Java code allows a Groovy
developer to to write Groovy code that is more efficient when it is executed on a JVM.
Stack traces are easier to read and understand since in Groovy they are presented
from a Java perspective. This includes call stacks in your favorite IDE as well as stack
traces when exceptions are thrown.
As a Java developer seeing a really elegant implementation of some very interesting
programming concepts plants seeds of how similar solutions might be applied in your
existing Java code. Any time you read well-written code you become a better developer
simply by reading it.

The Tools to Run Your Groovy Code

Your Groovy distribution includes a few tools used to execute Groovy code and scripts. One is the Groovy interpreter (groovy) and the
other is the Groovy compiler (groovyc). There are other tools provided in the distribution; including the Groovy Shell (groovysh) and
the Groovy Console (groovyConsole), but these are used to interactively execute Groovy.

Both the Groovy interpreter and the Groovy compiler compile your Groovy classes into Java bytecode to run on the JVM. The major
difference is when the compilation occurs and whether the resulting bytecode is in memory or on disk.

The Groovy Interpreter (groovy)

The Groovy interpreter takes a Groovy file (either a Groovy script or a Groovy program file with a main method) and executes it directly
on the JVM. In order to execute your Groovy code on the JVM though, it must first be converted to Java bytecode. The compilation

15 • groovymag • volume two | issue three | march, 2009

Groovy Under The Hood - How Your Groovy Class Becomes Java Bytecode – Part I

process is described in more detail below, but in short the Groovy interpreter (which is a Java program) takes your Groovy code,
compiles it in memory to bytecode using the process below and then executes it directly on the JVM.

groovy

Groovy compile Java execute

Source (groovy) Bytecode (Class Loader)

Figure 1 – The Groovy Interpreter

The Groovy interpreter is executed as follows:
groovy [options] <program or script>
For example:
groovy MyScript.groovy
will execute the Groovy script MyScript by first compiling the
script into Java bytecode and then executing it on the JVM.
class matches the name of the script. The Groovy compiler will
generate a run method that contains the translated Groovy script
code (the code that is within the script that resides outside of any
class). It will also generate a main method that creates an instance
of the generated Script class and invokes the Script object's run
method.
For each Groovy class, the Groovy compiler will generate a
class that implements the groovy.lang.GroovyObject interface.
This interface is an integral component of the implementation of
dynamic behavior in Groovy. It will be discussed at length in Part
II of this article.
Additional classes are generated for closures that appear within
your Groovy class or script, so the Groovy compiler will generate
at least one Java .class file on disk for each Groovy class or

Groovy compile Java execute

Source (groovy) Bytecode (java)

The Groovy Compiler

(groovyc) Figure 2 – The Groovy Compiler
The Groovy compiler enables you to
compile your Groovy code to bytecode
which is stored on disk in Java .class files. This bytecode can The Groovy compiler is executed as follows:
then be run as regular Java application code within a JVM.

groovyc [options] <program or script>

At least one Java class is created for each Groovy class or script
in your application. The generated Java class or script will have
the same name as the Groovy class or script. The Groovy compiler
may create additional classes; for example each closure that For example:
appears in your Groovy source will have an associated class.

groovyc MyScript.groovy
For each Groovy script, the Groovy compiler will generate a class
that extends from groovy.lang.Script. The name of the generated

16 • groovymag • volume two | issue three | march, 2009

New GORM Features
in Grails 1.1 (Part 1 of 2)
Grails 1.1 is just around the corner
with a target release date slated
for the end of February 2009, so
Grails 1.1 might have already been
released by the time you read
this article. Grails 1.1 includes
many new and exciting features:
out of the box Maven 2 support,
Global plugins, a new testing
framework, the ability to use JSP
tags in GSPs and many more. This
article is the first of two articles
that will discuss the new GORM
features forthcoming in Grails 1.1,
specifically using the latest binary
release, Grails 1.1 Beta 3. In this
article I will discuss using GORM
in standalone mode, new GORM
events, better enum support,
and persistence of collections
of basic types and enums. Next
month’s article will discuss loading
objects in read-only state, batch
fetching, new dynamic finders and
improvements to legacy mapping.
24 • groovymag • volume two | issue three | march, 2009
By Bashar Abdul-Jawad
Using GORM outside of Grails
Prior to Grails 1.1, using GORM outside of a Grails application was not an easy task.
It involved multiple configuration changes and numerous hacks to get it to work, and
those hacks usually didn’t work with a newer release of Grails. Luckily, Grails 1.1 adds
support for using GORM outside of Grails by using Spring to configure a Hibernate
SessionFactory. In the following example, I will show you how to use GORM in a
command-line application that creates and lists Authors and Books.
To make our life easier, I will use Maven 2 to build the example and manage its
dependencies. Start by creating the POM file, shown in Listing 1, in the root of your
empty project.
LISTING 1
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:
xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.gorm.standalone</groupId>
<artifactId>groovymag</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>Standalone GORM</name>
<url>http://maven.apache.org</url>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.groovy.maven</groupId>
<artifactId>gmaven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>generateStubs</goal>
<goal>compile</goal>
<goal>generateTestStubs</goal>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.1</version>