I wrote previously about parsing JSON in Groovy. In this article I show a simple example of creating JSON using Groovy. I had to learn about creating JSON using Groovy as I would be using JSON as the response format in the REST API which might be developed sometime in future.

Creating JSON using Groovy

Groovy 1.8 introduced json package for parsing and building JSON data. JsonSlurper is used for parsing JSON and JsonBuilder is used for creating JSON in Groovy.

Lets see a very simple example of creating a JSON using named arguments:

def jsonBuilder = new groovy.json.JsonBuilder()
jsonBuilder.book(
    isbn: '0321774094',
    title: 'Scala for the Impatient',
    author: 'Cay S. Horstmann',
    publisher: 'Addison-Wesley Professional',
)
println("Using just named arguments")
println(jsonBuilder.toPrettyString())

The output:

Using just named arguments
{
  "book": {
    "isbn": "0321774094",
    "title": "Scala for the Impatient",
    "author": "Cay S. Horstmann",
    "publisher": "Addison-Wesley Professional"
  }
}

Creating JSON using an instance of some class
For this lets define a class which would be a container for our data:

class MyBook{
    def isbn
    def title
    def author
    def publisher
}

and the code which would create JSON from an instance of MyBook is

def myBook = new MyBook(isbn: '0321774094',
                        title: 'Scala for the Impatient',
                        author: 'Cay S. Horstmann',
                        publisher: 'Addison-Wesley Professional')
jsonBuilder(book: myBook)
println("Using an object")
println(jsonBuilder.toPrettyString())

The output:

Using an object
{
    "book": {
        "title": "Scala for the Impatient",
        "publisher": "Addison-Wesley Professional",
        "isbn": "0321774094",
        "author": "Cay S. Horstmann"
    }
}

Creating JSON using a list of instances

def myBook = new MyBook(isbn: '0321774094',
  title: 'Scala for the Impatient',
  author: 'Cay S. Horstmann',
  publisher: 'Addison-Wesley Professional')

def myBook2 = new MyBook(isbn: '0976694085',
  title: 'Pragmatic Ajax: A Web 2.0 Primer',
  author: 'Justin Gehtland, Ben Galbraith, Dion Almaer',
  publisher: 'Pragmatic Bookshelf')

def myBook3 = new MyBook(isbn: '1934356050',
  title: 'Pragmatic Thinking and Learning: Refactor Your Wetware',
  author: 'Andy Hunt',
  publisher: 'Pragmatic Bookshelf')

def myBookList = [myBook,myBook2,myBook3]

jsonBuilder(books: myBookList)
println("Using list of objects")
println(jsonBuilder.toPrettyString())

The output for this would be:

Using list of objects
{
  "books": [
    {
      "title": "Scala for the Impatient",
      "publisher": "Addison-Wesley Professional",
      "isbn": "0321774094",
      "author": "Cay S. Horstmann"
    },
    {
      "title": "Pragmatic Ajax: A Web 2.0 Primer",
      "publisher": "Pragmatic Bookshelf",
      "isbn": "0976694085",
      "author": "Justin Gehtland, Ben Galbraith, Dion Almaer"
    },
    {
      "title": "Pragmatic Thinking and Learning: Refactor Your Wetware",
      "publisher": "Pragmatic Bookshelf",
      "isbn": "1934356050",
      "author": "Andy Hunt"
    }
  ]
}

For more details visit the API here and a good article here.

In our sample Gaelyk application here we stopped at just obtaining the location information. In this post lets update that application to fetch the Weather information as well.

For the weather information we make use of the Weather Underground API which provides a lot of features like geolocation information, current weather conditions, forecast weather conditions among others. You need to sign up to obtain the API KEY.

The URL to request the data is:

http://api.wunderground.com/api/

KEY/FEATURE/[FEATURE…]/[SETTING…]/q/
QUERY.FORMAT

where,
KEY- API key which you can obtain after sign up
FEATURE- The feature you are interested in: geolocation, conditions, astronomy, radar and so on. One can provide multiple feature data to be retrieved.
FORMAT- The format for the return data- XML or JSON
QUERY- This is the query to be used for retrieving the data- can be city name, pin code, latitude-longitude and others.

For our application we can make use of the following version of the URL:

http://api.wunderground.com/api/

${weatherKey}/conditions/q/
${locationInformation.cityName}.json

where,
${weatherKey}- will be replaced by the actual weather key
${locationInformation.cityName} will be replaced by actual city name.

Lets create a template- weather.gtpl for showing the Weather information. This template will be added to src/main/webapp/WEB-INF/includes.

<!-- weather.gtpl -->
<h3>Weather as of ${request.forecastDate}</h3>
<div class="span3">
    <ul>
        <li>
            <strong>Weather</strong>: 
            ${request.weather}
        </li>
        <li>
            <strong>Temperature</strong>: 
            ${request.temperature}
        </li>
        <li>
            <strong>Wind</strong>: 
            ${request.wind}
        </li>
        <li>
            <strong>Relative Humidity</strong>: 
            ${request.relativeHumidity}
        </li>
    </ul>
    More details 
      <a href="${request.moreUrl}" 
         target="_blank">here</a>
</div>
<div class="span2">
    <img src="${request.icon}" 
         alt="${request.iconDesc}" />
</div>

And this will be included in the src/main/webapp/WEB-INF/pages/index.gtpl as:

<% include '/WEB-INF/includes/header.gtpl' %>
<div class="row">
     <!-- Older code here-->
    <div class="span6">
        <% include '/WEB-INF/includes/weather.gtpl' %>
    </div>
</div>
<% include '/WEB-INF/includes/footer.gtpl' %>

Now we need to fetch the required information in the Groovlet and set it in the request object. This can be performed in the src/main/webapp/WEB-INF/groovy/index.groovy.

//index.groovy
//Code from the previous sample- removed for clarity
//Fetch the weather information
def weatherKey="YOUR API KEY HERE"
def weatherUrl = """http://api.wunderground.com/api/
                ${weatherKey}/conditions/q/
                ${locationInformation.cityName}.json"""
def xmlSlurper = new XmlSlurper()
def weatherInformation = null
if (memcache[locationInformation.cityName] != null){
    weatherInformation = 
        memcache[locationInformation.cityName]
}
else{
    weatherInformation = 
        jsonSlurper.parseText(new URL(weatherUrl).text)
    //caching the weather for each hour
    memcache.put(locationInformation.cityName,
                 weatherInformation,
                 Expiration.byDeltaSeconds(3599))
}

def currentObservation = 
    weatherInformation.current_observation
request.forecastDate = 
    currentObservation.observation_time_rfc822
request.weather = 
    currentObservation.weather
request.temperature = 
    currentObservation.temperature_string
request.wind = 
    currentObservation.wind_string
request.relativeHumidity = 
    currentObservation.relative_humidity
request.moreUrl = 
    currentObservation.ob_url
request.icon = 
    currentObservation.icon_url
request.iconDesc = 
    currentObservation.icon

forward '/WEB-INF/pages/index.gtpl'

Once completed your application will look like:

If you want to play around with this code and also the previous sample developed here you can fork the git repo here and clone the repo locally. Once you are done with that just execute gradlew gaeRun on your command line to run this application.

