Introduction
In the late '90s I was working on a project developing large-scale enterprise learning management systems using early J2EE technologies such as EJB 1.0 and the Servlet framework. The Java hype machine was in full swing, and references to "EJB that, and Java this" were on the cover of every major IT publication.
Even though what we were doing—and learning as we did it—felt so horribly wrong, the industry kept telling us we were doing the right thing. EJB was going to solve all our problems, and servlets (even without a view technology at the time) were the right thing to use. My, how times have changed.
Nowadays, Java and J2EE are long-forgotten buzzwords, and the hype machine is throwing other complex acronyms at us such as SOA and ESB. In my experience, developers are on a continued mission to write less code. The monolithic J2EE specifications, like those adopted by the development community in the early days, didn't help. If a framework or a specification is overly complex and requires you to write reams of repetitive code, it should be an immediate big red flag. Why did we have to write so much repetitive boilerplate code? Surely there was a better way.
In the end, developers often influence the direction of technology more than they know. Why do so many developers favor REST over SOAP for web services? Or Hibernate over EJB for persistence? Or Spring over JNDI for Inversion of Control? In the end, simplicity often wins the day.
Certainly, working with Spring and Hibernate feels a lot better than traditional J2EE approaches; in fact, I strove to use them whenever possible, usually in combination with Web-Work, and delivered a number of successful projects with this stack. Nevertheless, I still felt I had to deal with the surrounding infrastructural issues and configuration, rather than the problem at hand. After all, the more efficient I could be as a developer when doing "real" work, the more time I would have to do what should be driving every developer: spending time with loved ones and learning new and exciting technologies.
In 2003, Groovy entered the picture. I had always been fond of looser rules governing dynamic languages in certain contexts, having worked extensively with Perl, Visual Basic, and JavaScript in the past, and after quickly hacking the WebWork source code, I was able to write MVC controllers (or actions in WebWork lingo) with Groovy in no time.
Groovy was perfect for controllers whose sole responsibility should be to delegate to business logic implemented by a service and then display an appropriate view. I was starting to have even more time for the good things in life. Then came the storm of dynamic language– based frameworks led by Ruby on Rails.
Unfortunately, it was all a little late. Java, the community, the tools, the frameworks, and the mind share are well-embedded. The size that Java has grown to is quite staggering, and having been in the training business for many years, I see it showing no signs of slowing, contrary to popular belief. Still, Java has its problems, and I wanted to write less code. Grails was born with this goal in mind in the summer of 2005 after I, Steven Devijver, and Guillaume Laforge kicked off a discussion about its conception on the Groovy mailing list.
Fundamentally, there is nothing at all wrong with many of the specifications that form part of J2EE. They are, however, at a rather low level of abstraction. Frameworks such as Struts, WebWork, and more recently JSF have tried to resolve this issue; however, Java and its static typing don't help. Groovy, on the other hand, allows that higher level of abstraction. Having used it for controllers, it was now time to take it to every layer—from controllers to tag libraries and from persistence to the view technology.
The APIs you can create with Groovy's metaprogramming support are amazingly simple and concise. Grails uses every single dynamic trick, at both runtime and compile time, from custom domain-specific languages to compile-time mixins, with two fundamental goals in mind: write less code and be Java friendly.
Are Groovy and Grails a replacement for Java, like other dynamic language frameworks? No, on the contrary, they're designed to work with Java. To embrace it. To have Java at their very core. Grails is Java through and through, and it allows you to pick and choose which features to implement with dynamic typing and which to entrust to the safer hands of static typing.
Grails was born from the realization that there is never only just one tool for the job. Grails is about providing an entry point for the trivial tasks, while still allowing the power and flexibility to harness the full Java platform when needed. I hope you enjoy the book as much as I have enjoyed writing it and being part of the Grails community.
—Graeme Rocher
Who This Book Is For
Grails forms just one framework that is driving the movement toward dynamic language–based frameworks. In this sense, anyone who is interested in dynamic languages, whether Perl, Ruby, or Python, will gain something from reading this book, if just to acquire insight into what the alternatives are.
If platform is not a choice and Java is the way your project is going, Grails can provide features like no other framework. In this circumstance, Grails may have the answers you are looking for. Primarily, however, this book will be of most benefit to those who know and love the Java platform—those who appreciate the Java language for all its strong points but want something better as a web framework.
Grails is providing the answers to the long search for something better in the Java world by presenting a framework that solves the common problems in an unobtrusive, elegant manner. But this does not mean that the subject matter of this book is trivial. We'll be challenging you with advanced usages of the Groovy language and real-world examples.
Furthermore, you'll be pushing the boundaries of what is possible with a dynamic language like Groovy, extending it into every tier of a typical web application from the view layer with Ajax-enabled technology to the persistence tier with rich domain models. For experienced Java developers, it should be an enlightening experience, because we'll explore features not found in Java such as closures, builders, and metaprogramming.
Through all this, however, although the subject matter and examples are advanced, the solutions are simple, and along the way you may learn a new way to approach web application development.
How This Book Is Structured
This book is divided into 17 chapters and one appendix. Unlike the first edition, coverage of Groovy is saved for the appendix. If you have no experience using Groovy, then it is recommended that you read the appendix first as the chapters themselves dive straight into Grails starting with Chapter 1, which covers the basic philosophy behind Grails.
In Chapter 2 we take you through a kick-start, demonstrating how you can quickly get productive with Grails. Then from Chapter 3 onward we delve into detailed coverage of each concept within Grails from domain classes in Chapter 3 to views in Chapter 5. By this point, you should have a good understanding of the basics.
The book will then dive straight into the nitty-gritty details of Grails in Chapter 6 with coverage of URL mappings, followed by the multilingual experience that is internationalization in Chapter 7. If you haven't had enough excitement by this point, then Chapter 8 should solve that with coverage of Grails' support for adaptive Ajax.
In Chapter 9 the book will begin to cover some of the more advanced features of Grails staring with Web Flow. In Chapter 10 you'll get a much better understanding of how GORM works, while in Chapter 11 you'll learn how to leverage declarative transactions with Grails services.
Chapter 12 goes into a lot of detail on how you can integrate Grails into your existing ecosystem; then in Chapter 13 you will get to become a Grails plugin developer as you explore the features offered by Grails' plugin system. Security is the focal point for Chapter 14, while in Chapter 15 we'll cover publishing web services with Grails.
Finally, Chapters 16 and 17 are dedicated to the more advanced topics of integrating Grails with the underlying Spring and Hibernate frameworks.
Conventions
This book uses a diverse range of languages, including HTML, XML, JavaScript, Groovy, and Java. Nonetheless, each example is introduced appropriately and appears in a fixed-width Courier font. We have also endeavored to be consistent in the use of naming conventions throughout the book, making the examples as clear as possible.
In many cases, the original source code has been reformatted to fit within the available page space, with additional line breaks and modified code indentation being common. To increase the clarity of the code, some examples omit code where it is seen as unnecessary. In cases where the code is omitted between two blocks of code, an ellipsis (...) is used to indicate where the missing code would have been.
Prerequisites
This book shows you how to install Grails; in the examples, we use the 1.1 release. As of this writing, the 1.1 release was not quite final, but by the time of publication, Grails 1.1 should be final (or nearly so). However, Grails itself is dependent on the existence of an installed Java Virtual Machine. As a minimum, you will need to install JDK 1.5 or newer for the examples in this book to work.
Installing an application server, such as Tomcat, and a database server, such as MySQL, is entirely optional, because Grails comes bundled with an embedded server and database. Nevertheless, to use Grails in production, you may at least want to set up a database server.
Downloading the Code
The code for the examples in this book is available in the Source Code section of the Apress web site at http://www.apress.com. Chapter-by-chapter source code is also available in the Code-haus Subversion repository at http://svn.codehaus.org/grails/trunk/samples/dgg.
Contacting the Authors
Graeme is an active member of the open source community and welcomes any comments and/or communication. You can reach him via e-mail at [email protected] or via his blog at http://graemerocher.blogspot.com. You can reach Jeff via e-mail at [email protected] or via his blog at http://javajeff.blogspot.com. Alternatively, you can simply pop a message on the Grails mailing lists, the details for which can be found here: http://grails.org/Mailing+lists.