Jon Dickinson

Hi all,

I was a guest author on this forum a few weeks ago promoting my book 'Grails 1.1 Web Application Development'. I am just following up from that promotion to say that the book is finished and is now available.

You can get it from the Packt site:

http://www.packtpub.com/grails-1-0-web-application-development/book

There is also a sample chapter available:

http://www.packtpub.com/files/grails-1-1-web-application-development-sample-chapter-10-managing-content-through-tagging.pdf

Thanks,
Jon

Thanks all for the great questions and interest the book.

Cheers,
Jon.

That's interesting. I have to say that I have never tested a scaffolded controller before as I haven't written any logic to require testing.

I have just quickly spiked what I think you are trying and it does fail but I get a different issue, namely the action closure does not exist. Now I am not entirely surprised by that, but I am able to set the behaviour on the params object.

Here's what I have, hope that helps:

//the domain class, under grails-app/domain class Task { String name } //the controller class, under grails-app/controller class TaskController { def scaffold = Task } //the test class, under test/unit import grails.test.GrailsUnitTestCase class TasksTests extends GrailsUnitTestCase { def tasks public void setUp() { super.setUp() tasks = [] mockDomain( Task, tasks ) mockController( TaskController ) } void testTaskCreate() { def taskController = new TaskController() taskController.params.name = 'first task' //no problems here taskController.save() //fails here, not entirely surprising assertEquals( 1, tasks.size() ) } }

I am using Grails 1.1, rather than 1.0 with the testing plug-in.

Cheers,
Jon.

Why don't you read them both and let me know

Hi Chris,

The dynamic methods added by the Grails framework are not available in unit tests, unless you mock them, however, you can use the testing plug-in to do this for you. As of Grails 1.1 the testing plug-in is one of the core plug-ins, so there is no need to install it.

Here's a cut down example from Chapter 6 of my book, assume we have a MessageController that binds the 'title' and 'detail' parameters from a request onto a Message domain class. We could test this controller called the save method on the domain class like so:

import grails.test.GrailsUnitTestCase class MessageControllerTests extends GrailsUnitTestCase { def savedMessages void setUp() { super.setUp() savedMessages = [] mockDomain(Message, savedMessages) //mocking the domain class mockController(MessageController) //mocking the controller } void testMessageCanBeCreated() { def messageController = new MessageController() messageController.params.title = 'detail' messageController.params.detail = 'some detail' messageController.save() // executing the save action on the MessageController assertEquals('list', messageController.redirectArgs.action) assertEquals(1, savedMessages.size()) //assert the message has been saved } }

Here we have asked the Grails testing plug-in to mock the Message domain class and controller. By mocking the domain class the unit test adds the GORM methods on, like save, list, get etc. and uses the list we have supplied savedMessages to temporarily store any messages that are saved. In this way we are able to assert that the message has actually been saved in the controller.

Cheers,
Jon.

Hi Sachin,

Have you tried using the mockController method? It looks like you are trying to mock a lot of behaviour yourself, which may be confusing the issue. If you are already extending GrailsUnitTestCase you can do the following:

class MessageControllerTests extends GrailsUnitTestCase { void setUp() { super.setUp() mockController(YourController) //this will set up the mocked behaviour on the MetaClass } void testCreateViewIsRenderedIfTheMessageDoesNotValidate() { def controller = new YourController() //this will create a controller with all the necessary mocked behaviour controller.anAction() //here you are executing the action you need to test assertEquals('success', controller.renderArgs.view) //here you are verifying that the action called render( view: 'success' ) } }

When a controller is mocked in this way the arguments that your code passes to the render and redirect methods are available through the renderArgs and redirectArgs properties. You can also get access to the various scopes (request, flash, session) to check the contents.

There is of course, quite a good example of this, using controllers, domain classes and services, in Chapter 6 of my book!

Cheers,
Jon.

Hi Mourougan,

There is no support, that I am aware of, for Velocity in Grails.

The only benefit I can think of for using a separate templating language for the view, e.g. Velocity or Freemarker, is that you can test the views without running the entire application. However, if I wanted to unit test the views I would rather use Java or Groovy code than a template language.

After a quick Google I think it is more likely that freemarker will be supported before velocity, if either of them are on the plan.

Cheers,
Jon.

Hi Burk,

The book does not actually cover Grails IDE plug-ins. I'll leave that up to google search:

http://www.grails.org/IDE+Integration
http://www.grailsblog.com/archive/show?id=10

Personally, I use IntelliJ, which was by far the best environment when I started with Grails, but with the release of Grails 1.1 I think the others are catching up. Check out the links above for more information.

Cheers,
Jon.

Chapter 14: Deployment and Next Steps

In the final chapter you will see how to deploy your application to a production environment, using Tomcat and MySQL. Finally we briefly discuss some next steps for investigation if you want to take your Grails knowledge further:

Using Java classes for your domain

Other presentation frameworks

Handling data migration, once you are in production

The final stage in the delivery of your Grails application is to deploy it to a stable production environment, running in a hosted servlet container and against a permanent database that will not be cleared out every time you restart or re-deploy the application. You will see just how simple it is to package a Grails project into a deliverable and set up the Grails configuration for a production environment.

Once the application is up and running in a production environment we will briefly introduce some next steps that may worth investigating to learn more about working with Grails.

Chapter 13: Build Your Own Plug-in

After seeing how easy it to use plug-ins, this chapter will show you how to implement your own plug-in. You will also learn how to use Groovy meta-programming to add dynamic behaviour to your domain classes.

Now that you have finished the implementation of your application it is time to look at the code and see what can be pulled out into a separate component for reuse on future projects. The feature that stands out as being most reusable is tagging. This feature will be useful on many different projects. Simplifying the implementation of tagging for future projects by using a plug-in will be a great benefit. In this chapter you will see how to:

Create and package your own plug-in

Enhance the plug-in using dynamic method support in Groovy and Grails

Chapter 12: Searching, RSS and REST Services

In this chapter you will see how to install and use the Searchable plug-in to provide an application wide search for content. You will also use a Groovy builder to create your own RSS feed, and then learn about Grails' built in support for RESTful web services.

After our last increment of providing editable in-line tagging, the users have been making good use of the application. There are now hundreds of posts and quite a few files in our application. Sometimes activity has been so fast that users have reported their messages are getting lost and people aren't seeing the information they need.

It is great news that our application is being used so much, but we need to address some new user goals that have arisen due to the usage of the application. Namely, to easily search for past messages and keep up-to-date with the increased levels of activity.

It sounds like our users need to be able to search the content of the application, and given the high frequency of messages they would probably benefit from some sort of unobtrusive notification system for new content: an RSS feed springs to mind.

We have also received some requests to send messages into the application via email. Who knows where else we will need to receive data from in the future? We had better put some web services onto the application to allow other applications to add content in the future.

Chapter 11: AJAX and RIA Frameworks

A little web 2.0 sugar for your users.

We are going to enhance the user experience of our application using AJAX and Rich Internet Application (RIA) frameworks. We will see how Grails provides built-in support for AJAX, and then introduce a plug-in that provides a number of components to leverage popular user interface design patterns. The enhancements we will implement in this chapter are:

Allow tags to be updated through AJAX.

Automatically suggest existing tags when a user is tagging content.

Use a tag cloud to filter content by tags.

Chapter 10: Managing Content Through Tagging

To enable tagging for files and messages, this chapter introduces inheritance in domain classes, and shows the different strategies that are available in GORM.

Over the last few chapters we added the ability for users to upload and share files with their teammates. As with messages, files are displayed on the home page in the order they are added to the system. Currently all messages and files are displayed on the home page. Over time, our home page is going to become rather large and unwieldy. We need a users home page to show only the files and messages that they are interested in. To do this, users need to be able to tag their content.

We will implement a simple tagging solution, restructure the home page and then add some new pages to the application for viewing all messages and files.

The new Grails concepts that will be introduced in this chapter are:

Working with inheritance in the domain classes, and which strategies GORM supports for persistence.

Using polymorphic queries over a domain inheritance hierarchy.

Encapsulating view-rendering logic in GSP templates.

How to manipulate collections with the Groovy methods collect and sort.

Hi Federico,

Unfortunately I don't have any first hand experience of this. I believe both JSecurity and Acegi Spring Security handle X509 certificates and there are plug-ins for both of these in Grails. In chapter 5 I show how to use the JSecurity plug-in, although the application just uses simple username and password form authentication.

Alternatively, is this something that you can let the servlet container (i.e. Tomcat) handle when deploying to production?

Hope that helps,
Jon.

Hi Gregg,

The application is a team communication application for sharing messages and files between team members. Essentially by the end of the application users can:

post messages and files

maintain version history of files

tag messages and files

subscribe to an RSS feed

search the application for messages and files

customise their home page by watching for content with certain tags

edit tags in-line with auto suggest

view a tag cloud for messages and files

filter content by tags, using the tag cloud

There is also a RESTful API for creating and listing messages.

I devote an entire chapter to testing, covering unit testing, integration testing and functional testing. I tried to take more of a domain driven approach in the book, because it seemed like an easier way to write about what I was doing. Where there are, relatively, large bits of coding to do before you can see an on-screen result, I use some tests to give the reader something to run to give an indication of progress.

I'm a big fan of TDD in my day to day work, but the driving goal behind writing an application for a book is actually quite different from real world development, for a start you don't have any real users. You also have to spend at least ten times more effort writing than coding!

Cheers,
Jon.