This article is based on Groovy in Action, Second Edition, to be published on Summer 2011. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) eBooks and pBooks. MEAPs are sold exclusively through Manning.com. All pBook purchases include free PDF, mobi and epub. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information. [ Use promotional code 'java40beat' and get 40% discount on eBooks and pBooks ]

Introduction

Although it’s nice to have code that reads like a simple list of instructions with no jumping around, it’s often vital that control is passed from the current block or method to the enclosing block or the calling method—or sometimes even further up the call stack. Just like in Java, Groovy allows this to happen in an expected, orderly fashion with return, break, and continue statements and, in emergency situations, with exceptions. Let’s take a closer look.

Normal termination: return/break/continue

The general logic of return, break, and continue is similar to Java. One difference is that the return keyword is optional for the last expression in a method or closure. If it is omitted, the return value is that of the last expression. Methods with an explicit return type of void do not return a value, whereas closures always return a value.

Listing 1 shows how the current loop is shortcut with continue and prematurely ended with break. As in Java, there is an optional label.

Listing 1 Simple break and continue

def a = 1
while (true) { //#1 Do forever
	a++
	break //#2 Forever is over now
}
assert a == 2
for (i in 0..10) {
	if (i==0) continue //#3 Proceed with 1
	a++
	if (i > 0) break //#4 Premature loop end
}
assert a==3
Using break and continue is sometimes considered smelly. However, they can be useful for controlling the workflow in services that run in an endless loop or for breaking apart complex conditional logic, such as this:
for(i in whatever){
if (filterA) continue // skip if filter matches
if (conditionB) break // exit loop if condition matches
// normal case here
}

Similarly, returning from multiple points in the method is frowned upon in some circles but other people find it can greatly increase the readability of methods that might be able to return a result early. We encourage you to figure out what you find most readable and discuss it with whomever else is going to be reading your code—consistency is as important as anything else.

As a final note on return handling, remember that, when closures are used with iteration methods such as each, a return statement within the closure returns from the closure rather than the method.

Exceptions: throw/try-catch-finally

Exception handling is exactly the same as in Java and follows the same logic. Just as in Java, you can specify a complete try-catch-finally sequence of blocks, or just try-catch, or just try-finally. Note that, unlike various other control structures, braces are required around the block bodies whether or not they contain more than one statement. The only difference between Java and Groovy in terms of exceptions is that declarations of exceptions in the method signature are optional, even for checked exceptions. Listing 2 shows the usual behavior.

Listing 2 Throw, try, catch, and finally

def myMethod() {
	throw new IllegalArgumentException()
}
def log = []
try {
	myMethod()
} catch (Exception e) {
	log << e.toString()
} finally {
	log << 'finally'
}
assert log.size() == 2

In accordance with optional typing in the rest of Groovy, a type declaration is optional in the catch expression. And, like in Java, you can declare multiple catches.

There are no compile-time or runtime warnings from Groovy when checked exceptions are not declared. When a checked exception is not handled, it is propagated up the execution stack like a RuntimeException in Java.

It is worth noting an issue relating to exceptions. When using a Groovy class from Java, you need to be careful—the Groovy methods will not declare that they throw any checked exceptions unless you’ve explicitly added the declaration even though they might throw checked exceptions at runtime. Unfortunately, the Java compiler attempts to be clever and will complain if you try to catch a checked exception in Java when it believes there’s no way that the exception can be thrown. If you run into this and need to explicitly catch a checked exception generated in Groovy code, you may need to add a throws declaration to the Groovy code just to keep javac happy.

Summary

This article covered one of Groovy’s control structures: exiting blocks and methods early. We haven’t seen any big surprises: everything turned out to be like Java, enriched with a bit of Groovy flavor. The only structural difference is the for loop. Exception handling is very similar to Java, minus the requirement to declare checked exceptions.

This article is based on Groovy in Action, Second Edition, to be published on Summer 2011. It is being reproduced here by permission from Manning Publications. Manning publishes MEAP (Manning Early Access Program,) eBooks and pBooks. MEAPs are sold exclusively through Manning.com. All pBook purchases include free PDF, mobi and epub. When mobile formats become available all customers will be contacted and upgraded. Visit Manning.com for more information. [ Use promotional code 'java40beat' and get 40% discount on eBooks and pBooks ]

Introduction

In Groovy, everything is an object. It is, after all, an object-oriented language. Groovy doesn’t have the slight fudge factor of Java, which is object-oriented apart from some built-in types. In order to explain the choices made by Groovy’s designers, we’ll first go over some basics of Java’s type system. We will then explain how Groovy addresses the difficulties presented and, finally, examine how Groovy and Java can still interoperate with ease due to automatic boxing and unboxing where necessary.

Java’s type system—primitives and references

Java distinguishes between primitive types (such as boolean, short, int, float, double, char, and byte) and reference types (such as Object and String). There is a fixed set of primitive types and these are the only types that have value semantics, where the value of a variable of that type is the actual number (or character, or true/false value). You cannot create your own value types in Java.

Reference types (everything apart from primitives) have reference semantics; the value of a variable of that type is only a reference to an object. Readers with a C/C++ background may wish to think of a reference as a pointer—it’s a similar concept. If you change the value of a reference type variable that has no effect on the object it was previously referring to, you’re just making the variable refer to a different object or to no object at all. The reverse is true too: changing the contents of an object doesn’t affect the value of a variable referring to that object.

You cannot call methods on values of primitive types, and you cannot use them where Java expects objects of type java.lang.Object. For each primitive type, Java has a wrapper type–a reference type that stores a value of the primitive type in an object. For example, the wrapper for int is java.lang.Integer.

On the other hand, operators such as * in 3*2 or a*b are not supported for arbitrary1 reference types, but only for primitive types (with the notable exception of +, which is also supported for strings).

The Groovy code in listing 1 calls methods on seemingly primitive types (first, with a literal declaration and, then, on a variable), which is not allowed in Java, where you need to explicitly create the integer wrapper to convince the compiler. While calling + on strings is allowed in Java, calling the – (minus) operator is not. Groovy allows both.

Listing 1 Groovy allows methods to be called on types that are declared like primitive types in Java

1
2
3
4
5

(60 * 60 * 24 * 365).toString(); // invalid Java
int secondsPerYear = 60 * 60 * 24 * 365;
secondsPerYear.toString(); // invalid Java
new Integer(secondsPerYear).toString();
assert "abc" - "a" == "bc" // invalid Java

The Groovy way looks more consistent and involves some language sophistication that we are going to explore next.

Groovy’s answer—everything’s an object

In order to make Groovy fully object oriented and because, at the JVM level, Java does not support object-oriented operations such as method calls on primitive types, Groovy designers decided to do away with primitive types. When Groovy needs to store values that would have used Java’s primitive types, Groovy uses the wrapper classes already provided by the Java platform. Table 1 provides a complete list of these wrappers.

Any time you see what looks like a primitive literal value (for example, the number 5, or the Boolean value true) in Groovy source code, that’s a reference to an instance of the appropriate wrapper class. For the sake of brevity and familiarity, Groovy allows you to declare variables as if they were primitive type variables. Don’t be fooled—the type used is really the wrapper type. Strings and arrays are not listed in table 1 because they are already reference types and not primitive types—no wrapper is needed.

