Friday, April 28, 2006

Grails: Interview on JavaPosse

There is a podcast interview with yours truely up on JavaPosse discussing my experiences with Groovy, what makes it so powerful and how Grails fits into the bigger picture of J2EE development.

Thanks to Dick and all the JavaPosse guys for taking their time out to chat to me, it was a most enjoyable experience.

PS I was a bit nervous in the beginning and I think it shows!

Monday, April 24, 2006

Grails: Ruby on Rails feeling the heat

Up until now I have not wanted to be drawn into a Grails vs Rails debate, clearly not wanting to start a flame war with the Ruby community, but it seems the Ruby/Rails people are doing that job perfectly well without my intervention and feel rather threatened by Grails as they keep bringing it up in interviews and comments on blogs.

In the latest podcast on the Ruby on Rails website they have an interview up with Tim Bray. They talk about Rails and the future of dynamic languages, and they brought up the topic of Grails in which the interviewer said and I quote:

"I heard that some guys had done a Groovy on Rails or Grails framework and didn't quite get it right."

Now, I encourage said interviewer to qualify his statement and point me to a reference where it says we havn't got it quite right. Clearly, you havn't tried Grails my dear boy and making such statements without the facts to back you up is really rather silly, and typical of the response from the Ruby community.

I follow all Grails news quite closely and not one user has said we havn't got it right in fact all the users on our mailing list that have taken up Grails feel we have got it very right with comments like Grails is "The Holy Grail" of Java web development and that its productivity is on par with Rails and for Java developers even more so because they can fully utilise their existing API knowledge.

So far there has yet to be a negative post about Grails from a Java developer, I'm sure there will be one, but I'm still waiting.. so the question is: are the Rails people feeling the heat?

The fact that they even mentioned Grails in this interview and have not mentioned any other Rails-like frameworks is a sign that they are worried and they should be. Grails takes Java integration to a new level. A level that will never be reached by the likes on JRuby on Rails, which really only serves as a useful proof-of-concept.

Good luck guys, Grails may have only just had a 0.1 release, but it has a growing following, greater integration with Java and an aggresive project plan and for the first time you have real competition.

Tuesday, April 18, 2006

Grails: The Render method and Ajax

Users of Ruby on Rails will be familiar with the 'render' method which allows rendering of responses from a controller. Grails has a similar mechanism, for example rendering text is as simple as:

render 'hello world!'

You can of course also render templates and views via the method (for more complete documentation see here), but what makes Grails' render method that little bit different is its support for markup building.

With other Java frameworks I've used I ended up with loads of partial views implemented as JSP or velocity views. Each with the sole responsibility of rendering some XML or JSON. With Grails this is rarely needed for pure XML responses (note, I would never condone defining layout in this way this is purely for data oriented XML rendering). Rendering XML is made infinitely more simple:

def results = Book.list()
render(contentType:'text/xml') {
books {
for(b in results) {

The above results in the following XML snippet being rendered to the response:

<book title="The Shining" />
<book title="Along came a Spider" />

When you combine this with how Grails controllers reload automatically on changing it makes writing ajax responses a breeze. But, there is more! Grails has inbuilt support for OpenRico so if you want to write Ajax responses in Ricos required format this can be done as follows:

render(builder:'rico') {
object(id:'bookUpdater') {
books {
for(b in results) {

Rico will then automatically look-up your 'bookUpdater' instance and delegate the response to it passing the contained XML to the updater for handling.

I don't normally like talking about unimplemented features, but thought it might be worthwhile just to highlight the power of the builder concept in Groovy as I don't believe that many grasp the potential of builders and their usages. One of the upcoming features in Grails is a JSON builder which will be available via the render method so say I wanted to render JSON instead of XML? We just change the content type defined in the render method:

render(contentType:'text/json') {
books {
for(b in results) {

And the resulting output would be JSON instead of the XML without any change to the structure of the builder code itself:

books : [
{ title: 'The Shining' },
{ title: 'Along came a spider' }

Monday, April 17, 2006 Live

Thanks to John Wilson of the Groovy development team who was on the ball enough to snap up the domain when it became available Grails has a new web home at!

Grails: Getting Started on Oracle 10g

Just got back from my easter break with the family and its great to see such fantastic tutorials being posted about Grails already including this one on how to get Grails up and running with Oracle 10g Express Edition.

Not only does it go through how to setup the database side of things, but it also talks you through deployment on OracleAS via a Grails WAR and improved deployment options. Great stuff.

Monday, April 03, 2006

Grails: Tag Libraries & The Power of Closures

When we started developing Grails we wanted to support a dynamic view technology that allowed scriptlets in Groovy instead of Java, but without falling into the trap of having scriptlets intermingled with HTML code a trap that many Java developers have spent years trying to avoid.

Historically though JSP custom tags have always been a bit of a pain to write, they're designed to cover every variation of tag under the sun, hence the API is complicated and the tag lib descriptors verbose. Grails is all about simplicity, so how do we avoid introducing this level of complexity into our Grails applications. The answer came in the form of anonymous code blocks or closures.

I would say 90% of the tags that are written for JSP out there fall into one of three categories: simple, logical or iterative. There are those more complex tags that have relationships to each other via nesting, but the vast majority are of the aforementioned type and Grails is about making the most common cases easy, but still allowing the flexibility to scale to the more complex (thats why we still support JSP).

So what have closures done to make custom tags easier? Well Grails allows you to define a custom tag as a JavaBean property. No descriptors, no configuration, and everything is reloaded at runtime so no need to restart that application server. So lets look at an example from the tag library that ships with Grails (simplified for clarity):

class ValidationTagLib {
@Property eachError = { attrs, body ->
def errors = attrs.bean.errors
if(errors) {
errors.each { body(it) }

Each tag library is simply a class that ends with the convention "TagLib". The above example contains an "eachError" tag that loops through each error contained within the "bean" attribute and invokes the "body" of the tag. Note how the body of the tag itself is a closure and hence callable, the attributes are a map. To use this tag we simple call it from our GSP no need to import the tag library or anything, the error itself is available using Groovy's implicit 'it' variable which was passed to the body closure:

<g:eachError bean="${myBean}">
<p style="color:red;">${it.defaultMessage}</p>
</g:eachError >

Now thats pretty neat and simplistic, but this is where using closures for defining tags becomes really powerful. How about we want to re-use our "eachError" tag else where? Say we want to implement a default rendering tag called "renderErrors" that renders our errors as an HTML list. Well we can re-use the "eachErrors" tag to accomplish this:

@Property renderErrors = { attrs, body ->
def markup = new groovy.xml.MarkupBuilder(out)
markup.ul() {
eachError(attrs) { err ->
li( message(code:err.code) )

The above code creates a new MarkupBuilder instance which is used to generate an HTML list re-using the eachError tag defined previously, it actually uses a third Grails tag called "message" to retrieve the message for the error code. To call the "renderErrors" tag we simply do:

<g:renderErrors bean="${myBean}"/>

Grails users can of course customise the inbuilt tags and add brand new ones simply by adding new tag library classes in the "grails-app/taglib" directory. So there you have it, custom tags have never been easier, and your markup can remain scriptlet free without the need to invest huge amounts of time creating a custom JSP tag library.