I added some feeds to the CompareXY.com site (see some other blogs on the experiment). Technically, I already had one feed already, but I'll go over it anyway. Eventually, I think I'll support Atom, and add some feeds based upon tags, or searches, but for now I just created feeds for the blog (about building the site), the latest-n articles, and a site map.

Basically, the idea for creating feeds is:

• Install RSS feed plugin
  
• Make a shared service for getting articles
  
• Make a feeds controller with a few actions for delivering the feeds including:
  
  
  
  • latest - For feeding the n latest articles
    
  • sitemap - For feeding the site map of the site
    
  • blogs - For feeding the world my incredible blog updates
  
  
• Put some links on the site, and tell browsers how to handle them

1. First, I installed the "feeds" plugin from Grails.org, http://grails.org/Feeds+Plugin. There is reasonable documentation on how to use the feeds plugin on the site, but basically:
   
    >grails install-plugin feeds
   
   
2. Second, I created a SiteMap service, and added a method called "list":
   
   >grails create-service com.comparexy.services.SiteMap
   
   I will be able to re-use the "list" method for both the full site map feed, and for the latest-n feed. The list method accepts three arguments:
   
   
   
   • size - The maximum number of elements to list in feed. For instance, Google will only read 50,000 items in an RSS site map. If my site ever (which I am not holding my breath) gets within a magnitude of that, I'll adjust the controller to split the feeds up.
     
   • minState & maxState - Just a filter range that is specific to the articles. Basically, it ranges from Official, and Valid to Suggested, Flagged, and Garbage. I don't really need to feed Google a site map of the Garbage articles, so I'll filter them out. Also, the latest feeds will filter everything out that isn't marked as Official, so (assuming anyone ever subscribes) it isn't feeding merely Suggested articles, but just Official articles).
     
   
   
   Maybe fortunate, or unfortunately, I modeled the comparison articles to maintain their history by having multiple versions in the same database table. The latest article in the table that is marked Official by an editor (me) will be the version of the article that will be displayed when an article is requested. So, to get a list of unique articles, I need to group them by the article identifiers, and order them by their createdDate (as you can see in the HQL below).
   
   I am going to pass the HQL statement that I wrote to the GORM method, executeQuery(), that was injected into the Comparison domain object. I'll add additional filters, and the maximum number of records to return.
   
   (Sorry for putting the code in images, but blogger.com seems to be a bit a pain to keep code formatted)
   (Snippet from SiteMapService.groovy)
   
   * Parenthetically, the first time I used executeQuery(), I mistakenly assumed it for something that executed a native SQL statement, rather than a GORM or HQL statement, as it looks like java.sql.Statement#executeQuery(). That was quickly rectified. If you want to execute native SQL in GORM, you'll have to create an instance of groovy.sql.Sql.
   
   
   
3. Thirdly, I created a controller, and added a few actions for it including "latest", "sitemap", and "blogs":
   
   >grails create-controller com.comparexy.controllers.Feeds
   
   For the latest-n feed, I needed to pass in a number from the URL, or use a default value if a good number wasn't passed in. Since the path to the feeds was already organized by Grails default (i.e."/$controller/$action/$id"), I could have just gone with that, but I figured it would be a bit clearer for me if I passed in a "num" parameter specifically instead of the "id" parameter. To do this, I updated the /conf/UrlMappings.groovy file with an entry that points to this controller, and action, but names the third parameter $num:
   
   (Snippet from UrlMapping.groovy)
   
   In the "latest" action (see code below):
   
   
   
   • I take the param.num that I set up in the UrlMapping.groovy above, and make it a reasonable integer that I can use.
     
   • I call the siteMapService.list() method, and load up some results with Official comparison articles.
     
     • The service's list method takes a range of states, and in this case, the upper and lower bounds ofthe range are both Official identified with the constant STATE_OFFICIAL.
     
     
   • I broke up the URL that I will eventually pass to the "feeds" service, into parts (mainly so it would fit into a screen shot) with the base, and path variables.
     
   
   Now the meat of the feeds: I pass the values for feedType, and feedVersion into the controller's render method. I hard-code the those values for RSS, but I could have (and I will be doing a little refactoring here shortly) passed in a "feedType" argument to the action, and dynamically set this to be an Atom, ROME, or ITunes feed rather than RSS. The "feeds" plugin defines a Builder DSL, which I used to define the content of the feed such as title, link (of the feed), and description. Then, for each record that I received from the SiteMap service, I add an entry element in the Builder DSL. The entry method takes a title inside it's parenthesis, and inside of the closure, you set the author, publishedDate, and link. For my title, I used the terms from the comparison like "This vs That".
   
   (Snippet from FeedsController.groovy)
   
   
   To the above controller, I also added an action for both sitemap, and blogs. The "sitemap" action uses the same SiteMap service method that "latest" action uses. The "blogs" action just used the Gorm DomainObject.list() method with a couple of properties for sorting: Blog.list(sort: 'dateCreated', order: 'desc' )
   
   