While we have the Java primitives under the microscope, so to speak, it’s worth examining the numeric literal formats that Java and Groovy each use. They are slightly different because Groovy allows instances of java.math.BigDecimal and java.math.BigInteger to be specified using literals in addition to the usual binary floating-point types. Table 2 gives examples of each of the literal formats available for numeric types in Groovy.

Notice how Groovy decides whether to use a BigInteger or a BigDecimal to hold a literal with a G suffix depending on the presence or absence of a decimal point. Furthermore, notice how BigDecimal is the default type of non-integer literals; BigDecimal will be used unless you specify a suffix to force the literal to be a Float or a Double.

Interoperating with Java—automatic boxing and unboxing

Converting a primitive value into an instance of a wrapper type is called boxing in Java and other languages that support the same notion. The reverse action—taking an instance of a wrapper and retrieving the primitive value—is called unboxing. Groovy performs these operations automatically for you where necessary. This is primarily the case when you call a Java method from Groovy. This automatic boxing and unboxing is known as autoboxing.

You’ve already seen that Groovy is designed to work well with Java; so, what happens when a Java method takes primitive parameters or returns a primitive return type? How can you call that method from Groovy? Consider the existing method in the java.lang.String class: int indexOf (int ch). You can call this method from Groovy like this:

1

assert ’ABCDE’.indexOf(67) == 2

From Groovy’s point of view, we’re passing an Integer containing the value 67 (the Unicode value for the letter C), even though the method expects a parameter of primitive type int. Groovy takes care of the unboxing. The method returns a primitive type int that is boxed into an Integer as soon as it enters the world of Groovy. That way, we can compare it to the Integer with value 2 back in the Groovy script.

Figure 1 shows the process of going from the Groovy world to the Java world and back.

No intermediate unboxing

If in 1 + 1 both numbers are objects of type Integer, you may be wondering whether those Integers unboxed to execute the plus operation on primitive types.

The answer is no: Groovy is more object-oriented than Java. It executes this expression as 1.plus(1), calling the plus() method of the first Integer object, and passing3 the second Integer object as an argument. The method call returns an Integer object of value 2.

This is a powerful model. Calling methods on objects is what object-oriented languages should do. It opens the door for applying the full range of object-oriented capabilities to those operators.

Summary

Let’s summarize. No matter how literals (numbers, strings, and so forth) appear in Groovy code, they are always objects. Only at the border to Java are they boxed and unboxed. Operators are shorthand for method calls.

This article is about Groovy Server Pages basic concepts. Groovy Server Pages (GSP) is a view technology which can be used for designing web application using Grails Framework. Developing GSP are very much similar to that of designing web pages with Active Server Pages (ASP) and Java Server Pages (JSP) but coding is very much simpler and easier than both of them.
Users are provided with facility of having static, dynamic as well as mix of both contents at a time in a single application.
The output can be dynamically rendered to different forms like : HTML, XML, text and any other format based on Web client request object.If you are beginner in learning groovy, please read Introduction to Groovy – Scripting Language.

Advantages of using GSP using Grails

1. A GSP uses Groovy GString for evaluation of expression generally using ${….} but whereas in JSP EL expressions are used for the same purpose but they are restricted only to object navigation to overcome this disadvantage JSTL functions can to be written for creating static helper methods, registering them through a taglib descriptor, adding a taglib declaration and finally implementing them using the function.
2. A developer has been provided with Logical and Iterative tags in GSP with safe navigation operator and Elvis operator which
   can be implemented easily to fetch the needed results according to their requirement. For example these operators can be implemented in this manner:
   • Safe navigation operator :
     ${book.pages?.no()}
3. Elvis operator : ${totalpages ?: 100}
5. A GSPhas ability for invoking methods through Grails dynamic tags which makes it easier to produce well-formed markup:<!– With a regular tag

   1 2 3 4

   <!-- With a regular tag --> <a href="<g:createLink action="list" />">Click here</a> <!-- As a method call --> <a href="${createLink(action:'list')}">Click here</a>

6. Creating and testing custom tag libraries using GSP are very easier then JSP since there is no need for developer to code tld files and taglib declarations.

Basic Setup

1. Install Java SDK 1.4 or above and set the JAVA_HOME environment variable to the location of that SDK.

The minimum required version of the SDK depends on which version of Grails you are using:

• Java SDK 1.4+ for Grails 1.0.x and 1.1.x

• Java SDK 1.5+ for Grails 1.2 or greater

• Download the latest Grails release and set the GRAILS_HOME and Path environment variable to the extracted archive folder and Grails bin folder respectively.
• An integrated development environment like NetBeans 6.5 or above, Eclipse 3.1 or above and plugins has to be download, IntelliJ IDEA, or UltraEdit.

A Simple Example for rendering different outputs to an HTML page

1
2
3
4
5
6
7
8
9
10
11
12

<html>
	<head>
		<title>GSP</title>
	</head>
	<body>
		Welcome!
		<% print 'Welcome!' %> ------------> print method
		<% out << 'Welcome' %> ------------> out object
		<%= '!' %> ------------> Scriplet
		${'Welcome!'} ------------> GString (Groovy String) style 
	</body>
</html>

Output:

Comments

There are three ways of commenting code in GSP.

• HTML Style: The code commented using this style will be seen in source code as well as data will be sent to browser, but its impact over the output will be disabled.
  Example:<!– out <<code–!>
• JSP Style: It can be used for commenting a single line of code.
  Example:
  <%– out <<code –%>
• GSP Style: It can be used for commenting larger/multiple block of code.
  Example:
  %{– code –}%

Variables and Scope

A user can declare variable with in a Scriplet block in this manner: <% vname %> and the same can be accessed using <%= vname %>.

Please note: vname indicates variable name.

Example to declare a variable of date category can be done like this <%d = new Date() %> and to access the same we can use <%= d %>.

Predefined Variables and Scope

• request: This variable can be used as one of argument for invoking other service methods like doGet, doPost, etc.. of underlying Servlet in the project since this variable is the instance of HttpServletRequest interface which extends ServletRequest interface to provide request information for HTTP Servlets.
• response: This variable is the instance of HttpServletResponse interface which extends ServletResponse interface and can be
  used for sending HTTP specific response for other service methods like doGet, doPost, etc… This variable can also access different methods of HTTP cookies and header information of web application.
• out: This variable is the instance of responeWriter and can be used for sending response to output stream.
• session: This variable is the instance of HttpSession and can be used for maintaining history of the visitor of that web-site since a unique id per visit is maintained for every web application.
• params: Is a map object which can be used for retrieving request parameters.
• flash: Is a temporary storage map object which can be used for working with flash scope. It maintains key value pairs within session which points to next request value and this value will be cleared out once the request is executed by an application.
• application: It defines a set of methods for communicating with Servlet container through a Servlet. It is instance of
  javax.servlet.ServletContext.
• applicationContext: Is the instance of Spring ApplicationContext which extends ListableBeanFactory, HierarchicalBeanFactory, MessageSource, ApplicationEventPublisher, ResourcePatternResolver classes to provide configuration for an application. This object is read-only but can be reloaded if needed.
• grailsApplication:This object is the instance of GrailsApplication which extends ApplicationContextAware class
  and can be used to analysis artifacts of Grails Application since user can
  access metadata i.e., information regarding controllers, domain classes etc..
