Exploring Grails is very much like exploring Rails. This is not unexpected as Grails was modelled on Rails. The obvious major difference is in the language being used. Rails uses Ruby while Grails uses Groovy. Groovy is also a dynamic language like Ruby or Python; however, its syntax is close to Java syntax so that the Java programmers should be very comfortable with it (http://en.wikipedia.org/wiki/Groovy_%28programming_language%29). The major advantage is that it “seamlessly integrates with all existing Java classes and libraries”. Furthermore, it “compiles straight to Java bytecode so you can use it anywhere you can use Java”. (http://groovy.codehaus.org/)

Advantages of Groovy with Java get carried forward to Grails. Hence, Grails is a very attractive option for organisations which are already using Java applications. J2ee applications are very common in major corporates. By adapting Grails, j2ee users can gain advantages of agile development methodologies.

But how easy would it be to enhance existing applications or code with modules written in Grails?

The first possibility is that we may wish to use an existing database. However, Grails starts with the definition of domain classes which are translated into a relational database using the object relational mapping api (GORM). GORM is a thin layer on top of hibernate.

Existing Databases

If we wish to use an existing database, we need to need to create the domain classes as per the existing database. The following tutorial explains the possibilities - https://www.ibm.com/developerworks/java/library/j-grails07158/. One can work with the relational database, hibernate or EJB3's.

An interesting solution is to use the database to create a CRUD application using Grails Application Generator ( http://grag.sourceforge.net/ )

Amarok music player uses Mysql database. So, I decided to experiment with GRAG on the database used by amarok. I selected a few tables related to tracks from the database and created the grails application. It just creates the domain classes. Creating the controllers resulted in very uninteresting application as the relationship between the various tables was not modelled.

I went back to GRAG and after selecting the tables, I defined the relationship between the tables and then generated the domain classes. The results were far more interesting, particularly with bi-directional relations. One could create an album and add tracks to it. Or explore tracks and get information about the album.

The default locking mechanism is optimistic as in the case of hibernate. The version property assumes significance in this context. Since an existing database may not have the version column, it may be necessary to use pessimistic locking explicitly where needed.

Views

The default layout of the scaffold is quite usable. There is an option to generate views, which will generate the groovy server pages(gsp) for the list, create, edit and show options. These can be modified for creating customised views.

As we would expect, gsp can use custom jsp tags. Gsp uses the '<% %>' syntax for variables, script code, expressions etc, which makes it similar to jsp and rhtml.

However, gsp also includes tags, like jstl. The tags built into gsp are specified as '<g:example />' and are the preferred way to use gsp. Additional tags can be easily implemented using groovy. This style is also similar to the Zope's TAL.

For Ajax, grails ships and uses the Prototype and Scriptaculous libraries by default. However, it can use alternate libraries like Dojo, Yahoo UI or GWT by using plug-ins. Grails tags like remoteLink, formRemote and submitToRemote for Ajax will use the appropriate javascript library.

For layout, grails also uses Sitemesh (http://www.opensymphony.com/sitemesh/) to decorate the views - “SiteMesh is a web-page layout and decoration framework and web- application integration framework to aid in creating large sites consisting of many pages for which a consistent look/feel, navigation and layout scheme is required.”

Hence, ensuring a reasonable consistency of look and feel between a grails application and the traditional j2ee application should not be difficult.

URL's

The structure of the url is 'controller/action/id'. Controller is a class. Action is a method in the class. Id would normally identify the domain object. As we might expect, the url mapping is controlled by a script, UrlMappings.groovy, and one does not have to use the default settings. This again can be useful when integrating with existing j2ee applications.

We have briefly surveyed the possibilities with Grails. A wide range of tutorials and documentation is available for exploring it in depth. A priori, Grails would appear to be an excellent option for j2ee shops to add new capabilities to their environment using agile development methodologies.

Users are impatient, competition is fierce and cost of missed opportunities is high. It is worth taking a look at http://www.grails.org/Testimonials and, perhaps, there is an opportunity for your organisation.