4. So, that was fairly easy so far. The hardest thing was deciding what I wanted to put into the feed. Now I need to share the feed with the world by putting some links on my site.
   
   Before I put the links back to the appropriate actions, I used the feeds plugin's <feed:meta...> tags for assisting me in telling the browser the content type to expect at the other end of the RSS links. Again, I could have done this dynamically, and placed Atom, ROME, or ITunes in, but here I hard-coded RSS. I placed these in the <head...> tag of my main.gsp layout file.
   
   Snippet from main.gsp layout
   
   
   The output from the above feeds tags on the source code of the rendered web pages is as follows below:
   
   Snippet output from the what the above <feed:meta...> tags created
   
   
   Now, when I put the following orange feed squares links in my page as below, the browser will recognize the same URL that is referenced in the tag, and know that the intention is render the content at the other end of the link as a feed, and not as the plain XML that is delivered to the browser.RSS feeds to the site blog (left), and to the latest 20 articles (right)
   
   
   
   RSS feed to the sitemap for Google (and maybe other search engines if they accept RSS)
   
   
   Ok, it took me longer to write this blog than it did to add the feeds.
   

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.

Chapter 6 - Testing

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.

There are many plugins available to the Grails developer. Among them are: Easyb Testing, though new to it, a personal favorite of mine (the plugin does not appear to be ready, yet, there is little info on the plugin page. You can still use it. See the official easyb site.), Build Test Data, Selenium, Test Code Coverage, Canoo WebTest, CodeNarc and many others. While it would have been nice to have a more comprehensive chapter on testing, giving those listed above their proper due would get lengthy, perhaps worthy of a book of their own. The author instead focuses on unit testing, including many of the built-in mocking features, integration testing and functional testing using Functional Testing.

The chapter starts off with a bit of history behind automated unit testing, its relationship to Extreme Programming (XP) and Test Driven Development (TDD). He explains how the original unit testing framework is JUnit and that Groovy comes with this, extending and enhancing it, and that the JUnit framework on which Groovy and Grails builds uses the conventions prior to JUnit 4 (meaning before annotations were available). I won't go into detail here. However, I do want to point out that he remarks on one of the best practices of using descriptive test names. Here is a place where I feel easyb, a Behavior Driven Development (BDD) framework, is far superior.

I have another quibble, as well, in this section. He speaks of how many developers write test cases that do not execute against their application code, implying, I believe, that not only do you have to write tests that exercise the production code, but also that the tests must actually be meaningful. I will return to this later. My problem with this section, though, is that he gives an example of a bad test and does not demonstrate what a good test should look like. Someone likely to write a bad test, in my opinion, may not really understand what is wrong with the test as written and not intuit the proper way to write it.

And, this brings up yet another quibble. Here, again, Jon seems to have chosen to roll his own rather than using the automated features included with Grails. Maybe the way test cases were generated changed during the writing of the book explaining the differences between the code he has here in this and other examples. That could explain it, but I think that this should have been revisited and updated with the 1.1 Grails release. I'd like to hear Jon comment on this. The changes are not dramatic, though. The name of the generated unit test for class User, for example, would read UserTests rather than UserUnitTests. Similarly, he extends GroovyTestCase, at least in the example on page 116 and others, rather than GrailsUnitTestCase. In other examples, he does extend GrailsUnitTestCase. In the example testing the MessageController, the framework generates a class that extends ControllerUnitTestCase and he uses GrailsUnitTestCase. The auto-genned classes, too, come with stubs for the setUp and tearDown methods, something not included in his examples.

Jon does list the JUnit assert methods and the additional assert methods provided by the GroovyTestCase, from which GrailsUnitTestCase inherits. These additional assert methods are: assertArrayEquals, AssertContains, assertLength, assertScript, and assertToString. Also included are the convenience methods shouldFail and shouldFailWithCause. These shouldFail methods are then explained further with an example. These are a bit tricky. They take a closure and the closure is expected to throw an exception. If one is not thrown, the test fails. By using the WithCause variation, you can specify the exact type of exception you do expect. Any other exception or no exception at all will cause the test to fail.