• webRequest: Is instance of GrailsWebRequest.

Looping

Looping in GSP can be achieved in two ways.

• By Embedding code between Scriplet i.e.., <% %>. For
  example consider a scenario where user wants to iterate through a list of two values i.e., User1 and User2 then same can be achieved through below mentioned sample code :

• 1 2 3 4 5 6 7 8

  <html> <head> <title> GSP </title></head> <body> <% ["User1",User2""].each { num -> %> <p><%="Welcome ${num}!" %></p> <%}%> </body> </html>

Output:

• Logical Branching is another way for looping.
  For example if the user wants to compare two variable values then the same can be
  done as mentioned below.

  1 2 3 4 5 6 7 8 9 10 11 12 13

  <html> <head > <title> Looping Branching</title> </head> <body> <% def a =10 %> ------------> declaring variable can be done by 'def' also. <% def b =20 %> <% if (a==b) %> the given numbers are equal <% else %> the given numbers are not equal </body> </html>

Output:

Page Directives:

By default all the JSP page directives are supported by GSP and user are provided with facility for creating their own tags according to the requirement by using GSP Tags. The import directive can be used for importing the necessary classes into a page but by default all the Groovy and GSP tags are available.
<%@page
import =’groovy.sql.Sql’ %>
The contentType directive allows response to render to any other format than HTML i.e.., output can be render as a plain text or XML format.
<%@page
contentType=’text/html; charset=UTF-8 %>

Scripting:

A multiple line/block of code can be enclosed between Scriplet i.e.., <% ……. %>.

A Sample example of Scripting:

1
2
3
4
5
6
7
8

<head>
<title>Scriptlet Demo</title>
</head>
<body>
<% def var = 'test'
if (var == 'test') out<< 'scriptlet demo' %>
</body>
</html>

Output:

Conclusion:

This article is all about basic concepts of Groovy Server Pages (GSP) and explain concepts like Output Rendering, Comments, Variable declarations, Predefined Variables as well as Scope, Looping, Page directives and Scripting with the related demos.

• Buy Groovy Books in Java Books Store

What This Book Covers

Chapter 1, Introduction to DSL and Groovy, discusses how DSLs can be used in place of
general-purpose languages to represent different parts of a system. You will see how
adding DSLs to your applications can open up the development process to other
stakeholders in the development process. You’ll also see how, in extreme cases, the
stakeholders themselves can even become co-developers of the system by using DSLs
that let them represent their domain expertise in code.

Chapter 2, Groovy Quick Start, covers a whistle-stop tour of the Groovy language. It also
touches on most of the significant features of the language as a part of this tour.

Chapter 3, Groovy Closures, covers closures in some depth. It covers all of the important
aspects of working with closures. You can explore the various ways to call a closure and
the means of passing parameters. You will see how to pass closures as parameters to
methods, and how this construct can allow us to add miniDSL syntax to our code.

Chapter 4, Example DSL: GeeTwitter, focuses on how we can start with an existing Javabased
APiand evolve it into a simple user-friendly DSL that can be used by almost
anybody. You’ll learn the importance of removing boilerplate code and how you can
structure our DSL in such a way that the boilerplate is invisible to our DSL users.

Chapter 5, Power Groovy DSL Features, covers all of the important features of the
Groovy language, and looks in depth at how some of these features can be applied to
developing DSLs.

Chapter 6, Existing Groovy DSLs, discusses some existing Groovy DSLs that are in
current use and are free to download.

Chapter 7, Building a Builder, explains how Groovy provides two useful support classes
that make it much simpler to implement our own builders than if we use the MOP. You’ll
see how to use BuilderSupport and FactoryBuilderSupport to create our own
builder classes.

Chapter 8, Implementing a Rules DSL, takes a look at Groovy bindings to see how they
can be used in our DSL scripts. By placing closures strategically in the binding, you can
emulate named blocks of code. You can also provide built-in methods and other
shorthand by including closures and named Boolean values in the binding. These
techniques can be used to a great effect to write DSL scripts that can be read and
understood by stakeholders outside of the programming audience.

Chapter 9, Integrating it all, covers the many different ways in which you can integrate
Groovy code into Java. You’ll explore the issues around tightly integrating the two
languages at compile time. You’ll see how this can lead to dependency issues arising
when Java code references Groovy classes and vice versa. You’ll take a look at how you
can use dependency injection frameworks like Spring to resolve some of these issues.

Building a Builder

Builders are a powerful feature of Groovy. The Groovy libraries contain an
expanding set of Builders for everything from XML and HTML markup to managing
systems via JMX. Even so you will always come across circumstances where the
semantics of a builder would be useful in your own application.

We’ve seen how to build a rudimentary builder by using the Groovy MOP and
pretended methods in Chapter 5. Thankfully, the Groovy libraries provide us with
easier means of developing our own builders. In this chapter, we will look at some of
the ways in which we can use Groovy and the MOP to create our own builder classes.

• To begin with, we will recap the Groovy features that enable the Groovy
  builder pattern in order to understand how they work.


• We will look at how to build a rudimentary builder with features from the
  Groovy MOP.


• We will implement our own database seed data Builder by using two of
  the builder support classes provided in Groovy: BuilderSupport and
  FactoryBuilderSupport.

Builder code structure

The real beauty of Groovy‘s builder paradigm is the way in which it maps the
naturally nested block structure of the language to the construction process.
The process of defining parent-child relationships between objects through nested
code blocks is well-established through other markup languages, such as
XML and HTML.

The transition from writing XML or HTML to the GroovyMarkup equivalent
is an easy one. To make use of a builder, we don’t need to have any intimate
understanding of the Groovy MOP or of how the builder is implemented. We
just need to know how to write the builder code so that it conforms to the correct
language semantics. The code structure of the builder pattern relies on just a few
Groovy language features.

• Closure method calls: The distinctively nested block structure in the builder
  pattern is facilitated by Groovy‘s special handling of closures when they are
  passed as method parameters. This allows the closure block to be declared
  inline after the other method call parameters.


• Closure method resolution: When a method is invoked within the body of a
  closure and that method does not exist in the closure instance, Groovy uses
  a resolve strategy to determine which object (if any) should be tried to locate
  that method.


• Pretended methods: The Groovy MOP allows us to respond to method
  calls that do not exist in a class—in other words to “pretend” that these
  methods exist.


• Named parameters: When we pass a map parameter to a method, we can
  declare the individual map elements alongside the other method parameters,
  giving the effect of a named parameter list.


• Closure delegate: Changing the delegate of a closure allows another class to
  handle its method calls. When we change the delegate to a builder class, this
  allows the builder to orchestrate how the method calls are handled.

Closure method calls

When we declare a Groovy method that accepts a closure as its last parameter,
Groovy allows us to define the body of the inline closure immediately after the
method call containing the other parameters. A method call followed by an inline
closure block has all the appearance of being a named block of code. It’s when we
nest these method calls within each other that we get the distinctive builder-style
code blocks.

