Archiv für September 2009

Did you ever want to put the instances of your domain classes into user-defined categories? Something like tags but more structured and maybe hierarchical?

Good news today: Grails has a plug-in for this purpose – it is called the taxonomy plug-in. The developers of this plug-in say that it allows you to apply arbitrary hierarchical categorisation (Taxons) to domain objects. Here is an example of the basic usage:

def book = Book.get(1)
// Add the book to the Non-fiction > Autobiography category
book.addToTaxonomy(['Non-fiction', 'Autobiography'])
 
def autobiographies = Book.findAllByTaxonomyFamily(
    ['Non-fiction', 'Autobiography']
)

There is support for arbitrary nesting of Taxons (categories) within unlimited taxonomies, and taxonomies are domain class independent.

So the category “Local” on Author can also be used on Book.

However, you can have different taxonomy graphs aside from the default one, so you might have a taxonomy graph “Location” storing the names of states and cities, and another taxonomy graph “Company type” – and objects having categories in both graphs.

Release 0.1 of the taxonomy plug-in is “alpha” grade. It does not support polymorphism. So querying objects by taxonomy requires you to query the specific class type. This will be resolved in the next release. Also, it does not do caching so it isn’t going to be blazingly fast. Developers say that this will come soon.

Have fun and visit the plug-in page on grails.org.

When you write an integration test for a Grails app, you will likely want to have a clean situation with reproducible test data in your database before the test actually starts. Enter the Fixtures Plugin for Grails.

This plugin helps you to define a fixture, that is a defined set of data used for testing. The plugin defines a DSL in which you can express your need for data. Example:

fixture {
    guillaume(Author) {
        name = "Guillaume Laforge"
    }
    dierk(Author) {
        name = "Dierk Koenig"
    }
    gina(Book) {
        title = "Groovy In Action"
        authors = [guillaume, dierk]
    }
}

Or a little shorter:

fixture {
    guillaume(Author, name: "Guillaume Laforge")
    dierk(Author, name: "Dierk Koenig")
    gina(Book, title: "Groovy In Action", authors: [guillaume, dierk])
}

Then, in your test case, you will want to load that fixture, like this:

class GinaTests extends GroovyTestCase {
    def fixtureLoader
 
    void testFinderMethod() {
        fixtureLoader.load("gina")
        def gina = Book.findByTitle("Groovy In Action")
        assertNotNull(gina)
        assertEquals(2, gina.authors.size())
    }
}

Pretty simple, isn’t it? Find out more about how to install and use the Fixtures plugin on its plugin page at grails.org.

The monsters enter the Grails web framework! Jonas Nordstrand has written a plugin that opens the door to them. This is what he says about it:

A grails implementation of MonsterID: a method to generate a unique monster image based upon a certain identifier (user id, email address, whatever). It can be used to automatically provide personal avatar images in blog comments or other community services.

You can find this plugin (as usual) on grails.org.

Bean Fields, a new plugin for Grails, provides a suite of tags for rendering form fields for domain and command objects. As the developers claim, it takes the pain, boredom and scope for error away.

Out of the box it:

• renders a field using a UI element appropriate for the property type. Constraints are used to set maximum lengths etc.
• automatically renders tags for fields, from i18n message bundles
• renders “required” indicators if the field is nullable:false and/or blank:false
• renders errors adjacent to the field that had the error
• renders the current value as appropriate

This is all done by building on top of Grails existing tags, so all the regular tag attributes are supported where possible.

Here’s an example of how you can render all this for a bunch of bean properties:

<bean:withBean beanName="form">
    <bean:field property="firstName">
    <bean:field property="lastName">
    <bean:field property="company">
    <bean:field property="email">
</bean:withBean>

You can find more elaborate examples as well as instructions for use on the plugin page.

David Russell notified me about a bug in the Paypal plugin. Thank you, David!

Bug description: When a user makes a payment, Paypal notifies the site with a so-called instant payment notification. The code in PaypalController.notify() was wrong so that an error code 404 was returned to Paypal. Paypal retried the notification several times and finally gave up. The plugin processed the notification properly, though.

I fixed this bug today and released the corrected Paypal plugin as version 0.5.

You can find more info about the plugin on the plugin page at grails.org.

Scaffolding in Grails (from my point of view) is like scaffolding in construction: After the walls have been built, you remove the scaffold.

However, at least one plug-in developer for Grails seems to think differently. See for yourself:

This plugin provides an ‘automatic’ component-like rendering infrastructure to Grails. It combines the ease of use of scaffolding with the flexibility to change the resulting views via custom renderers. This also allows you to change what tags you use to render an object without having to worry about consistency across views. Write it once, and be done with it!

What do you think – is this plug-in worth a try?

The Apache Camel Grails plug-in allows you to send and route messages to a wide variety of destination endpoints directly from your controllers and services. It also provides a new Grails artifact, Routes, to configure your routes using known Enterprise Integration Patterns via the Apache Camel Java DSL.

It is quite easy to route messages. For example, write a Grails service like this:

class MyService {
    def myMethod(fooBarText) {
        log.info “Got text: ${ fooBarText }”
    }
}

Then, using Camel’s bean integration, you can deliver messages from an in-memory queue directly to that Grails service:

from(“seda:my.queue”).filter {
    it.in.body.contains(“FooBar”)
}.to(“bean:myService?methodName=myMethod”)

Cool, isn’t it? As usual, you can find more info on the plugin page on grails.org.

The tutorial that describes how to use the AcegiSecurity Plugin for Grails has been updated:

There are three ways to define security mappings – see Securing URLs for more details. This tutorial uses the Requestmap approach. To use Controller annotations, use this tutorial and to specify security mappings using the standard Spring Security approach use this tutorial.

Good Luck!