The problem is, that Converter provides no way to determine which drawings have been added. So I tried the following, like I would have done in Java – subclass the Converter and add the needed methods.

But I can’t override the AddDrawing-Method, because it’s not marked as virtual in the super class (and I can’t change the super class). Now what?

I chose to factor out the conv.AddDrawing(drw) part of the original method in a new method “AddToConverter”, create a TestService class and override the new method there similar to how I planned to do in the TestConverter. Leads to more methods that need to have less restricted access than I’d like to… bäh.

In all other classes I still think that the only use of regions is to find which parts of a class should be extracted into a new class

This snippet in Firefox

only prints exactly one page (that means it even stops in the middle of a line when the page is full).

However, using

instead of

solved the problem.

All talks were awesome (and I totally want an arduino for Christmas), but the one that kept me researching and having new ideas was the one of Moritz Stefaner about visualizing information. He has some really inspiring websites (here and here). I especially liked his contribution to the book “Dynamic Taxonomies and Faceted Search” – it’s about search, visualization and it even has formulas. What more could one want?

The organizor of the conference promised to upload videos of the talks, I’ll post an update once they are available (most are in german, though)

The first small remark is about line 3: markup{//doSomething} is similiar to markup.call({//doSomething}). BuilderSupport intercepts all method calls and MarkupBuilder produces xml tags from these method calls. So this will lead to an enclosing <call> tag. Surely not what we want.

Now let’s have a closer look at the body parameter. This is a GroovyPageTagBody, a special Closure which captures output using a special Writer (GroovyPageTageWriter). These bodies are usually called by various GroovyPage.invokeTag methods (see another following article on how to investigate groovy pages rendering) and return either a StreamCharBuffer (a special Writable and CharSequence) or the result of the closure evaluation, which is also Writable or a CharSequence if we are lucky.

So what is the right way to pass a CharSequence to the builder if we want our MarkupBuilder to use it as tag content? This will not work:

The String will be evaluated, but as it’s not in a method call, our MarkupBuilder doesn’t know what to do with it. There are two possibilities to do it right:

If we now replace “some text” with our GroovyPageTagBody call, we are nearly done. But wait, there’s one more thing. mkp (short for markup.getMkp()) returns a MarkupBuilderHelper (since Groovy 1.6.6, prior it was the builder itself). Instead of mkp.yield("some text") we could also use the yield method of the MarkupBuilder itself: yield("some text", true). But, hey, what means true? It’s the XML escaping of the text, which is also done if we pass the text as last parameter to the builder method (as in line 2 above). If we expect our body to contain markup, we should omit escaping. Of course there is also a helper method for that and our corrected example now finally looks right:

One last remark: Prior to Groovy 1.7.2 MarkupBuilderHelpers yield and yieldUnescaped methods were duplicated in MarkupBuilder itself, so the mkp prefix could be omitted. This is no longer true. You have to either fall back to the ugly boolean parameter or use the helpers pretty named methods.

For example, we use GreenMail in our testing environment. To check for sent mails, we have to use GrailsUnitTests, even if we are testing a Controller, because the content of mails is always empty in ControllerUnitTests.

Checking view names or redirects in those two types of tests is also slightly different:

This is pretty annoying and I hope it will be unified in future versions of Grails.

Not as clean as we’d like to have it, so suggestions are welcome!

The information is stored in the request header, so the obvious solution to add an user-agent-header worked. That we didn’t even consider this solution at first is maybe a sign that testing in grails seldom does what you expect…

“I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I’d probably have never created Groovy.”

That book incidentally is highly recommended. Some might be put off by the operator-heavy syntax but it is simply a matter of getting familiar with it. The language itself is quite tiny – the defining goal is for Scala to be a scalable language. For example, the language didn’t have to grow to accommodate Erlang-style actors, but they could be implemented as a library. The type system is very well thought-out and feels like what Java should have been. And it is so easy to mix OO and functional programming (without having to fight the language!)

Lots of web folk are proclaiming the death of Java (not likely to happen for a long, long time); but the JVM ecosystem is flourishing. With Groovy, Scala and Clojure there are great options for leveraging existing libraries and interacting with legacy code. So pick a flavor and dig in!

That’s a pretty neat method to check for authentication, incorrect parameters etc. Unfortunately, filters are not applied during unit or integration tests – you need functional tests that simulate http-requests and responses to verify they are doing the right thing.

Grails does not support functional tests directly, you need a plugin (we chose “functional-test”):

grails install-plugin functional-test (install)
grails createFunctionalTest AuthenticationFilters (create test)
grails functional-tests (run test)

There are a couple of annoying things regarding functional tests:

• takes forever (more than one minute)
• when checking for contentsContains you only see that it didn’t match, but not what the content was
• you’re not able to see the output of println for simple debugging

On top of that it didn’t work when one installs the plugin and someone else in the team does an svn update – only after calling run-app twice.