This style of coding is not unique to builders. We can nest other method calls in
the same way. In the following example, we have three methods defined within a
script: method1(), method2(), and method3(). Nesting calls to these methods gives us
some code that is very similar to a builder block, but is not actually a builder block.
The cool thing about the builder pattern is that it uses this existing feature from the
language and turns it into a whole new coding paradigm.

The success of building our own b uilder class by using the Groovy MOP depends
largely o n understanding the sequence in which these methods get called. The
output gives us an idea of what might be happening and what the true sequence of
events is. Let’s decorate the code a little to show what is happening. The comments
show what scope we are running in.

	// Script scope

	method1(param: “one”) { // Closure1 scope

		method2 { // Closure2 scope

			method3 “hello”

		} // End Closure2

		method1( 123 ) { // Closure3 scope

			method1 ( “nested” ) { // Closure4 scope

				method3 10

			} // End Closure4

		} // End Closure3

	} // End Closure1

The main block of code runs within the scope of the script. Each inline closure is in
fact an anonymous instance of a C losure object. For the purpose of this exercise we
will name these instances Closure1 to Closure4. The first call to m ethod1() occurs
in the outer scope of the script so we would expect this method to be passed to the
script instance. The subsequent method calls all happen within the scope of one or
other of the anonymous closure instances, so we expect these methods to be invoked
on the individual closure instances. The following sequence diagram illustrates this:

Resolve Strategy: OWNER_FIRST

The one problem with the previous diagram is that we know that the closure
instances don’t implement the method1() t o method3() methods. So this sequence
diagram shows what methods are initially called, but it does not show what methods
actually get called. When Groovy makes a call to a method on a closure, it does not
always expect it to be present.

If a method is not present in the closure itself, Groovy will try to find it by looking
in the owner of the closure, or its delegate, or both. The order in which this occurs
is called the resolve strategy of the closure. The default resolve strategy is OWNER_
FIRST, which means that the owner of the closure will be queried first for the
method, followed by the delegate. If the owner of the closure happens to be another
closure, then the resolve strategy will continue its search for a match in the owner of
the owner and so on, until a match is found or the outer scope is reached.

	The resolve strategy can be changed for a closure by calling

	Closure.setResolveStrategy. We can change the resolve strategy to

	any of the following self-explanatory strategies: OWNER_FIRST, OWNER_

	ONLY, DELEGATE_FIRST, DELEGATE_ONLY, and NONE.

Although the preceding sequence diagram refl ects the first port of call for e ach
method invocation, what in fact happens is that the resolve strategy kicks in and
the method calls will percolate out through the closure instances. A match will
eventually be found in the script instance, which is the only place where the actual
methods exist. Therefore, the actual calling sequence is better represented as follows:

The insight that Groovy designers had when designing the builder pattern was that
this natural nesting of closures could be used to map to any construction process that
involved a parent-child type of relationship. Even without using a builder class, we
can nest closures’ method calls to create a pseudo builder. In the next example, we
declare three methods that we can use to construct a rudimentary tree structure out
of map objects.

The root() method creates the initial tree map and inserts a root element into it. We
can nest as many levels deep as we like with the nod e() method, as it will remember
its parent node and add sub nodes to it. The leaf() method is the only one to take a
value and it does not expect to be passed a closure, as it will create the leaf elements
in the tree structure.

	def current

	def root (Closure closure) {

		def tree = [:]

		def root = [:]

		tree["root"] = root

		def parent = current

		current = root

		closure.call()

		current = parent

		return tree

	}

	def node (key, Closure closure) {

		def node = [:]

		current[key] = node

		def parent = current

		current = node

		closure.call()

		current = parent

	}

	def leaf (key, value ) {

		current[key] = value

	}

	// pseudo builder code

	def tree = root {

		node (“sub-tree-1″) {

			leaf “leaf-1″, “leaf object 1″

		}

		node (“sub-tree-2″){

			node (“node-1″){

				leaf “leaf-2″, “leaf object 2″

			}

		}

	}

	assert tree == [

		root: [

			"sub-tree-1": [

				"leaf-1": "leaf object 1"

			],

			“sub-tree-2″: [

				"node-1": [

					"leaf-2": "leaf object 2"

				]

			]

		]

	]

Pretended methods

Many Groovy builders rely on the ability to describe arbitrarily-named elements.
When we make use of markup builders to generate XML, we need to be able to
insert whatever tag names are required to conform to the schema that we are using.
Given that elements are created in method calls, we also need to be able to make
arbitrarily- named method calls during the markup process.

With Groovy, we can respond to methods that don’t exist as concrete methods of
a class. The term we use for this type of methods is pretended methods. Groovy
provides two means for implementing a pretended method.

invokeMethod

The PoorMansTagBuilder class that we covered in Chapter 5 uses invokeMethod as
a means of pretending methods. The Poo rMansTagBuilder class works by handling
all method calls to the builder, and invoking the closure argument manually. With
invokeMethod, we can respond appropriately to any arbitrary method call. In this
case, we output the appropriate XML tags.

	class PoorMansTagBuilder {

		int indent = 0

		Object invokeMethod(String name, Object args) {

			indent.times {print ” “}

			println “<${name}>”

			indent++

			args[0].delegate = this // Change delegate to the builder

			args[0].call()

			indent–

			indent.times {print ” “}

			println “</${name}>”

		}

	}

This is a simple case that we are using just to illustrate the mechanism. Although the
technique works for simple cases, extending it to implement a more complete
tag builder would rapidly result in complex and hard-to-maintain code.

methodMissing

Since Groovy 1.5, an alternative to invokeMethod was provided. The
methodMissing mechanism differs slightly from invokeMethod, as it is only called
when a method call fails to be dispatched to any concrete method. To update the
PoorMansTagBuilder for using methodMissing instead of invokeMethod, all we
need to do is replace the method name that we declare.

	class PoorMansTagBuilder {

		int indent = 0

		def methodMissing(String name, args) {

			indent.times {print ” “}

			println “<${name}>”

			indent++

			args[0].delegate = this // Change delegate to the builder

			args[0].call()

			indent–

			indent.times {print ” “}

			println “</${name}>”

		}

	}

	def builder = new PoorMansTagBuilder ()

	builder.root {

		level1{

			level2 {

			}

		}

	}

Closure delegate

Earlier, we looked at how to code a pseudo builder using, methods declared within
a script. The resolve strategy in that example passed method calls in the nested
closure up to the owner of the closure. The builder block in the previous example is
also in the scope of a script. Let’s decorate it as we did before, to identify the various
anonymous closure instances.

	// method root() called on PoorMansTagBuilder

	builder.root { // Closure1

		// method level1 called on Closure1 instance

		level1{ // Closure2

			// method level2 called on Closure2 instance

			level2 { // Closure3

			}

		}

	}

The first method call to root() is made against the builder instance, so it will be
handled directly by Poo rMansTagBuilder.methodMissing(). Nested method
calls will first be dispatched to the enclosing closure. The lev el1() and lev el2()
methods won’t be found in the closure instances, so we would normally expect the
resolve strategy to dispatch these methods up the chain of owners until a method
is found. This normal dispatch chain would end up at the script instance, so these
methods would cause a MethodMissingException to be thrown.

