Enum Usage in Grails
I started working on a super simple Grails application that will hopefully ingrain the basics into my brain. It is a Movie Database (I know...) application. I started off with a simple Domain class called Movie (wow, you say?) and a Rating property. Generally for a collection of data that is really not going to change I'll use an enum instead of a mapping table in the database. So I created an enum called Rating.
The problem became appearent because by default the <g:select /> tag will render the list of enum values just fine except the label that the end user sees is the enum.name() which in my case is G, PG, PG13, R, NC17, NR. What I want to present to the user is G, PG, PG-13, R, NC-17, Not Rated. Simple, I thought, I went into Rating.groovy and added a toString method that would return the value of the enum. This worked except because of the way <g:select /> works the value attribute of my options were wrong. They were my enum values (PG-13) instead of the name (PG13). So when I tried to persist a Movie I got a nasty exception to this effect.
After some googling and some Grails doc reading I came up with the following solution. I'm assuming this is the best way. It is pretty simple and it works, so good enough for me. I added a getKey() method to Rating.groovy so now the entire class looks like this.
Then I added optionKey="key" to my <g:select /> tag. This gave me the desired results and really doesn't feel hackish or anything. I spent a good hour trying to figure this out so hopefully this will get indexed by the search gods quickly and might save someone else a bit of hunting.
Time To Dig Into Grails
I've played around with Grails on and off for about a year. Something never really clicked for me. I'm not sure if it was the way the available books were written or my own ignorant preconceived notions about performance and being able to create anything beyond CRUD screens. Grails is Groovy, after all. And Groovy will always be slower than Java because of all the reflection. I'm not saying that in a haters kind of way. It's just fact. It's something that you accept when dealing with dynamic languages.
I recently stumbled on a screencast called Building Twitter with Grails in 40 Minutes. The screencast was so well done that it peaked my interest in Grails again. So I've started bugging people like Matthew Taylor (who is now an independent consultant so if you need a Grails expert, reach out to Matthew) about things like "When would you not use Grails" and "What is GORM really doing when you use dynamic finders". See, what has worried me about Grails and kept me away from it was the fact that so much is going on below the surface that I don't feel like I have control of. That screencast and the wisdom of Matthew have helped alleviate some of those issues for me.
I'm generally happy with my current stack; Stripes, Spring, iBatis or Hibernate/JPA. Stripes is the best action based web framework, IMHO, available. At this point in my career/life I'm just looking for something a bit more, full. I read an article yesterday called My Framework is More Productive Than Your Framework and so much of that article is so true. I don't think this article should be taken as reasons to not use Groovy (or insert favorite scripting language here) or Grails. I think this article is more about things to watch out for when using these other languages and tools. I kind of agree with some of the comments that suggest Ken just needs more time with the API. I'm sure 10 years ago, when Ken first started with Java, he had all the books and API docs open all the time. So I'm taking that article with a grain of salt.
From what little experience I have with Grails right now I think there is more to it than just quick project creation and CRUD screens. Most Grails developers I've talked to never use scaffolding. In fact, if you watch the screencast I linked to above no scaffolding is every used and no generator scripts are used after the initial create-app script. So my approach to Grails this time is going to be entirely different.
I've rambled a bit. This is probably me just convincing myself a bit more that investing some time in Grails is a good decision. I'll probably blog some more about my experience as I move along. Also, I'm sure I'll blast Twitter now and again if anyone cares to follow me.
Becoming the Mom I Wish I'd Had
No, I don't need to become a mom. I'm already a dad of three and that is challenging enough. However, a really good friend of mine has released her first book titled "Becoming the Mom I Wish I'd Had". The book officially went on sale today and you can purchase them through the link I provided.
Venus is an amazing woman who, with her husband, has raised two beautiful children. Be one of the first 100 to purchase a book (well, 98 because I bought 2 copies) and Venus will autograph your copy prior to shipment.
Groovy is Cool, We Get It, However...
Look, I think Groovy is great. I'm no fanboy in any sense of the word. But I do like it. For some tasks it can really save some time because it takes 15 lines of java code and condenses it to two lines. Obviously, there is a lot more to it than just that. Groovy has more than proven itself as a viable language for the JVM.
That said, I'm really quite tired of examples like the one given here. It seems that when you want to find reasons to use Groovy the file reading example is the one most folks give. Let me first say though that I agree with nearly everything in the article I linked to. This is in no way a response to that article specifically. What I want to point out though is that yea, dealing with exceptions can be "icky". They can also save your application from utter failure.
My biggest problem with the file reading example is that they fail to address the most common failure scenario. The file doesn't exist. If you take those 2 lines of groovy code, put them in some production system and the file you expected to be there was missing, your application blows up. Write all the tests you want (if you're smart you write tests for dynamic languages), you can't control missing files. Under the covers groovy is doing what those 15 lines of java code do and it still throws an exception. At the very least, if you must prove that groovy is better for reading files than java, include the code to ensure the file exists first. It's one extra line of code so your example becomes three lines instead of two. Your point is still received and your code doesn't fail. That's all I ask.
DRY CRUD DAOs with iBatis
I blogged before about writing DRY CRUD DAOs using JPA. I was able to improve on that thanks to many comments from other users. So thanks for the tips. On a recent project we decided to go with iBatis and I wanted to see if it was possible to use the same methods that I use for JPA based DAOs.