The Kaptain on ... stuff » Apache

Grails-UI DataTable using XML for a model

TheKaptain — Mon, 26 Oct 2009 07:06:05 +0000

I had a great chance to play with some new stuff this weekend, namely Grails 1.2-M3, the new Grails REST plugin and Groovy in general. Awhile back I wrote some Groovy code to explore the various Jira, Fisheye and Crucible REST api’s using Apache HttpClient directly, and I wanted to see what it would like abstracted behind HTTPBuilder. With the help of the Grails-UI and Google-charts plugins, I got some pretty nice views of the data as well.

First off, dealing with a RESTful call was about as simple as I’ve ever seen. This is the entire code that deals with creating the connection, authenticating, executing a GET, and parsing the returned XML into a ‘data’ property on the response.

    private withFisheye(String url, Map args) {
        withRest(uri: url) {
            auth.basic userName, password
            return get(query: args)
        }
    }

Getting XML using Andres’ plugin is extremely simple and we can achieve some pretty nice visualizations of the resulting data very easily as well. In particular I wanted to share how to use an XML response as a backing model for DataTable. The excellent examples provided by Matthew Taylor on his blog seemed to concentrate on using GORM to load and sort domain objects to utilize as data models. When using XML as an alternative way to represent the data, and using RESTful calls to populate that data, the available sorting options on a DataTable weren’t able to function properly without a little extra help.

Consider an list of XML elements like this, which represents a single review in Crucible.


    false
    
        Kelly Robinson
        TheKaptain
    
    20010101T00::00.0000000
    20010101T00::00.0000000
    
        Kelly Robinson
        TheKaptain
    
    
        Test review
    
    
        Kelly Robinson
        TheKaptain
    
    
        Test review
    
    
        CR1
    
    CR
    Closed
    
      Test review

You can leverage this list as a DataTable model by extracting specific elements from the XML, and providing a sorting mechanism based on dynamic map value lookups.

    private def createReviewDataJson(HttpServletResponse response, Map params, reviews) {
        def list = []
        response.setHeader("Cache-Control", "no-store")
       //build a List of Maps, one for each row in the DataTable
        reviews.reviewData.each {
            list << [
                    id: it.permaId.id.text(),
                    author: it.author.displayName.text(),
                    creator: it.creator.displayName.text(),
                    moderator: it.moderator.displayName.text(),
                    description: it.description.text(),
                    state: it.state.text()
            ]
        }
       //sort by the 'order' and 'sort' parameters passed in by DataTable
        switch (params.order) {
            case 'asc':
                list.sort { it."${params.sort}" } //sort by value where key == params.sort
                break
            case 'desc':
                list.sort {a, b -> b."${params.sort}" <=> a."${params.sort}" } //reverse sort by value
                break
        }
       //the entire model
        def data = [totalRecords: list.size(), results: list]
        render data as JSON
    }

This model can then be rendered using the tag. Note that this is pretty much a direct copy of a provided example, nothing fancy here.

So for very little work you get a sortable, paginated DataTable, complete with column resizing and dragging. The DataTable is also being rendered using a template, allowing it to be used arbitrarily by controller methods that populate the model with different reviews. Pretty cool if you ask me. I also used the same backing XML model to drive some PieCharts, but that’s perhaps a topic for another post.

Groovy CliBuilder with multiple arguments

TheKaptain — Sun, 04 Oct 2009 23:30:07 +0000

I’ve been writing a lot of Groovy scripts lately and have developed quite a fondness for the CliBuilder along the way.
There’s lots of great examples on the internet, but I could only find one place that demonstrated how to easily consume an unknown number of parameters as a List and that was a copy of the CliBuilderTest I found on Koders. There’s also some explanation for the different behavior inherent in the Apache Commons Cli libraries V1.0 and V1.1 that CliBuilder encapsulates(there is a 1.2 version, but from the documentation it seems CliBuilder may not be fully compatible with it).

Here’s a GroovyTestCase that exercises CliBuilder with multiple arguments.

package org.kar
import org.apache.commons.cli.Option
/**
 * Demonstrates usage of the CliBuilder with multiple arguments to create a List.
 */
class CliBuilderDemoTest
extends GroovyTestCase {
    /**
     * You can specify multiple arguments one at a time.
     */
    void testMultiOption() {
        CliBuilder cli = new CliBuilder()
        cli.with {
            a longOpt: 'arguments', args: 2, required: true, 'Two arguments'
        }
        def args = ['-a', 'arg1', '-a', 'arg2']
        def options = cli.parse(args)

        assert (options)
        assertEquals('First arg is available with the -a option. ', 'arg1', options.a)
        assertEquals('Should be two args, in order, available with the addition of an "s" to the option.',
                ['arg1', 'arg2'], options.as)
    }

    /**
     * You can specify multiple arguments together in a block, with a defined separator(in this case a comma).
     */
    void testMultiOptionWithSeparator() {
        CliBuilder cli = new CliBuilder()
        cli.with {
            a longOpt: 'arguments', args: 2, required: true, valueSeparator: ',' as char,
                    'Two arguments, separated by a comma'
        }
        def args = ['-a', 'arg1,arg2']
        def options = cli.parse(args)

        assert (options)
        assertEquals('First arg is available with the -a option. ', 'arg1', options.a)
        assertEquals('Should be two args, in order.', ['arg1', 'arg2'], options.as)
    }

    /**
     * You can also have any number of arguments by specifying UNLIMITED_VALUES.
     */
    void testUnlimitedArgs() {
        CliBuilder cli = new CliBuilder()
        cli.with {
            a longOpt: 'arguments', args: Option.UNLIMITED_VALUES, required: true, valueSeparator: ',' as char,
                    'Two arguments, separated by a comma'
        }
        def args = ['-a', 'arg1,arg2,arg3']
        def options = cli.parse(args)

        assert (options)
        assertEquals('First arg is available with the -a option. ', 'arg1', options.a)
        assertEquals('Should be a list of args, in order.', ['arg1', 'arg2', 'arg3'], options.as)

        def args2 = ['-a', 'argOnly']
        def options2 = cli.parse(args2)

        assert (options)
        assertEquals('First arg is available with the -a option.', 'argOnly', options2.a)
        assertEquals('Should be a list of args, with a single entry.', ['argOnly'], options2.as)

        def args3 = []
        //this will automagically print the usage string and any validation errors to System.out
        def options3 = cli.parse(args3)
        assertNull(options3)
    }
}

Anyhow, hope that the next guy finds this info useful – it certainly has made my recent work writing Groovy scripts much easier!

Going old school – Apache Camel mailing lists ftw!

TheKaptain — Fri, 17 Jul 2009 03:52:04 +0000

I’ve been learning a lot about Apache Camel at work recently and am so very glad that I signed up for the mailing list a couple of weeks back.

Was scratching my head recently about why my headers were mysteriously disappearing from some messages and fortunately I read the mailing list before deep diving into the Camel source to find the problem. Somebody else came across this exact problem and pointed it out on the mailing list. In a beautiful display of same day service, a response was posted back to the forum by one of the developers. He filed a bug report and committed a fix within hours. Nice job Willen Jiang!

This is a great example of open source collaboration, as far as I’m concerned – and it saved me a lot of debugging thank-you-very-much! This kind of care and attention in the community surrounding Camel makes me feel a lot more comfortable about leveraging it to solve some tricky integration problems at work. And the mailing list has been a wealth of knowledge in many other ways as well, guiding me to a lot of resources that I wouldn’t have otherwise known about.

If you’re a developer using Camel I highly recommend signing up for the mailing list.

Groovy and Glazed Lists with Grape