The secret of how this works is in the handling of the delegate for closure instances.
The builder block starts with a direct method call onto the builder instance, builder.
root(). Anonymous closure, Closure1, is passed as a par ameter. The call to root()
will fail and fall through to methodMissing. In this simple example, arg[0] is
always the closure because we are not processing parameters on our tags. A more
sophisticated version would need to scan the parameters for the closure instance.

At this point we have access to the closure, so we can set its delegate to the builder
instance. Now when the level1() and level2() calls are encountered, the resolve
strategy will try the owner first and then try the delegate as follows:

• The level1() call will not be resolved in Closure1. It won’t be found
  in the owner of Closure1, which is the script, but it will be resolved in
  the delegate,which is the builder instance. PoorMansTagBuilder.
  methodMissing will field the method and also set the delegate for the
  anonymous closure, Closure2.


• The level2() call ha ppens in the scope of Closure2 but will not be resolved
  there. First its owner, Closure1, will be tried, and then its delegate, which
  once again is the builder instance.

Groovy Articles

• Buy Groovy Books in Java Books Store
• Introduction to Groovy – Scripting Language
• Groovy Articles
• Closures in Groovy
• Web Development in Groovy using Groovlets

In this article, let us look into one of the important features supported in Groovy, the Closures. Groovy is an object-oriented scripting language in which the syntax resembles Java. Not all languages support the concept of Closures directly, although they may provide indirect support, that too with so many limitations and restrictions. This article will make you familiar with the concepts of Closures and will provide considerable amount of code snippets to make the understanding clearer. This article assumes that the reader is having sufficient knowledge in Groovy Programming and first-time readers may look into the Introductory Article on Groovy before proceeding with this article.

2) Closures

To say in simple words, a Closure definition is a block of code that can be re-used any number of times. The definition may look more or less like the definition of a function or a method. A Closure resembles a function or a method in many aspects, however there are subtle differences between them. For example, a Closure may take any number of arguments like a function. A Closure has a return value like a method. A closure can be re-used and referenced any number of times and anywhere similar to a method.

It is clear that a Closure is very similar to a function in many aspects, but the difference is that a Closure can be passed as an argument to a function. A programming language like Java supports similar kind of Closures through anonymous Inner classes. For example, consider the following piece of code,

Button button = new Button();
button.addActionListener(new ActionListener(){
    public void actionPerformed(ActionEvent actionEvent)
    {
        // Do something here.
    }
});

In the above code, the method Button.addActionListener() will take an argument of type ActionListener. We have defined something which is of type ActionListener and has included a method actionPerformed() within it. This type cannot be used elsewhere in the code since we don’t have any reference to it. One possible way to re-use the reference is to have something like the following,

ActionListener actionListener = new ActionListener(){
    public void actionPerformed(ActionEvent actionEvent)
    {
        // Do something here.
    }
};

Button button = new Button();
button.addActionListener(actionListener);

To understand the need to have Closures, let us analyze the situation in this way. You have some simple piece of logic (such as printing the state of an object) and you want this logic to be re-used by some common group of objects. The more traditional way to arrive at the solution for this problem is to define a method with suitable argument list and then to call this method. However, in an object-oriented programming language like Java, methods doesn’t exist on their own. They have to be embedded within a class. It doesn’t look nice to create a new type (in the form of a class) and to embed a simple behavior in the form of a method. This is where Closures come in. They are simply a named type for some set of statements containing some useful logic. The named type can then be re-used any number of times.

The same problem exists with callbacks. Classes with the design of call-backs in mind, usually have a well-defined interface along with methods. And the client application (or the caller) has to define an implementation class conforming to the interface which often results in defining new types. This will result in the many smaller classes in the Application. One form of solution to these kind of problems is manifested in the form of Closures.

3) Groovy Closures

3.1) Simple Closures

Let us look into the syntax for defining and making use of Closures. The syntax of a closure definition looks like this,

ClosureName =
{
    Parameter List ->

    Set of statements.
}

The syntax is simple (although it may not look like that at the very first glance). Let us get into the example. If we want to define a closure called 'helloClosure', then we can define something like this,

helloClosure =
{
    println "Hello";
}

Note that in the above definition, the closure name is 'helloClosure' and since we don’t want this closure to accept any parameters, we have left the list of parameters that should follow after the brace '{' as blank. Next follows the block section which may contain any number of statements.

Let us look into the following sample,

SimpleClosure.java

public class SimpleClosure
{
    def testClosure =
    {
        println "Test Closure";
    }

    public static void main(String[] args)
    {
        ClosureTest object = new ClosureTest();
        object.testClosure();
    }
}

We have defined a closure called 'testClosure' with the 'def' (meaning for definition) keyword. This closure doesn’t accept any arguments. Simply defining the closure doesn’t provide any purpose unless someone calls that explicitly. In the main method, we have created an object for the class 'SimpleClosure' and have invoked the closure 'testClosure' in function-like syntax.

3.2) Closures with Arguments

In this section, let us see how to define Closures that takes arguments. As we have already seen, Closures, like functions may take any number of arguments. For example, consider the following code snippet,

ClosureWithArguments.java

public class ClosureWithArguments
{
    def addClosure =
    {
        int one, int two ->

        println "Number one is " + one;
        println "Number two is " + two;
        return one + two;
    }

    public static void main(String[] args)
    {
        ClosureWithArguments object = new ClosureWithArguments();
        def result = object.addClosure(10, 20);
        println "Result from closure is " + result;

        result = object.addClosure(130, 230);
        println "Result from closure is " + result;
    }
}

In the above code, we have defined a closure called 'addClosure'. Note the parameter list (int one, int two) that is following after the brace '{'. Following that is the symbol ‘->’ which is used as a separator between the parameter list and the set of statements to follow. The code prints the arguments passed to this function before returning the result.

The caller (main method) calls this Closure using the same function-like syntax passing two arguments.

3.3) Different ways of calling a Closure

We have seen how to invoke or call a Closure in the above sections. For example, if the Closure Name is 'myClosure', then this closure can be invoked through the expressioin 'myClosure()'.

CallingClosures.java

public class CallingClosures
{
    def testClosure =
    {
        println "Test Closure";
    }

    public static void main(String[] args)
    {
        CallingClosures object = new CallingClosures();
        object.testClosure();
        object.testClosure.call();
        object.testClosure.doCall();
    }
}

However, there are other alternative ways of calling a Closure as mentioned above. Every closure has default methods (implicit methods, so no need to declare them) namely call() and doCall() so we can also call the closures in this manner.

3.4) The Closure class

It should be noted that all Closure definitions will be resolved to some Java class at run-time. So all Closures are just like any other objects. And it is not surprising that the class name of such closure objects seems to be 'Closure'. It means that the following code will work fine.

ClosureClassTest.java

public class ClosureClassTest
{
    def testClosure =
    {
        println "Test Closure";
    }

    public static void main(String[] args)
    {
        ClosureClassTest object = new ClosureClassTest ();

        Closure closureObjectForTest = object.testClosure;
        closureObjectForTest();
        closureObjectForTest.call();
        closureObjectForTest.doCall();
    }
}

The above code tries to assign the closure 'testClosure' to the object 'closureObjectForTest' which is of type 'Closure'. This is perfectly legal, since all Closure objects are of type 'Closure'.