On page 121, the author tells us of the convention of where tests are expected to live, and explains that the tests are automatically generated when you use one of the create commands. He then goes on to write his own variation, as stated before, and inexplicably in my opinion. The example here is missing the import for GrailsUnitTestCase. I am not sure that the test was tested!

We are then instructed on how to run the test case and the reporting explained. Nothing here should surprise the professional developer, especially one that has used one of the xUnit frameworks before.

Next, Jon goes on to tell us of the problems we'll quickly encounter with testing a Grails app. Unit tests do not run within the Grails container. This means that dynamic methods and properties are not available to the unit test. This leads to a couple solutions, neither of which is ideal, mocking and running the tests as integration tests. Luckily, as Jon explains, mocking support is built-in through the GrailsUnitTestCase class. He provides a table showing the various methods supporting mocking and a brief description regarding their use: mockController, mockDomain, mockForConstraintsTests, mockFor, mockLogging, mockTagLib and registerMetaClass. Of these, he demonstrates the use of mockController, mockDomain, mockForConstraintsTests, and mockFor. He goes in depth on the latter to explain how the delegate property is used on the closure.

When discussing mockForConstraintsTests the author seemingly violates his earlier assertion that you should write meaningful tests that I mentioned above. I find this rather ironic. Here he tests a constraint (page 127), but to validate only writes:

assertTrue(message.hasErrors())

Well, this means that no matter what error is thrown, the test will pass. Wholly inadequate, in my opinion. It would be better, in my opinion, to take greater advantage of the error property. For example, the test in question could be written as:

assertTrue message.errors.allErrors[0].toString().contains("Field error in object 'app.Message' on field 'title': rejected value []")
assertEquals 1, message.errors.errorCount
assertEquals "title", message.errors.fieldError.field
assertEquals "", message.errors.fieldError.rejectedValue

The first line above could be used instead of the latter three, though takes a bit more work to figure out. You may need to run a test outputting the actual error string. Certainly, your test could get more sophisticated than this and there are other alternatives. All three tests in this example are similarly challenged and the solutions for testing reliably will vary.

After explaining mocking, we are told of the limitations of unit testing, and Jon goes on to discuss integration testing. This is all fairly familiar territory so will not be discussed in depth. He does introduce us to grails.util.Environment in this section, something he promises to delve into deeper in a later chapter. I don't really agree with the reason he is using it, however. He is manipulating the creation of data in our BootStrap.groovy for testing reasons. It is my opinion that the test case should neither depend on the existence or non-existence of such data. Test cases should manage all the variables that impact proper execution.

Finally, we get to functional testing and the Functional Testing plug-in. This is all so simple to install, create and implement, that it almost seems trivial. Just what we developers need! He does stress the trade-off necessary between the level of code coverage and the time it takes functional tests to run. The functional tests are run within the Grails container.

While totally gratuitous on my part, a short discussion of the differences between Webtest and Functional Testing plugins is probably relevant. Webtest had been the original "go to" plugin for functional testing. The Functional Testing plugin seems to be the new favorite. Since many will undoubtedly work on legacy applications that use the former, understanding the differences could be necessary. There is a page on the Grails site that does discuss this, but is rather incomplete. Oh, well.

Chapter 5 - Authentication with JSecurity Plug-in

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.

Many applications require security. Luckily, through Grails plug-in architecture and a number of available plug-ins devoted to the task, adding security a Grails application is relatively easy. In this chapter, Jon takes us through implementation of many normally encountered requirements using the JSecurity plug-in. I have only used the Spring Security (Acegi) plug-in prior to this, so I really looked forward to the experience (I have read about JSecurity and CAS previously). My impression after this chapter is that implementing JSecurity via the plug-in is a fairly simple process and is one I'll strongly consider on future projects. The only caveat to this is the same complaint I've had of features the book covered earlier, namely the decision to "roll your own" rather than using the supplied commands to create artifacts and teaching and modifying those. In the end, I am not sure what it is I don't know and will be forced into digging into the features of the plug-in before I use it. Certainly, this being a tutorial, a few additional pages covering the plug-in in greater detail does not seem unwarranted.

The chapter starts off introducing us to the fact that there is a plug-in mechanism and tells us of several of the many areas for which plug-ins have been written. Jon explains that plug-ins can generate a number of artifacts, from classes to static resources, and can take part in build and runtime events. Further, he states that the core features of Grails are implemented as plug-ins, thus making the plug-in architecture fundamental to Grails, and provides the sample of GORM as a core plug-in, the plug-in used to abstract Hibernate.

