The Angels Sang

The angels sang, no doubt about it. And it wasn't just a benign little "Aaaaah", it was like a full Mormon Tabernacle Choir sonate.

Man, I can't believe how impressed I am with Grails. Where on earth do these Grails developers find the time to implement all this stuff, for free?! Since my last post I've been tweaking the basic auto-generated scaffolding and code that Grails produces by itself. I've tidied up some error messages, which in itself was impressive in how Grails scaffolding builds validation and error notification automatically into form submission. Validation with the 'constraints' static object is very easy. Customising your error messages follows a class.action.constraint format, also - dead easy. You edit or add to a single messages.properties file and that's it.

And here it's worth mentioning the 'flash' context, which is something I'm not aware of in other Java web frameworks, but is also something borrowed from Rails. In Java you typically have page, request, session and application context. For short-lived objects, you usually place them in page or request context. Session is more long-lived, and application obviously is the longest lived in terms of web application object lifespan. Flash context slots in somewhere around page and request, in that while page and request contexts 'die' after a response has been made to the user, flash context lives until the next request. So it lives sort of from 'response - next request' and then Grails cleans it out. Why this is useful is because often, after you've completed a use case, you want to redirect your user to a different URL, not just simply forward them. With page and request context, anything you place in those contexts will be gone when the redirect request comes back. With flash however, objects placed in 'flash' context live until the redirect request is completed. I recall from past web applications, where something like that would have been useful. Giving a confirmation message with a redirect, for instance, is very useful. I can't recall off-hand but most likely I placed stuff like that in the session context and nuked it after the next request was done, which is probably similar to how it works in Grails, but I didn't have a formal concept for it; more like a stab in the dark.

Anyway, moving along. Adding taglibs is also very easy, and has a special place in a Grails application. The conciseness of Grails - or actually - Groovy code, is very convenient here too. I followed the book and created formatting taglibs to format my numeric, date and currency fields, and all within a minute or two. Of course, I was surprised that these tags weren't already in the core Grails taglibs, but hey, it's only v0.4 at the moment, so, baby steps.
This also bears mention of the GString (*snicker*) class which allows for transformation within a String. That probably doesn't make much sense, so allow me to copy and paste from the official Grails API docs:

Represents a String which contains embedded values such as "hello there ${user} how are you?" which can be evaluated lazily. Advanced users can iterate over the text and values to perform special processing, such as for performing SQL operations, the values can be substituted for ? and the actual value objects can be bound to a JDBC statement.

Can't deny some of that strikes fear into me - I mean linking a String to JDBC SQL operations just screams 'security hole', but I probably don't fully understand that definition. I'll be sure to investigate this more in the days to come. But it does mean you can do things like the transformation indicated in that definition, and determine the final value in real time.

Now, one thing that blew me away was how easy it was to setup search capabilities, using default search syntax for simple searches, but also integrating very intuitively with Hibernate's Criteria building. Here again, no XML files to configure, just fairly straight-forward, simple code and naming conventions.

The similarities of Grails to Rails are very obvious, and one can see the Grails developers have done a good job with this. I find myself understanding this book very quickly simply because of my understanding of Rails. Those of you who haven't ever read up on Rails may find some concepts confusing at first. So take my word for it, they are good ideas. Each controller action is defined by a closure, and convention over configuration means you don't have to tweak 2 or 3 XML files to add an action to your controller. View resolution is determined by your controller and action, and the brevity with which you can accomplish much is also a Rails testament.

Now if you're anything like me, you're probably thinking "Ok, all of this is cool, but honestly, this is not complex stuff, and all this proves is that Grails accomplishes simple goals, simply." True, very true, which is why it's reassuring to see that one of the headings of the next chapter, "Not Just For Intranet Apps", is "Beyond CRUD". This is where I add authentication to my application, with specific permissions to specific views etc. Stay tuned as I delve into the unknown.