Grails Web FrameWork - Sapient

Grails Web Framework

ANCE 1

ANCE 2

An Evaluation Based on Firsthand Implementation Experience Rajeshkumar I.P

ANCE 3

A Sapient Case Study © Sapient Corporation 2013

1

Contents 1. Executive Summary

3

2. Getting to Know Grails

3

2.1. Putting Grails to the Test

4

2.1.1 Consideration #1: Ramp-up and Set-up

4

2.1.2 Consideration #2: Scaffolding and Template Support

5

2.1.3 Consideration #3: Java Interoperability

6

2.1.4 Consideration #4: Validation Support

7

2.1.5 Consideration #5: Plugins and Tag Lib Support

8

2.1.6 Consideration #6: GORM

9

3. Design Considerations

9

3.1.1 Best Practices

9

3.1.2 Design Patterns

11

3.1.3 Issues and Pitfalls 4. Benefits of Using Grails

12-13 14

4.1. Time to Market

15

4.2. Cost Reduction

15

5. When to Use Grails

16-17

6. Comparison and Adoption

17-18

7. Grails and Groovy: Looking to the Future

19

8. Conclusion

20

9. References

20

Grails Web Framework: An Evaluation Based on Firsthand Implementation Experience

2

1. Executive Summary The market is awash in Java web frameworks, each claiming to be better than the next. The goal of this paper is not to assess which framework is superior. Rather, the intent is to share firsthand experience in using one particular framework: Grails and its programming language, Groovy. To that end, this paper discusses the framework in the context of real-world application—highlighting advantages, challenges and pitfalls, as well as exploring the framework’s long-term potential.

2. Getting to Know Grails Grails is a next-generation Java web development framework that generates great developer productivity gains through the confluence of a dynamic language, a convention over configuration philosophy, powerfully pragmatic supporting tools, and an agile perspective drawn from the best emerging web development paradigms. Grails is an Open Source, full stack, web application framework for the Java Virtual Machine (JVM). It takes advantage of the Groovy programming language and convention over configuration to provide a productive and streamlined development experience.

Grails is a full stack framework that attempts to solve as many pieces of the web development puzzle through the core technology and its associated plugins. Grails as a framework has not reinvented the wheel, but instead has leveraged the already tried and trusted frameworks such as Spring, Hibernate, Sitemesh and other open source libraries already popular in the enterprise Java world. Grails’ model-view-controller (MVC) is an abstraction built over Spring MVC. The Grails persistence framework, GORM, is an abstraction built over Hibernate. Implementing most Java web frameworks can be tedious—requiring extensive time to edit configuration files, customize web context files, write injection definitions, modify page layouts, build scripts and restart apps following each change. These tasks consume the majority of the developer’s time at the expense of tackling the real business problem and functional requirements.

The below diagram depicts the Grails architecture.

Grails Architecture Grails Java EE

Spring

Java Programming Language

Hibernate

Sitemesh

Java Development Kit (JDK)

Java Virtual Machine

Groovy

By contrast, Grails offers the best of the available Java web frameworks while shielding the developer from the noisy configuration, design complexity and boilerplate code that make existing Java web development so cumbersome and inefficient. In short, Grails allows the developer to focus time implementing features, not editing XML, while also providing a productive, streamlined development experience.

A Sapient Case Study © Sapient Corporation 2013

3

2.1. Putting Grails to the Test

2.1.1 Consideration #1: Ramp-up and Set-up

An investment banking company engaged Sapient Global Markets to develop a reference data application in support of its commingled investment vehicles (funds/ pools). The client required an application with these high-level features:

Key requirement: “The team has no experience with Grails. Won’t a lot of time be lost in ramping up and getting the application wired?”

• Intuitive and simple set-up to maintain reference data in terms of structure and attributes with View/ Add/Edit functionality. • Integration and interoperability with legacy Java Struts 1.x application, deploying them together as one application. • Dynamic validation and mandatory check for fields/ attributes driven by specific rules. • Dynamic fetching of attribute values from different applications on pre-conditions. • Audit/history functionalities. • Search, change status and notifications. • Entitlements at each field and page level depending on roles and responsibilities. The Sapient team took a close look at Grails—addressing a number of considerations and requirements and ultimately determining that it would be a viable Java web framework for this client application.

