Grails Dynamic Dropdown

Recently I had a UI requirement where a customer wanted to select values from two separate dropdowns. The value of the first dropdown essentially filtered the values for the second dropdown. Given the financial projects we support are not heavy on UI requirements, I had to do some initial learning and experimentation to yield a good implementation. This blog entry details the how to implement dynamic dropdowns in Grails with ajax and minimal JavaScript.

Example Problem

A contrived for dynamic dropdowns can be described below:

A user would like to select a sports team for a city. The user first selects a value for a dropdown to choose a city. A second dropdown is filtered with the sports teams within that city. An example to clarify:

• The user selects Dallas as the city in the first dropdown. The second dropdown now displays values: Mavericks, Cowboys and Rangers.
• The user selects Pittsburgh as the city in the first dropdown. The second dropdown now displays values Steelers, Pirates, and Penguins.

High Level Design in Grails 

Before we get into the details, we can take a step back and describe how we can accomplish a dynamic dropdown in the grails framework.

• On a gsp page, create a select dropdown with the list of cities.
• On change of the city dropdown, send an ajax call to the server with a param of the city selected.
• A controller on the server receives the parameter and looks for teams based on the city selected.
• Return a template with a new select dropdown for the teams, providing a model with the filtered list of teams.

We will continue below with code snippets. The code was demoed with Grails 2.0.

Domain Objects
The domain objects for this example are quite simple: A City object with a name, and a Team object.

That's Not Agile!

If you work with a bunch of agile minded developer's, you often hear the phrase "That's not Agile!" It's quite humorous to hear, because it comes up all the time.

Recently I have been reading Andy Hunt's books and I find them very insightful. The latest book I am reading is "Practices of An Agile Developer", which he co-authored along with Venkat Subramanium. At the beginning of each section they place a little quote which represents a "devilish" thought. They are entertaining to read, so I thought I would pick out some of my favorite and post them along with my thoughts. If you are agile minded like myself, you will certainly think "That's not Agile!"

Blame Game

"The first and most important step in addressing a problem is to determine who caused it. Find that moron! Once you’ve established fault, then you can make sure the problem doesn’t happen again. Ever."

This attitude is rooted in the blame game. Agile is about providing solutions, not assigning blame. If you run into this atmosphere, try to bring a positive outlook to it and solve the problem first. Allow room for a retrospective to mitigate problems in the future, but for pete's sake, don't blame.

Hack

"You don’t need to really understand that piece of code; it seems to work OK as is. Oh, but it just needs one small tweak. Just add one to the result, and it works. Go ahead and put that in; it’s probably fine."

Under time pressure, this thought will definitely come up in any reasonable person's mind. If you think about it, this mindset is a hack. Responsible developer's should understand what they are getting into. This doesn't mean getting into analysis paralysis, but always look for ways to understand, refactor, and improve the code. The trade off in doing that must always be a consideration, but a hack mindset only leads to distressed code in the end. Weigh the options. Refactoring and understanding the code you are working will pay for itself quickly. 

Egotism

“You have a lot invested in your design. You’ve put your heart and soul into it. You know it’s better than anyone else’s. Don’t even bother listening to their ideas; they’ll just confuse the issue.”

Agile is about collaboration and learning. I have run into this egotistic attitude many times in my career. I would hope an agile team is about ideas, not who is behind the idea. In addition, even if you have a design, it means nothing until you prove it out in code. Tracer bullet the idea instead of arguing, and you will probably come up with a better design in the end anyways if you consider others' input. Don't invest too much in upfront design. If you do, you are missing out on evolving your design.

Stagnant

“That’s the way you’ve always done it, and with good reason. It usually works for you just fine. The ways you learned when you first started are clearly the best ways. Not much has changed since then, really.”

I'll just say it. This is my favorite. That's not agile! At all. In an environment of continous improvement and value creation, this is the last thing you should hear. Especially in the technology field, we need to brace for change and accept that new ideas may be better then the old. I'll borrow a quote from the athletic arena, "If you ain't improving constantly, you are getting passed up."

Feel free to add your own quotes based on your past experiences.

Groovy DSL - A Simple Example

Domain Specific Languages (DSLs) have become a valuable part of the Groovy idiom. DSLs are used in native Groovy builders, Grails and GORM, and testing frameworks. To a developer, DSLs are consumable and understandable, which makes implementation more fluid as compared to traditional programming. But how is a DSL implemented? How does it work behind the scenes? This article will demonstrate a simple DSL that can get a developer kick started on the basic concepts.

What is a DSL

DSL's are meant to target a particular type of problem. They are short expressive means of programming that fit well in a narrow context. For example with GORM, you can express hibernate mapping with a DSL rather than XML.

  static mapping = {
    table 'person'
    columns {
      name column:'name'
    }
  }  

Much of the theory for DSLs and the benefits they deliver are well documented. Refer to these sources as a starting point:

• Martin Fowler - DSL
• Writing Domain Specific Languages - Groovy
• Programming Groovy - Chapter 18

A Simple DSL Example in Groovy

The following example offers a simplified view of implementing an internal DSL. Frameworks have much more advanced methods of creating a DSL. However this example does highlight closure delegation and meta object protocol concepts that are essential to understanding the inner workings of a DSL.