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