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!
We are using Groovy on Grails for an incubator project, which is incredibly refreshing! Groovy as a dynamic language with optional type annotations doesn’t quite rock my boat though. With static type checking the types you define are an essential element of design. I like to point out that Groovy’s creator wrote:
“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.” >> more…
One of the biggest advantages of Groovy over Java are those nice little collection helpers. For people who first encountered them in functional languages the names are confusing. Here’s a short comparison:
| Functional Language |
Groovy |
|
| map (list, function) |
list.collect (closure) |
Applies the function to each element of the list and returns the results as a new list |
| filter (list, function) |
list.findAll (closure) |
Returns a list of all elements in the input list for which the function returns true |
| fold (list, initial element, function) |
list.inject (initial element, closure) |
Applies the function to the initial element and the first element of the list. Then applies the function to this result and the second element of the list. Get the idea? |
>> more…
Hunting one of the strangest layout issues in IE – if you hover over an element, the input elements on the page mysteriously move down – we learned about the very strange concept of “layout” internet explorer employs: Give your elements height, width or one of the other CSS-properties that “cause an element to have layout” (I can’t help but giggle when I read this, and I have no clue what it’s supposed to mean) and many of your IE display issues will disappear. >> more…
Although it may seem to be obvious for experienced web page authors, it was a discovery for me: XHTML does not understand special symbols “&” and “<” if written directly. So it’s impossible for example to perform “and” operation (&&) in javascript on the page.
There are two solutions for that:
1) Use CDATA for such sections of data, f.e.
-
<script type="text/javascript">
-
//< ![CDATA[
-
function enableDisableRegisterButton(element1, element2) {
-
registerButtonWrapper.disabled = !(element1.checked && element2.checked);
-
...
-
}
-
]]>
-
</script>
>> more…
When we are editing web pages in our favourite IDE we expect that it will provide code completion support for all tags and their attributes we use. It is true for plain HTML pages as well as for JSPs and of course XHTMLs. How does code completion works? Very simple: we need to include tag library in page template and that’s it! IDE should analyze this tag library and use tag metadata to provide code completion for page author automatically. Of course tag library should contain all neccessary information for tags, their attributes, functions, etc.
When we create tag library for JSP everything is straightforward: tag library schema support all this information. So we simply create something like that: >> more…
Didn’t know these still existed:
-
// This variable enables domain checking, if it is set to true domain checking will be enabled, conversely if it is false
-
// domain checking will be disabled.
-
// Example : var elqIC = true;
-
// Default : var elqIC = false;
-
var elqIC = false;
Taken from JavaScript code provided by the leading online marketing automation provider.