Griffon: Identifying the Dark Underbelly of Java
By Geertjan-Oracle on Sep 15, 2008
- "Generally, I find the code very manageable, I look at xyzController in the controllers folder, I know its views will be in a directory xyz under views. Domain objects are again easily located and the dynamic CRUD support makes database interaction very straightforward. Another benefit is anyone who has used grails before has a much better chance of picking up the code, as they know where to look for things."
From Grails and the power of code by convention
- "MVC: By far, this was the area that benefited the most from the port. What began as a big clusterf—k all in one file has evolved to a nice separation of MVC. Thanks to @Bindable and changing from a concrete class as a view to a view clousure, I was able to eliminate some useless instance variables and move what needed to referenced from the view to the model."
From Porting a Groovy app to Griffon
The latter comment is by one of the creators of Griffon, so he should know what he's talking about. Spend half an hour looking at the Griffon samples, try to make some of your own, revel in the coolness of Groovy, and then marvel at how manageable your application's source structure has become. Even better, lead your existing application back onto the path of righteousness (i.e., port it!) by following this article I wrote today on Javalobby. Griffon is to source structure what refactoring is to source code. Maybe a new term needs to be coined for source structure refactoring, because that's Griffon's (and Grails') main benefit, and—until you grasp that aspect—you won't "get" it.
The case for Groovy has been made a whole lot stronger via Griffon. If you want not just your source code, but also your source structure, to be clean and maintainable, then I don't think you've got much choice but to give Griffon a whirl. And you'll enjoy the ride since Groovy is so liberating!