I had a few hours this weekend to continue investigating the possibility of using of using Grails and Groovy to implement a solution for a client, and I’ve learnt enough at this point so say for this project I am committed to using Grails.
I was already liking what I was seeing, but was uncertain early on if this could realy do the job, but now I am sold. It really is Groovy; it is awesome. The productivity gain from using the ‘coding by convention’ approach made popular by Ruby on Rails really is awesome. It is amazing. In comparision with working with multi-layered architectures where as a developer I have to code each indiviidual slice in the application from end to end and then spend just as much time on the configuration to wire them all together – this is amazing. Groovy and Grails are so concise and gets the job done with minimal effort and coding, and yes – minimal if any configuration.
Ok, I learnt a few lessons at the weekend, and came across a couple of issues that I logged with Grails JIRA:
- Creating a Grails web app WAR
- Deploying a Grails WAR to 4.0.x
- Using EJB3.0 entities with the Grails build scripts: the build script needs to include an import statement with the full package name in the generated Controller classes, otherwise the code will not comile next time you run the grails script.
- the g:select tag does not generate the correct HTML when working with EJB3.0 entities. For this reason I switched back to using the Groovy implemented domain objects instead, which actually turned out to be a lot more concise.