Chapter 11 - AJAX and RIA Frameworks

With Grails built-in support for AJAX and the power supplied by the RichUI plugin, we are able to take the tagging framework implemented in the previous chapter to new heights. We add in-line editing of our tags, auto completion and a tag cloud.

The chapter begins with adding in-line editing. We learn that Grails uses the Prototype framework for the AJAX support. We are given an overview of the remoteLink and formRemote tags, including a table describing the attributes. After a discussion of the user actions and the controller actions that will be needed to handle those actions, we create a TaggableController implementing the requisite actions. We then move on to add a couple in-line forms that will be used to render the edit and show tags views. Next we make slight modifications to the _message.gsp and _file.gsp templates. Finally, we are instructed to add the prototype library to the main template. This was quick and simple.

From there we move on to the addition of auto-complete capabilities to our tag lookup, creation and editing. The author tells us that there are two plugins available: GrailsUI and RichUI. They both wrap the YUI auto-complete widget. Jon chooses to use the RichUI plug-in as it has more features than the GrailsUI plug-in and the default styling is more appropriate for the application. After installing the plug-in, we add two methods to the TaggableController: suggestTags and renderAsXml. The latter method is the more interesting of the two. It uses the render method, but instead of specifying a view or a template, a closure is specified. The closure is executed against the Groovy MarkupBuilder. Since this is a little difficult to conceptualize, Jon provides a concrete example. This is good, but, personally, I would have preferred to see it as a test or an assert at a minimum. Asserts are a great way to explore the language. At this point, we are introduced to two new tags provided by the autoComplete widget: resource:autoComplete and richUI:autoComplete. This is followed by a table describing the attributes available to the autoComplete tag. With this new found knowledge, we update the message create.gsp, the taggable editTagsForm template, the profile myTags view with the richUI:autoComplete tag. We are then directed to add the resource:autoComplete tag to the main layout head element. The author suggests booting up the application and testing the auto-complete feature at this point. Sure enough, it all works as desired.

Now we are able to add tag clouds. We get a brief discussion of just what a tag cloud is and a sample based upon the words contained in the chapter. We are also given reasons why adding a tag cloud makes sense. Again, we use capabilities provided by the RichUI plug-in. We are presented with a static example from the online plug-in documentation and are encouraged to place it into one of our pages and then view the page. As you would expect, we get a nice little cloud. This is made possible through the richUI:tagCloud tag. We are also provided a table describing the attributes for the tag. Most of the work involved in implementing the tag cloud comes in areas other than the actual rendering of it. We add method cloudData to the TagService class. We then update the MessageController by injecting tagService and contentService, modifying the list method, and adding a filterByTag method. The FileController is similarly modified, however there is a trick to list method. Here we use listDistinct method on the CriteriaBuilder. This is necessary, we are told, because Hibernate uses an outer join to perform eager featches on multiple cardinality relationships. Finally, we get to changing the message and file list views. These are simply the aforementioned richUI:tagCloud added to a div element. And, Presto! We have a tag cloud!

This chapter went very smoothly. There was only one small issue I found and was irrelevant. The chapter clearly demonstrates the power of plugins to make very user friendly interfaces.

Part 1 of this series can be seen here.
Part 2 of this series can be seen here.
Part 3 of this series can be seen here.
Part 4 of this series can be seen here.
Part 5 of this series can be seen here.
Part 6 of this series can be seen here.
Part 7 of this series can be seen here.
Part 8 of this series can be seen here.
Part 9 of this series can be seen here.
Part 10 of this series can be seen here.
Part 11 of this series can be seen here.

Shaun Jurgemeyer and I have been busy organizing the conference, a conference dedicated to Groovy, Grails, Griffon and other GR8 technologies.

We have contacted many Groovy and GR8 stars, including: Guillaume Laforge, Graeme Rocher, Burt Beckwith, Dierk Koenig, Chris Judd, Jim Shingler, Paul King, Robert Fischer, Scott Davis, Venkat Subramaniam, Jeff Brown and many others. Most have expressed strong interest in presenting at our event. Based upon the responses regarding their availability, we are targeting April 16, 2010 for the conference date. We are pretty sure of the venue, but need to work out some details, such as being able to expand the number of days, before we sign an agreement. Thus, the only reason the conference date is still tentative. This should be firmed up by early September.

Some people have questioned the wisdom of a single day conference. If we do get enough quality proposals, and there is enough interest in the community (i.e. paying attendees), we may expand to two days. I was one that initially advocated for a three day event. Since we began organizing the conference, Shaun and I have thought this through thoroughly. We concluded a one day, multi-track event is more likely to assure that we deliver on the twin goals of an excellent conference and low cost. Be sure that an excellent conference, defined by high satisfaction amongst the attendees with a large percentage wanting to come back the next year, is our top priority.

We hope to See you there!

Chapter 10 - Managing Content through Tagging

This chapter continues building the application by adding tagging capabilities. Achieving this requires that we learn how to work with inheritance in domain classes, understand the available GORM persistence strategies, and gain insight into polymorphic queries over domain inheritance hierarchies. We also need to use manage collections using collect and sort to get the behavior we want.

Initially we are given an overview of just what tagging is, and quickly move to a domain model needed to support tagging. After creating the initial model of Tag and Tagger, we create TagService. This provides methods for adding tags and is where we use the collect method. We are also shown the Elvis operator. A bit of trivia explains that the name for this operator comes from the fact that it looks Elvis' hair style. The author then has us write some integration tests to verify that all is working properly. We are required to implement further functionality in the Message class to make the tests pass.

