Rather than writing out the Groovy as a string, which forces you to check that its well formed, parsed, and, correctly formatted, it might be better if you had an object to handle that for you.

I’m thinking you could do something like this:

GrIFMap grifMap = new GrIFMap();
grifMap.add(”points”, [[10, 10, “Visit 1″, “javascript:alert(’Visit 1′)], [10, 40, “Visit 2″],[40, 10, “Visit 3″], [40, 40, “Visit 4″]]);
grifMap.add(”xLabel”,”Waiting Time”);
grifMap.add(”yLabel”,”Cost per visit”);

Then, to get the correctly formatted data string out, it would be a call to:

groovyData = grifMap.toGrIF();

Then, on the other side of the wire, you could do:

GrIFMap map = new GrIFMap(groovyData);
assert “Waiting Time”.equals(map.get(”xLabel”));

The fact that its Groovy going over the wire would be basically invisible to the rest of the implementation. I’d probably extend GrIFMap off of LinkedHashMap, to maintain data order….

Cool stuff.

You’re point about the parsing speed is interesting. It shouldn’t be too difficult to test out either. As for not being widely used, that’s right too, but this particular application uses Groovy and Groovy Server Pages already. So actually what happens is that a GSP generates the data in GrIF and the graph servlet consumes it.

The primary disadvantage is that its not a widely used standard, so the next person to see the code might be thinking WTF?, even if, technically, its a good solution. It would probably gain more acceptance if you came up with a cool acronym for it, though, along the lines of JSON or AJAX. Maybe GrIF?

[…]Is Groovy a good way to pass complex data from one server to another (instead of JSON or XML)?

If you're already using Groovy, you can use it very easily to transfer complex data (say for a graph). Parsing it is much easi…