« previous 1 2

Grails may use Rails' conventions but under the hood, a different philosophy is at work. As a comparison, let's look at how they handle databases. They both use 'model' classes to define persistent objects, validation rules and relationships; in Grails they are called "domain classes". Underneath, Rails uses ActiveRecord to map these classes to an SQL database with ActiveRecord doing all the SQL generation. Grails 1.0 has GORM (Grails Object Relational Mapper) to do this mapping. GORM is actually a thick wrapper around Hibernate 3, the de facto standard in Java object/relational mapping, thus offloading the SQL generation to a solid Java based library. This pattern is repeated throughout Grails; Rails functionality is implemented using well known Java libraries, but delivered in the Rails style.

Running Grails in a terminal

The work flow also differs. Take the development mode and how databases are populated. In Rails, the models are derived from from tables already created in a database using Rails migrations into an embedded SQLite3 database. In Grails, there are no migrations as standard. The database tables are created based completely on the domain classes when the application runs, into an in-memory HSQLDB database. To pre-load data into the database, you add some code to the BootStrap.groovy file to create some data when the application starts (Or you can just switch to a persistent database by editing the DataSource.groovy file).

It is different, but the overall process of iteratively building your application is essentially retained. You can still run your application in development mode, make changes to your code, and see them reflected in the running application. You can still use scaffolding to create quick dynamically created controllers with just one line of code. You can still call on a library of plugins to add capabilities to your application with a simple command. You can still easily write and run unit and functional tests.

Grails targets Java application servers; from being able to locate a database via JNDI to having a single command take your application and package it in a war file ready for deployment, making it easy to integrate into existing Java infrastructure. The JNDI locating is new to Grails 1.0, as is GORM, filters (to allow you to inject code across controllers), automatic XML and JSON unmarshalling and content negotiation to allow you to return XML, HTML or JSON as appropriate to a browser request.

Viewing a Box

Grails 1.0 does have rough edges though; error messages can be obscure and carry with them lengthy stack traces, making debugging less friendly than it could be. IDE integration is generally a work-in-progress; Eclipse, NetBeans and IDEA all have differing levels of support, though they are all usable. At the same time, working at the command line with TextMate (the editor much used by Rails folk) Grails bundle is quite a pleasant experience, and the actual Grails documentation is extensive, so you can become productive quickly.

Grails isn't alone in bringing the Rails experience to Java. JRuby allows the Java VM to run Ruby and by extension Rails, with only minor differences, like using JDBC for databases, and supports most Rails plugins. If you are wanting to host Ruby applications on Java application servers, JRuby on Rails is the path of least resistance, but if you are coming from Java then Groovy on Grails brings the dynamic/agile advantages, without you discarding your existing Java application stack.

« previous 1 2