After making changes and having the tests pass successfully, we turn our attention to tagging File classes. Here is where we learn GORM supports two of the several Hibernate inheritance persistence strategies, table-per-hierarchy and table-per-subclass. The former creates one table per hierarchy and is the Grails default. The latter creates one table for each class in the hierarchy. Table-per-hierarchy has a drawback; a number of columns will have to be nullable. To override the default behavior, we are told to add the mapping property to the parent domain as follows:

static mapping = { tablePerHierarchy false }

In order to implement tagging File objects, we re-examine the domain model and add a superclass to Message and File called Taggable. We then add another test and quickly discover that our tests fail. This is due to the fact that the polymorphic nature of our queries returns all Message and File objects with the given tag even though we think we are querying objects of the specific type. This is remedied by adding another method on the Taggable class, and adding nearly identical methods to Message and File that override the finder method on Taggable.

Once the domain and persistence logic is coded and tested, we move on to modifying the user interface. Jon discusses templating in Grails. In Grails, a template is the same as a GSP except that it is prefixed with and underscore. He shows the various ways templates are rendered and provides a warning regarding rendering a collection via the template. He states that we must be careful to pass in the actual collection by using the ${} notation.

As we closeout the chapter, we create another service, ContentService and make greater use of templating. The added templating allows either Message or File posts to be displayed interchangeably. These final touches allow us to create a homepage wherein the user can specify which tags are of interest. The view will display the five most recent updates, either messages or files, and the five most recent items of interest, again, either messages or files.

Throughout this chapter, there were few problems. In a few tests a user variable named fred is used that was not defined elsewhere, nor is the variable used in the book source. Again, as he has done in previous chapters, he references a view named post where none exists. And, he continues to unnecessarily use some optional things such as the access modifier public. These are all rather trivial issues.

Part 1 of this series can be seen here.
Part 2 of this series can be seen here.
Part 3 of this series can be seen here.
Part 4 of this series can be seen here.
Part 5 of this series can be seen here.
Part 6 of this series can be seen here.
Part 7 of this series can be seen here.
Part 8 of this series can be seen here.
Part 9 of this series can be seen here.
Part 10 of this series can be seen here.

Chapter 9 - Services

Grails provides a service layer to applications. Chapter 9 discusses the concept of services and through them, how to simplify our application. In this chapter we move logic out of the File controller and moving it into a service class, FileService. Doing so separates responsibility nicely, always an admirable goal. Thus, this chapter is essentially a refactoring. Even though the chapter is short and simple, we do learn a few new things.

The first thing we learn is that services, through Grails, use Spring's declarative transactions making service methods transactional. This can be turned off by changing the value of the transactional property to false. The property is included and set to true in the stub created by the create-service command.

The next thing we are introduced to is how Spring's dependency injection mechanism is implemented by Grails. We are told dependency injection is important in that it forces us to write code to the interface and not have to be concerned about how classes are constructed. Traditionally this is set up via configuration files. Of course, Grails uses convention over configuration. We are told that by following a few simple rules, which are presented, we can simply add a property to the class in which we want to add the class. For instance, to inject the file service we are creating, we simply need to add the line:

def fileService

An added benefit to loosely typing the service is that there is no need to restart the application after changes to the service when in development mode.

The final significant thing we learn about services in this chapter is about the scope of services. By default services are created as singletons. This does mean that services using the default implementation are not thread-safe. The scope of the service can be overridden by defining a scope variable in the service and specifying one of a number of available scopes, which the author has listed and explained. To specify that a service to live within the request scope, all you need do is add the following line:

static scope = 'request'

The remainder of the chapter is dedicated to refactoring and creating the service. This all goes fairly smoothly. The issue I uncovered in the previous chapter regarding the inability to display some error messages are corrected. The changes I put into the create view, being irrelevant, were backed out by me and we are now in sync regarding that bit of code. The line specifying that view post be rendered still exists incorrectly. There is never any discussion of moving the method extractExtension from the controller to the service, though this should be relatively obvious from the listing of the service. Likewise, we are not told to remove the property injecting the user service into the controller, at least it is not clear that it should be done. This is a very minor issue, however, and failing to do so should not affect the application.

Part 1 of this series can be seen here.
Part 2 of this series can be seen here.
Part 3 of this series can be seen here.
Part 4 of this series can be seen here.
Part 5 of this series can be seen here.
Part 6 of this series can be seen here.
Part 7 of this series can be seen here.
Part 8 of this series can be seen here.
Part 9 of this series can be seen here.

The numbers this month are mixed. The Tiobe Groovy rating increased by a very slight percent, thought the absolute rank fell by 1. Dice showed declines over all three search results, whereas Indeed showed losses only for the Groovy/Grails combined search and gains for the individual Grails and Groovy searches.

The TIOBE Programming Community Index for Groovy
Month / Year	Rating	Change	Rank
08/2009	0.117%	+0.003%	48
07/2009	0.114%	-0.038%	47
06/2009	0.152%	+0.020%	36
05/2009	0.132%	-0.033%	41
04/2009	0.165%	+0.031%	36
03/2009	0.134%	+0.005%	42
02/2009	0.129%	-0.006%	40
01/2009	0.135%	--	38

Dice Keyword Search for Groovy and Grails
Month / Year	Groovy/Grails	Change	Grails	Change	Groovy	Change
08/2009	19	-8	32	-3	65	-3
07/2009	27	--	35	--	68	--
02/2009	23	11	29	12	56	25
01/2009	12	--	17	--	31	--

Indeed Keyword Search for Groovy and Grails
Month / Year	Groovy/Grails	Change	Grails	Change	Groovy	Change
08/2009	158	-10	296	22	477	70
07/2009	168	--	274	--	407	--
02/2009	89	18	110	-11	305	-80
01/2009	71	--	121	--	385	--

Results from the search engines should be considered carefully as the results are just the numbers returned from key word searches.