jetztgradnet
is using Posterous to post everything online. Shouldn't you?
Grails is a fantastic framework. As well as being ultra-productive and fun to work with, it encourages good testing practices, and provides a swathe of tools to make writing unit, integration, and web tests a real pleasure. As we will see, Grails also lends itself quite well to build automation. However, Grails is not Maven. Grails has a fairly loose concept of the software development lifecycle, and is happy to let you bundle up and deploy your application as a WAR file without running all the unit and integration tests first. A Continuous Integration (CI) server can help you keep the flexibility of the Grails development process, and still ensure that your code is fully tested for each and every code change. In this article, we will take a look at how you can introduce Continuous Integration into your Grails project. More specifically, we will walk through how you can automate your Grails testing and code quality metrics with Hudson, a popular open source CI tool.
http://today.java.net/pub/a/today/2009/06/23/Grails-and-Continuous-Integration.html
How can we build user interfaces using GSP that are manageable and easy to update? Many of the books on Grails focus on the technology available in Grails, but very few give rules and techniques to make GSPs manageable.
Grails templates and the out-of-the-box functionality is great. But once you start trying to integrate layouts and designs for real world websites, you'll find that bad coding practices can quickly lead to a chaotic and unmaintainable mess of spaghetti code.
In this post, I want to share some tips, lessons and ideas I have learned from projects worked in the last year and a half of Grails UI development.
