Saturday, June 28, 2008

Book Review: Groovy Recipes

I just finished reading Groovy Recipes book by Scott Davis so I would like to share my opinion about the book. Book is excellent "I'am in a Hurry" guide and you can get initial, but good enough knowledge about Groovy in a really short time. For sure it is not comprehensive guide to Groovy.

If you are Java developer and want to jump on Groovy wagon fast this book is excellent start. You will get introduction into Groovy and be able to use Groovy immediately as you finish with the book or related chapter of the book.

For those who have no knowledge about Java or Groovy I would not recommend this as a first book about Groovy. Even it is not stated that way, I believe that book expects at least some knowledge of Java.

The main minus for the book are poorly described closures. I believe that closures are really important part of the Groovy language and would expect better explanation. If you have no knowledge about Groovy closures, read some articles on the web to gain more knowledge about them.

Book is divided into 12 chapters.

Chapters 1 and 2 are introductory chapters describing in general what is Groovy, how to install it and how to integrated with the most popular IDEs.

Chapter 3 is dedicated to "special" (no Java like) constructs of language where you will learn about autoboxing, operator overloading...

Chapter 4 describes how to integrate Java and Groovy and vice versa. You will learn how to compile Groovy code to Java classes and how to solve some possible tricky dependencies issues.

In Chapter 5 you will see how you can use Groovy from the command line.

Chapter 6 is very interesting and you will see how easy it is to work with files within Groovy. This chapter is very useful for Java developers because they would ask themselves why Java file handling cannot be as easy. In Groovy you can read content of the file, you can list content of the file literally with the line of code.

Chapter 7 and 8 are even bigger "wows" for the Java developers. These chapters describe how Groovy handles XML. You will learn how to read XML file with XmlSlurper and XmlParser and how to create XML with MarkupBuilder and StreamingMarkupBuilder. For those that are used to to work with XML in Java this chapter will be proof that working with the XMLs need not to be painful.

Chapter 9 is devoted to web services and there is very nice introduction to different types of requests like: http get, post, SOAP request, XML-RPC request and others.

Chapter 10 is about metaprogramming. Metaprogramming is dynamic part of the Groovy language and the Groovy language option that make Grails so good web development framework. This is the chapter I liked the most.

Chapters 11 and 12 introduce Grails, web development framework based on Groovy.

Monday, June 16, 2008

Tag Cloud Added to Grails Tutorials

I have added tag cloud to Now each tutorial can be tagged so navigation is possible also by tags.

The main difference between tag cloud on grails tutorials compared to tag cloud on other sites is that it is enough to be logged in to change (add/remove) tags on any tutorial.

So far there is no possibility to add new tags, you have to reuse precreated set, but if there will be interest I plan to add this possibility too.

For tag cloud implementation I used Act As Taggable Plugin
This plugin give you boost at the beginning but from my point of view still misses lot of support functionality that I had to implement. I hope that in next days I will be able to organize code I implemented for tag cloud features and provide it to 'act as taggable plugin'. This way everybody can reuse what I had implemented and don't have to reimplement the same thing again.

If time permits me for sure I will write at least one post about tag cloud implementation on grails tutorials.

If you have any ideas or proposals for grails tutorials please let me know. I would be happy to have more responses from those who visit

Tuesday, June 10, 2008

Tweaking Star Rating component of RichUI Grails plugin

RichUI plugin for Grails is easy to use with number of interesting Ajax enabled components. One of the components is Star Rating component. Core behavior of this component is good but I wanted to get a little bit more than this core behavior. This component works fine out of the box. You click on the star, go to server, update rating and update number of stars assigned. And everything is executed without reloading the whole page. But what I wanted to achieve is also to update number of votes within the same Ajax request. And this is not supported by component. I checked the code of this component and found out that this can be achieved with really only few lines of code. Actually solution is so simple that maybe it would be good if it is included into the official plugin code. And all described in this post you can of course see live on the grails tutorials site.

So to make more clear what I am talking about have a look on the picture.


Idea is that when you click on the star, number of votes is increased also without necessity to reload the whole page. And this is not possible with the current star rating component.

Right place to start searching what to change is RatingRenderer.groovy file. This class is responsible for rendering the star rating component.

Signature of method is

