This question was raised and discussed at stackoverflow recently. Having used Grails for the sixbee project I shared our experiences compared to standard J2EE application development, especially to the subquestion:
Does it really confer rapid development benefits?
Definitely, it does. Even if the scaffolding path is left early and conventions are overriden to the own needs, the start-up period is very short, as we don’t have to care for many different technologies. That kind of lightweightness makes us work not only faster, but also more precise and clean. >> more…
Did you ever want to use builders in your grails taglib and wondered why the approach mentioned in the grails documentation doesn’t work at all? Here is what I found out after a lot of trial and error and digging in the MarkupBuilder, BuilderSupport and GroovyPagTagBody sources. Let’s stick with the example from the documentation and correct it until it works (the impatient can scroll down):
-
def dialog =
{ attrs, body ->
-
def markup =
new groovy.
xml.
MarkupBuilder(out
)
-
markup {
-
div(‘class’: ‘dialog’) {
-
body()
-
} } }
>> more…
Grails claims that it encourages writing test – for example, a test class is created every time you create a controller or domain. However, working on my first Grails project I find it quite confusing which kind of test supports what.
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:
-
//ControllerUnitTest
-
assert controller.modelAndView.view == "send"
-
assert controller.redirectArgs.controller == "delivery"
-
//GrailsUnitTests
-
assert controller.modelAndView.view == "Message/send"
-
assert controller.response.redirectUrl == "/delivery"
This is pretty annoying and I hope it will be unified in future versions of Grails. >> more…
Per default, Google Analytics tracks the whole URL. As a lot of our URLs contain some parameters or IDs, and we’re not interessted in tracking them, we needed to find a way to truncate them. As Grails unfortunately does not provide methods to access the current view and controller (which is basically what we’d like to track) in GSPs, we used this code:
-
pageTracker._trackPageview(${request.getServletPath() – ‘/grails/’ – ‘.dispatch’});
Not as clean as we’d like to have it, so suggestions are welcome!
For the new application we’re building, we not only want to try new technology (Groovy and Grails instead of Java), but also a new way of deployment – some cloud instead of our own servers in the data center.
First thing we found was Google’s Application Engine, but this post points out some serious shortcomings. It only supports Grails 1.1.1 (current version at this time is 1.2.2), you can’t write to the file system (which is not too bad, because big table should be fine for our needs) and – that was the worst thing – there was no further development of the project. >> more…
Sometimes the easiest way is the right one – after a considerable time of research, trial and error we figured out, how to pretend to be a certain browser in a grails tests:
-
controller.request.addHeader("USER-AGENT", "mozilla")
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…
Grails supports filters, which are applied to each action – before or after executing the action or after rendering. The scope of those filters can be constrained by a regex-like syntax to a subset of all actions.
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”): >> more…