Grails Web Framework: An Evaluation Based on Firsthand Implementation Experience

All the developers on the team have a pure Java web development background, so this represented their first experience working on Grails. Even so, ramping up on Grails did not involve a huge learning curve. The Sapient developers were able to ramp up on the Grails framework and Groovy language easily and quickly: • The Grails core is built on the already proven Spring MVC and Hibernate framework. Thus, the developers found it easy to understand the “nuts and bolts” of the framework. • As an object-oriented programming language, Groovy is similar to Java; Java developers were able to learn the language easily. Since Grails makes use of convention over configuration, it generates all the boilerplate shell code. It thereby avoids all unnecessary XML configuration and design complexity developers face when using other Java web frameworks, such as Spring MVC. With Grails, Sapient’s developers were up and running—and productive—quickly.

4

2.1.2 Consideration #2: Scaffolding and Template Support Key requirement: “We have around 80 Create/Edit/View pages in the application, with approximately 30 to 40 attributes/fields per screen. How will we ensure we are not repeating the effort so we can design these pages more efficiently?” Grails offers “scaffolding,” which lets the developer autogenerate views and controller actions for Create/Read/ Update/Delete (CRUD) for any given domain class. Grails provide two types of scaffolding: dynamic and static. Dynamic Scaffolding Dynamic scaffolding is achieved by enabling the scaffold property to “true” in the controller (assuming that the controller follows the same naming convention as the domain class). In cases where the domain names are different, it is necessary to specify the name of the domain to the scaffold property. class POVController { static scaffold = true } With this configuration, if the application is now started, it will auto-implement all the CRUD-related actions within the controller and also generate the respective views. Static Scaffolding With static scaffolding, Grails allows the developer to generate a controller and the views used to create the user interface from the command line. This can be achieved by running the “grails generate-* ” command.

In a real-world scenario, the default scaffolding templates would not suffice as each application would demand a specific structure and look and feel for the user interface. Fortunately, Grails remains true to its don’t-repeat-yourself (DRY) philosophy, providing an ability to customize the default scaffolding templates. Some of the steps required for customizing templates include: 1. Run the “install-template” command. 2. This copies the templates Grails uses for all code generation to the application’s “src/templates” directory. 3. You can then customize the copied template directly or make a copy of it and customize the copy per your requirement. Grails also provides an excellent plugin called “Spawn plugin” that allows you to denote a specific template for a domain class. This way you can have multiple templates within your application and assign them to whichever domain class you would like to use them with for scaffolding. In this case, the developers created three customized scaffolding templates—one for Create, another for View and the third for Edit/Update—and generated respective views and controllers for a given domain using the spawn plugin. Doing so ensured a consistent structure, look and feel, easy maintainability for all the user interface/views across the application, and saved about 60 percent of development time—hours that otherwise would have been spent writing it by hand.

Both of these use the default templates, which come bundled with Grails, to generate the view and controllers for a particular domain. Static scaffolding is beneficial when working to build a prototype, test an idea or create an admin interface.

A Sapient Case Study © Sapient Corporation 2013

5

2.1.3 Consideration #3: Java Interoperability Key requirement: “We already have an existing application developed in Struts 1.x. Although it is currently deployed as a separate application, we now need it to coexist with the new reference data application. Can we integrate the applications without migrating the legacy application to the Grails framework?” This challenge was complex, introducing the following requirements:

Grails provides a Struts1 plugin, which Sapient developers used to bundle the Struts and Grails applications. Further, the team was able to render either the Struts or Grails application with the help of URL filters. Able to complete this integration very easily and efficiently, the team saved a great amount of time and effort that would not have been avoided if using any other Java framework. What follows are some of the steps required as part of the integration:

• Both the Struts and Grails frameworks would have to coexist as a single application.

1 Copy Struts Java source files from \ source\java to \src\java

• It would be bundled as one Web Application Archive (WAR) and deployed as one application on a Tomcat web container.

2 Copy all folders (except WEB-INF & META-INF) from \source\WebApplication into \web-app

• Depending on the request URI, the web container would route the request to either of the frameworks and then load the respective pages.

3 Copy all TLDs and XMLs (except web.xm) from out