protected void renderTagContent(Map attrs, GroovyPageTagBody body, MarkupBuilder builder)
where attrs are attributes sent to the component from the gsp page. And after some code inspection it is clear that update is implemented using remoteFunction grails tag. To see more about remoteFunction read this post. One of the parameters to remoteFunction is also name of the element in the gsp page to update. Line of the code in RatingRenderer.groovy that accomplish this is
String link =":class:", "r${i}-unit rater").replace(":title:", "$i").replace("update", "${id}").replace("number", "$i").replace("%3Arating%3A", "${i}")

and for us interesting part is replace("update",${id}). And id to update is automatically generated in the first line of method. So actually, all we need to be able to update any page element, not exactly only stars, is to provide alternate id instead of one automatically generated.

So all I changed is following:

String updateId = id
if (attrs.updateId) {
updateId = attrs.updateId
String link =":class:", "r${i}-unit rater").replace(":title:", "$i").replace("update", "${updateId}").replace("number", "$i").replace("%3Arating%3A", "${i}")

This way if I provide updateId attribute to the star rating component, remote function generated by this component will update page element with provided id, otherwise it will keep original behavior.

And now, all I have to do is to use construct like this one in my gsp pages:

<div id="${tutorialid}tutorial">
<richui:rating dynamic="true" updateId="${tutorialid}tutorial" id="${tutorialid}" units="5" rating="${rating}" showCurrent="true" controller="rating" action="rate" />
${rate?.votes} votes; ${clicks} clicks

And of course previous code snippet is part of the grails template so during rendition necessary values are read from the provided model.

So only with three lines of code added to existing plugin code and one change to existing plugin code, star rating component is more powerful than the original one.

Wasn't that easy? ;)

Thursday, June 5, 2008 now supports RSS, Star Rating and Click Count

After few days of other responsibilities I had found some free time and additionally to star rating and click count I have added also support for RSS feeds. To see and try the latest features visit

During development of RSS feeds and star rating I have hit some not too complicated but interesting problems and challenges. I will write separate posts about those challenges.

And as usually, just to remind you, register and post interesting links.

In the case of any feature requests, bugs or just comments do not hesitate to comment to this post.

Sunday, June 1, 2008

Make gsp readable with grails templates and taglibs

In one of my previous post I already explained how grails templates and taglibs can simplify your gsp files and make them more readable. Now I believe I made even step further. One of the reasons I like grails is that front end technology is solved very good and is easy to understand even for java back-end developers like me. My gsp files does not look like html files but more like collection of components. The reason is simple. With grails it is very easy to create templates and tags. Example in this post is taken from, portal of grails and groovy community on which I work in my free time. Let me try to explain mind flow. I wanted to display components like one on the picture in common and easy to read way.


The first solution that came to my mind was really simple. Thing like this one you can solve easily in this way:

<div class="messageBox">
<div class="msg_box_title">
<div class="msg_box_body">

But in the sea of the divs it is really hard to orientate and the gsp looks more complicated than it really is. So I start thinking how it would be nicer. And I realized that what I want to achieve so my code is easier to read is following:

<g:messageBox title="TITLE_HERE">

So as the first thing I created message box template.

<div class="messageBox">
<div class="msg_box_title">
<div class="msg_box_body">

This code is almost the same as the first code. Important things to notice are model variables ${title} and ${body}. Now when I had a template I needed possibility to display it with the messageBox tag. So the next thing to create was to create tag. Just create simple tag file, if you don't know how read the post mentioned at the begging. And the code of the tag is:

def messageBox = {attrs, body ->
out << render(template:"/templates/common/messageBoxTemplate", model:[title:attrs.title, body:body()])

The only good thing to notice in the code above is usage of body() as a value of body model parameter instead of body that came as a input value into messageBox. Reason for this is that we don't want to send body closure to the template but content of the body closure.

Having messageBox tag available, the first code example in this post can be specified in the gsp file as:

<g:messageBox title="TITLE_HERE">

exactly as we wanted.

Now let us think about CONTET_HERE part. If we put complex gsp code there we will not get too much in readability. But solution is very simple. Don't use complex gsp code there, create corresponding template and tag for that part and you gsp code will be easy for reading. Just to give you example of what I have in mind, this is code snippet I use in to display statistics (you can see the picture on the top of post):

<g:messageBox title="Stats">

I believe that the final result is really easy to understand.