It seems that the reason JSecurity was used in the project is the ease with which it could be integrated with the existing domain model. This proved to be true, in my opinion.

Jon explained that plug-ins are installed in a default directory, your user account. He then states that this gives rise to a number problems and provides two:

• Other users may not be able to execute the plug-in.
• If the name of the project is changed, you must remember to dig around in your user directory to change the installation location of the plug-in.

I am not sure that these are truly serious concerns. Perhaps they are on larger projects than those on which I've worked. He then tells us how to override the default plug-in location, putting it into another location. Prior to Grails 1.1, the default location was within the project tree. With the change, a number of people had problems and one of the common solutions suggested on the mailing list was to do what Jon demonstrates here, except to use the path as had been used in earlier releases. I personally now just use the default. However, I followed Jon's instructions. What I found, and it could be a user error, is that my editor, Intellij IDEA, did not recognize the path specified in the BuildConfig.groovy file causing a cannot resolve symbol JSecurity error when I created the TeamworkRealm.groovy file. This error is specific to the browser. There were no problems building the project outside of IDEA. I did try many possible solutions, and think I covered them all, but no "solution" worked. So, I just ended up installing the plug-in into the default directory. But, I digress.

He went on to explain more about the structure of plug-ins, which is certainly nice to know information. He then tells us of the scripts the JSecurity plug-in makes available to the developer. However, we are then told that one will not be used because the default domain model generated is more complicated than the simple model used by the application. We do eventually use the CreateAuthController script to generate the login action and page.

We are then provided a quick overview of JSecurity, covering the role, permissions, subject, principal and realm concepts. Permissions are not used in the application. Realms are delved in more deeply than the other subjects, and then we go on to creating our own realm. There are a couple scripts supplied by JSecurity for creating realms, CreateDbRealm and CreateLdapRealm, that are not used. What these create should be self evident from their names.

Next, we go on to implementing the authenticate method in the realm. This gives rise to a discussion of dynamic finders. This is covered relatively sufficiently. Explaining how the term dynamic is derived from dynamically constructed method names rather than the fact that the methods are added to the domains dynamically, he covers all the operators that can be used when constructing a name. He rightly implies that the junction operators And and Or are limited to two conditions. This could easily be missed by the noob and gives rise to one of my complaints about Grails. For example, you may write a finder such as Book.findAllByAuthorLastNameAndPublicationDate(name, date). This is perfectly legitimate. When you try running your code with finder Book.findAllByAuthorLastNameAndPublicationDateAndBinding(name, date, binding), you'll find that it fails and will have a large stack trace on the console. You cannot have three conditions. This violates the principle that you should always write your code so that someone else has a clear mental model of what to expect. Unless you've read the one line in the Grails document that points this out or you've properly inferred from other writings, and it has stuck with you, you will run into this error. Perhaps this is a problem with the underlying Hibernate implementation. Either way, it is wrong. Never make people guess. I digress again.

From here we are introduced to the use of criteria for more complex queries. This is barely touched upon, but we are promised that we will get a deeper introduction in a later chapter.

Then come the concepts of filters. These are similar to filters in Java Servlets. They are quick and easy to implement. And, soon, we have our first filters written.

Because the authentication is in place, we are not able to log into our application. There are no users! So, Jon takes us through adding users via our bootstrap class and we are introduced to the encryption function provided by the plug-in. This gives us the required background for encrypting the password when the user is created or updated. Jon did teach a trick here of which I was unaware. He updated the password field after calling hasErrors and save. This takes advantage of the Open Session in View pattern for hibernate. This means that changes to your object will not be persisted until all server-side operations have finished.

Finally, we add some other features to our application: an improved permission denied page, a sign out link, and displaying the author of our messages. In the latter, we are introduced to services briefly and told we will learn more about services in an upcoming chapter. We are told that Grails supports the concept of a service layer, though little more. We are also required to relate messages to users. This was done simply, but Jon does not use belongsTo or hasMany properties to do so. We are also introduced to Hibernate's lazy loading feature, the n + 1 problem to which this gives rise, Hibernate fetch strategies, and using the eager strategy to resolve the n + 1 problem.

One error was found in the code listings in the chapter on page 100. It is fairly minor. The author wrote Sha1Hash(user.password).toHex() and it should read Sha1Hash(userInstance.password).toHex(). I've submitted an error report to the publisher. Hopefully it will show up on the errata soon. Similarly, there was an instance where he used the word principle rather than principal on page 89 in the text that was not listed in the errata. I have not submitted this and likely will not.