3.5) Closure Currying

At times, we may need to create multiple number of Closure objects whose argument lists to some extent will be similar. For example, consider the following Closure 'getNoOfRuns' which takes two arguments, one is the name of the country and the other one being the name of the player. And we wish to make Closure calls four times with the following values,

• Country-> India, PlayerName-> Sachin
• Country-> India, PlayerName-> Ganguly
• Country-> Pakistan, PlayerName-> Afridi
• Country-> Pakistan, PlayerName-> Salman

Examine the first two set of invocations. Both are taking the value 'India' as the first argument. And in the 3rd and the 4th invocation, the argument value 'Pakistan' is common. Now, analyze the following code where we will see a better way of making invocations to the Closure.

ClosureCurrying.java

class ClosureCurrying
{

    def getNoOfRuns =
    {
        String country, String playerName ->

        if (country.equals("India"))
        {
            if (playerName.equals("Sachin"))
            {
                return 15806;
            }
            else if (playerName.equals("Ganguly"))
            {
                return 11319;
            }
        }
        else if (country.equals("Pakistan"))
        {
            if (playerName.equals("Afridi"))
            {
                return 5226;
            }
            else if (playerName.equals("Salman"))
            {
                return 1159;
            }
        }
        return -1;
    }

    public static void main(String[] args)
    {
        ClosureCurrying object = new ClosureCurrying();

        def indianTeam = object.getNoOfRuns.curry("India");

        def result = indianTeam("Sachin");
        println "No. of runs scored by Sachin " + result;

        result = indianTeam("Ganguly");
        println "No. of runs scored by Ganguly " + result;

        def pakistanTeam = object.getNoOfRuns.curry("Pakistan");

        result = pakistanTeam("Afridi");
        println "No. of runs scored by Afridi " + result;

        result = pakistanTeam("Salman");
        println "No. of runs scored by Salman " + result;
    }
}

We have referenced the Closure 'getNoOfRuns' and has called the method 'curry()' on that with the value 'India' as its argument. Let us imagine that the method 'curry()' will create a new object with the countryName being set to 'India'. Now if want to get the number of runs for the player 'Sachin', then simply invoke the Curried Closure (the Closure that was obtained after calling the 'curry()' method) with the value 'Sachin'. The same applies for 'Ganguly' and for the rest of the players.

3.6) Closures as Arguments to another Functions

Till now, we have seen how to define and call Closures. In this section, we will see how to pass a Closure as an argument to some other function. Consider the following code snippet,

PassingClosuresTest.java

class PassingClosuresTest
{

    def testClosure =
    {
        println "Test Closure";
    }

    void acceptClosure(Closure closure)
    {
        closure.call();
    }

    public static void main(String[] args)
    {
        PassingClosuresTest object =
            new PassingClosuresTest();
        Closure closureObject = object.testClosure;
        object.acceptClosure(closureObject);
    }
}

In the above sample, we have defined a Closure called 'testClosure' and have defined another method which is taking an argument of type 'Closure'. In the main method, we have assigned the 'testClosure' to the object 'closureObject' which is of type 'Closure' and the same is passed to the method 'acceptClosure()' method.

3.7) Making use of Closures

In this section, let us make use of Closures being passed as arguments. For example, consider the following Class which wraps the string array objects. The decorate() method accepts an argument of type 'Closure'. The logic within the method iterates over the strings and the Closure being passed as argument to this method is invoked by passing the iterated resultant string object itself as argument.

DecoratedStringArrayClosureTest.java

class DecoratedStringArrayClosureTest
{
    def strs = null;
    public DecoratedStringArrayClosureTest(def strs)
    {
        this.strs = strs;
    }

    public void decorate(Closure closure)
    {
        for (String temp in strs)
        {
            closure.call(temp);
        }
    }

    def DecoratedClosure =
    {
        String element ->
        println "##" + element + "##";
    }

    public static void main(String[] args)
    {
        def numbers = ["one", "two", "three"];
        DecoratedStringArrayClosureTest object =
            new DecoratedStringArrayClosureTest(numbers);

        Closure decoratedClosureObject = object.DecoratedClosure;
        object.decorate(decoratedClosureObject);
    }
}

The Decorated Closure decorates the string passed to it by surrounding the string with ‘#’ symbols.

4) Conclusion

In this article, we understand the need for Closures and saw how Closures stand as a better replacement for defining a new type even for simpler cases. We also dealt in detail about the various usage cases of Closures in Groovy Scripting Language along with plenty of code samples.

The following are some of the popular articles published in Javabeat. Also you can refer the list of groovy articles and groovy books from our website. Please read the articles and post your feedback about the quality of the content.

• Creating JSON using Groovy
• Introduction to Groovy Server Pages (GSP)
• Introduction to groovy

If you are looking to buy a book, please consider buying Beginning Groovy and Grails: From Novice to Professional.

If you are interested in receiving the future java articles from us, please subscribe here.

In this article, we will learn about how to achieve Web Development using Groovy. Groovy is a scripting language and it has components called Groovlets which sit on top of a Web Server for handling HTTP Requests and Responses similar to Java Servlets. This article will provide an overview about Groovlets in the first section and will present several code snippets that will help in simplifying the usage of Groovlets in the subsequent sections. Remember, this is not an introductory article on Groovy and first-time readers are strongly advised to have a look over the Introductory article on Groovy .

2) Groovlets

Before getting into Groovlets, let us look into the basics of a typical Java Web Application. Usually a Web Server will host one or more Web Applications and the Client’s Requests are handled by Components called Java Servlets which usually sit on top of the Web Server. A Servlet continue to live within the Web Server’s address space and its life-time will be controlled only by the Web Server. One of the major responsibilities of a Web Server is to match a client request to a particular Servlet in an Application. Typically, this is done in the Application’s configuration file, usually web.xml file.

So a Java Servlet can be considered as an extension point which provides some useful services to a Client. The Web Server wraps the Client request and passes a Http Request object to the Servlet. The Servlet retrieves various inputs from the Client and executes some actions accordingly. A Servlet is written in pure Java code and one can see a mix of Java Business logic as well as Html UI Generation in a Servlet.

Now, let us see the Java Servlet’s counterpart, Groovlets. Groovlets, or Groovy Pages that end with .groovy extension are processed by Groovy Engine which sits on top of a Web Server. Typically, a Groovy Engine is nothing but a Groovy Servlet. When a client requests for a Groovy page for the very first time, the Groovy Servlet will be invoked (we will configure this in the Application’s descriptor file) and parses the page to convert into a Java class or a Java Servlet. The Java Servlet is then compiled and an instance of the class will be created by the Web Server. Groovlets are much suitable only for simpler or small Web Applications. Compared to Java Servlets, coding in Groovy will be much simpler.

In the next few sections, we will see how to develop Groovlets or Groovy pages.

3) Developing a Simple Groovlet

In this section, we will see how to write a simple static Groovlet. By the word static, we mean that this Groovlet doesn’t provide any dynamic content upon request. Instead it will provide a simple Html page back to the Client Browser.

Let us look into the sample code,

test.groovy

html.html
{
    head
    {
        title 'Groovy Test'
    }
    body
    {
        h1 'Groovy page called'
    }
}

