DSLs are nothing new. Just by encapsulating the concepts of a domain in classes (”domain objects”) and by defining the methods on those classes that act on them (”actions” and “messages”), you create a DSL of sorts. You see this a lot in unit testing. As a body of unit tests evolves, common SetUp and TearDown code is often extracted to avoid duplication. As the extracted classes and methods grow and evolve, a DSL emerges. For an excellent example of this, see Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin.

Groovy accomplishes the creation of DSLs in a number of ways:

1. Optional Syntax: In Groovy, much of the syntax is optional: semicolons at the end of statements when they are the only statement on the line, parenthesis around arguments in a method call, etc. Dropping away such “noise” is one way that the user can then focus on the domain at hand.
2. Missing-Method Methods: In Java, if you call a method that does not exist, you get a compiler error. In Groovy, it waits until runtime to decide if it’s a problem, giving the class with the missing method a chance to make up a method on the spot. This is done with a special “missing-method method.” For example, this is how GORM allows you to make up method calls like findByPersonAndJobTitle(). There’s a missing-method method that knows how to parse out the name, “findByPersonAndJobTitle” see that it’s comprised of pieces it understands (a find action and two field names) and thereby construct the logic to perform that action.
3. Operator overloading: Groovy allows you to define methods that correspond to the various operators, like plus() for the + sign. This means your DSL could allow for expression like “car = chassis + 4 * tires” and “truck = (cab + 6 * tires) + (trailer + 4 * tires) + (trolley + 4 * tires) + (trailer + 4 * tires)”
4. Named Parameters: Grails has the ability to emulate named-parameters (which means that having to know the order in which to pass parameters is no longer a concern). This is done by defining the method to accept a single map as a parameter. Then, in the call, a map is created on the fly with hard-coded keys that look like parameter names, and expressions that are the corresponding arguments. Leave out the optional square brackets that normally enclose a map constant, and wallah! Named parameters:
5. Closures: Groovy’s strong support for Closures means it’s easy to define custom control structures
6. Categories, MetaClasses, and GroovyObject: Without going into details, these are some of the core facilities in Groovy that make it a dynamic “scripting” language and so suitable for expressing DSLs

Builders:
The most common use of DSLs in Grails is the idiomatic “builder.” This is for when there is a distinct hierarchy, or tree-structure to the elements of the domain. There are pre-defined builders for Swing, XML, HTTP, Hibernate Criteria, HTML, ANT, and the Constraints builder in Grails that drives the validation mechanism, just to name a few. It’s easy to create your own builders as well.

With the groovy.xml.MarkupBuilder(), for example, instead of having to write your own XML…

<stocks>
  <stock symbol='JAVA'>
    <quote day='Mon' price="53.125" />
    <quote day='Tue' price="54.5" />
    <quote day='Wed' price="51.75" />
  </stock>
  <stock symbol='MSFT' />
  <stock symbol='IBM' />
</stocks>

You can express the information like this:

builder.stocks {
    stock(symbol: 'JAVA') {
        quote(day: 'Mon', price: 53.125)
        quote(day: 'Tue', price: 54.5)
        quote(day: 'Wed', price: 51.75)
    }
    stock(symbol: 'MSFT')
    stock(symbol: 'IBM' )
}

At first glance, it might seem like you’re just trading one arbitrary syntax for another: parenthesis, braces, colons and commas, rather than angle-brackets, equal signs, and matched-up start and end tags. However, this is merely a dumbed-down example. The benefits of using a builder are enormous:

For one thing, the Builder syntax is universal. Once you know who to write XML markup using Builder syntax, you also know how to write HTML markup, Swing forms, Grails criteria, and all of the other pre-defined builders mentioned above, and more .

Also, since Builder syntax is built on top of Groovy, Groovy code can be intermixed with the DSL code. For example, we can use each-loops to build the XML markup from a “tickerInfo” object:

builder.stocks {
    tickerInfo.each {ticker ->
        stock(symbol: ticker.symbol) {
            ticker.dailyQuotes.each{
                quote(day: it.day, price: it.price)
            }
        }
    }
}

DSLs are a key reason for the success of Grails. Taking advantage of Groovy’s DSL support is a prime example of how much thought has gone into the architecture Grails with it’s prime directive to be as idiomatic-Grails as possible.

We’ve only just scratched the surface of what DSLs are and how they are supported in Groovy. Here is some recommended further reading:

• docs.codehaus.org/display/GROOVY/Writing+Domain-Specific+Languages
• How Builders Work
• Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin

Related articles:

• A brief review of Clean Code
• Everything’s Groovy
• IDEs for Groovy/Grails

Groovy is most definitely the star of the Grails show. Every decision that went into formulating Grails started with, “What’s the Groovy take on this? How can we best take advantage of the innate ability of Groovy to solve this?” This attitude makes for a framework that’s powerful, yet minimal and consistent.

This attitude also goes beyond the Web framework. Groovy can be used end-to-end from inside the web server pages to the outer build scripts and even your shell scripts. In the Java world, before Grails came along, one would have to work in seven different languages to build a web app. Grails potentially reduces that to three:

appender.'errors.File'="stacktrace.log"

to

appender.'errors.File'="../logs/${appName}-errors.log"

Determining What is Logged
Config.groovy also determines what is logged. The default logging level is error. For some packages, you’ll want to change the logging level to warn or info. Your choices are, in order: FATAL, ERROR, WARN, INFO, DEBUG.

Grails automatically generates a log4j.properties files from what’s in Config.groovy and places it in the /WEB-INF/classes folder. The log4j.properties file can be tweaked in place as you attempt to debug a particular problem, but just remember that it gets reset every time the app is deployed. So, permanent changes need to go in Config.groovy.

I used to be a big fan of Eclipse, but the Groovy/Grails support in Eclipse is sorely lacking.  Three months ago I splurged on a copy of JetBrains IDEA 7.0 (http://www.jetbrains.com/idea/index.html) and haven’t regretted it one bit.  I’m sitting on 7.0 build 7860 (”Selena”).  Since then they’ve released 7.0.4 (build 7941) and a preview of 8.0 milestone 1, but neither seem to have anything I need, so I’m sitting tight.  I am, however, anxiously awaiting 8.0 milestone 2,  which promises more Grails refactorings and support for Grails 1.0.3. (My projects are still on 1.0.2.)

I just saw an announcement that NetBeans 6.5 (free open source, http://www.netbeans.org/community/releases/65/) is in beta test and that it includes Grails/Groovy support.  For anyone doing Grails work who can’t afford IDEA, I suggest you check it out.  If you do, I’d like to hear from you.  Let’s compare notes.

Getting started with Grails requires two efforts: learning how Groovy extends Java, generally, and learning how Grails then takes advantage of Groovy for rapidly developing web pages. For the former, I highly recommend the brand new book, Groovy Recipes by Scott Davis (Pragmatic Bookshelf). Chapter three exactly and concisely explains what an experienced Java programmer needs to know to get started with Groovy.

After that, The Definitive Guide to Grails by Graeme Keith Rocher is probably where you’ll turn. Be aware, though, that a second edition is pending, and you’ll want to update your copy when it comes out, so budget accordingly.