Using DSLs for validation
More examples of internal DSLs can be found in Rails and Grails. Listing 6 is an example of validation in ActiveRecords in Rails.
Listing 6. Validation in Rails
class Person
validates_presence_of :first_name, :last_name, :ssn
validates_uniqueness_of :ssn
end
I find the validation syntax to be very easy to read and understand. It is highly expressive; once you get the hang of it, adding and modifying validation logic is a breeze. Similarly, GORM in Grails supports constraints for validation, as shown in Listing 7.
Listing 7. Validation in Grails
class State
{
String twoLetterCode
static constrains = {
twoLetterCode size: 2..2, blank: false, unique: true }
}
The examples you have seen so far are for programmers (with the possible exception of CSS, which is often used by Web designers as well). But DSLs are not exclusively tailored for that audience; they can be deployed by anyone who uses an application. For instance, easyb is a behavior-driven testing framework that lets users write stories that express and validate application behavior. Validation in easyb is based on a story DSL, which bridges the gap between developers and business stakeholders.
Listing 8 is an example of a story written in version 0.8 of easyb. easyb's story DSL takes advantage of Groovy's flexible syntax and metaprogramming capabilities. The vocabulary terms, like given, when, and the like, are simply methods that accept a String parameter and a closure. When you exercise the story, easyb will execute the closure, if provided, letting it interact with the underlying application and assert its behavior.
Listing 8. A story in easyb
//transferMoney.story
scenario 'transfer money', {
given 'account numbers 123456789 and 123456788'
when 'transfer $50 from 123456789 to 123456788'
then 'balance of 123456789 is $50 less'
and
then 'balance of 123456788 is $50 more'
and
then 'transaction has been logged...'
}
The code in Listing 8 is executable documentation, and a domain expert or business analyst could write it. Later, a business analyst or a programmer could integrate it with the application by filing in glue code to calls to the service layer of the application. You can execute the story in Listing 8 using the following easyb command:
java -classpath ... org.disco.easyb.BehaviorRunner transferMoney.story
In which case you will get the following output:
Running transfer money story (transferMoney.story)
Scenarios run: 1, Failures: 0, Pending: 1, Time Elapsed: 0.431 sec
1 behavior run with no failures
easyb processed the story and indicated a status of Pending because the code has not been integrated with your application.
What I like about easyb is its lightweight, expressive syntax, which can be easily understood by programmers, testers, managers, domain experts, and business analysts. The DSL syntax of easyb provides an ubiquitous language for communicating the application's domain knowledge and requirements.
In conclusion
Once you wear your DSL glasses, you will start finding countless examples of these specialized languages around you. You've seen a few examples of them in this article. In the next article in this series, you will learn some of the characteristics of a DSL. That will provide you with a foundation for creating DSLs of your own, which we'll practice in the latter half of this series. For now, just try to notice the DSLs all around you. When you do encounter a DSL, explore it to see how it is tailored for its particular domain.
This story, "Creating DSLs in Java, Part 1: What is a domain-specific language?" was originally published by JavaWorld.