Save the above file as test.groovy and deploy the file in a Web Application. For testing purpose, Tomcat Web Container can be used which is running the Groovlet. Make sure that you follow the J2EE standard directory structure for packaging the Web Application.

web.xml

<?xml version="1.0" encoding="UTF-8"?>

<web-app>

    <servlet>
        <servlet-name>GroovyServlet</servlet-name>
        <servlet-class>groovy.servlet.GroovyServlet</servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>GroovyServlet</servlet-name>
        <url-pattern>*.groovy</url-pattern>
    </servlet-mapping>

</web-app>

The above listing is the deployment descriptor file for the Application. This Deployment Descriptor has two sections. One is the declaration of the Servlet and the other provides the mapping information to call the Groovy Servlet.

</p>

<servlet>
    <servlet-name>GroovyServlet</servlet-name>
    <servlet-class>groovy.servlet.GroovyServlet</servlet-class>
</servlet>

The above code snippet declares the Groovy Servlet with the name 'GroovyServlet'. Note that the 'servlet-class' tag should point to the fully qualified name of the Servlet, in this case it happens to 'groovy.servlet.GroovyServlet'. Don’t forget to add the library classes (groovy-all-1.0.jar, which comes as part of the Groovy Distribution).

Now, consider the following code snippet,

</p>

<servlet-mapping>
    <servlet-name>GroovyServlet</servlet-name>
    <url-pattern>*.groovy</url-pattern>
</servlet-mapping>

This declaration basically defines a mapping. A mapping generally specifies ‘the type of Request to be handled by the corresponding components’. In the above code snippet, we define the url pattern of the request in the tag 'url-pattern' as '*.groovy'. It means that the request that matches this URL pattern will be handled by the Groovy Servlet.

Before jumping into the next section, let us analyse the code in test.groovy. The test.groovy file looked like this,

test.groovy

html.html
{
    head
    {
        title 'Groovy Test'
    }
    body
    {
        h1 'Groovy page called'
    }
}

In Groovy, there are Components called Builders, which stands as the base for building the target. For example, a variant of Builder called Xml Builder can be used to populate XML contents in a file. Similarly, Html Builder can generate Html files. Other notable Builders in Groovy are Ant Builders and Swing Builders which are used to construct Build files and Swing Components respectively.

In our above code, we have used Html builder for populating Html contents which is to be served shortly to the clients. For the above test.groovy, the equivalent generated Html code would be,

</p>

<html>

    <head>
        <title>Groovy Test</title>
    </head>

    <body>
        <H1>Groovy page called</H1>
    </body>

</html>

4) Groovlet displaying Request Information

In this section, we will develop a Groovlet which will display the various request information supplied by the clients. Parallely, we will use the various implicit objects that are available. These implicit objects will be bound to some classes in the Java Servlet API. The following objects are the various commonly used implicit objects that are readily available and can be used in a Groovy Page.

• application, context –> Maps to javax.servlet.ServletContext
• session –> Maps to javax.servlet.HttpSession
• request –> Maps to javax.servlet.HttpServlet
• response –> Maps to javax.servlet.HttpResponse
• out –> Maps to response.getWriter()

RequestInfo.groovy

html.html()
{
    head()
    {
        title 'Request Information'
    }
    body()
    {
        table(border : "2")
        {
            tr()
            {
                td("Authentication Type");
                td("${request.getAuthType()}");
            }

            tr()
            {
                td("Context Path");
                td("${request.getContextPath()}");
            }

            tr()
            {
                td("HTTP Method");
                td("${request.getMethod()}");
            }

            tr()
            {
                td("Path Info ");
                td("${request.getPathInfo()}");
            }
        }
    }
}

In the above file RequestInfo.groovy, we have again made use of Groovy Builder classes for generating the Html output. Note that for building an Html element that involves attributes, we have use the following syntax,

</p>

(attrName : attrValue).

For example, in the above code, if we wish to set the 'border' attribute for the table tag as 2, then the same has to be mentioned as,

</p>

table(border : "2")

We have decorated the output by embedding the content in a simple Html table. Watch carefully for how we have taken the request information. We have used a simple scripting for the same. For example, consider the following script,

</p>

${request.getPathInfo()

Here, the symbol 'request' maps to the HttpServletRequest object and getPathInfo() can be treated as a method in the class HttpServletRequest. ${Symbol} is the value for the expression. The equivalent Html code is given below,

</p>

<html>
    <head>
        <title>Request Information</title>
    </head>

    <body>
        <table border='2'>
            <tr>
                <td>Authentication Type</td>
                <td>null</td>
            </tr>

            <tr>
                <td>Context Path</td>
                <td>/Groovy-Groovlets</td>
            </tr>

            <tr>
                <td>HTTP Method</td>
                <td>GET</td>
            </tr>

            <tr>
                <td>Path Info </td>
                <td>null</td>
            </tr>

        </table>
    </body>
</html>

5) Handling Form Requests

In the final section, we will see how to use Groovlets for form submission. As a simple example, let us develop a simple Login form that contains the username/password text-fields along with a submit button. The following code is an example for the same,

Login.groovy

html.html()
{
    head()
    {
        title 'Login Form'
    }
    body()
    {
        form(method : 'GET' , action : 'LoginAction.groovy')
        {
            tr()
            {
                td("Firstname:")
                input(type : 'text' , name : 'username')
            }

            tr()
            {
                td("Password:")
                input(type : 'password' ,  name : 'password')
            }

            tr()
            {
                input(type : 'submit')
            }
        }
    }
}

Note that when the user clicks the form to submit the values, we want some other Groovlet to be called with some appropriate request type. We have achieved the same in the form tag as follows,

</p>

form(method : 'GET' , action : 'LoginAction.groovy')

The above form tag details that when this form is submitted, the Groovlet 'LoginAction.groovy' will be called as pointed by the 'action' attribute with GET as the request type. Following is the complete code listing for 'LoginAction.groovy'.

LoginAction.groovy

html.html()
{
    head()
    {
        title 'Welcome Page'
    }
    body()
    {
        String username = request.getParameter('username');
        String password = request.getParameter('password');

        if ((username.equals('guest')) && (password.equals('guest')) )
        {
            h1 "Welcome guest"
        }
        else
        {
            h1 "Unknown user"
        }
    }
}

In the above Groovlet, the request values containing the username and password are taken and appropriate message is displayed depending on their values. It is always possible to compile Groovy code with that of Java code similar to the one we have seen in the above example.

6) Conclusion

This article provided a basic introduction on how to carry out Web Development programming in Groovy. It discussed about the Servlet counterpart that is available in Groovy, which are termed as Groovlets. The later sections on the article concentrated on writing various Groovlets, that display a simple html file to the user, displaying the request information along with form submission.

The following are some of the popular articles published in Javabeat. Also you can refer the list of groovy articles and groovy books from our website. Please read the articles and post your feedback about the quality of the content.

• Creating JSON using Groovy
• Introduction to Groovy Server Pages (GSP)
• Introduction to groovy

If you are looking to buy a book, please consider buying Beginning Groovy and Grails: From Novice to Professional.

If you are interested in receiving the future java articles from us, please subscribe here.