Disclaimer: This entry has been written while listening to the talk. Please forgive me any typographical or grammatical errors resulting from this approach.
Last day ofSpringOne 2009 – Graeme Roche will talk about how the Grails framework leverages Spring in order to increase developer productivity. Graeme is the founder of the Grails project and Spring lead for Grails.
He started with the basic message “Grails is Spring” (basically just Spring MVC in disguise). He also stressed that Grails is a full scale environment providing a complete stack from UI to persistence. There he also mentioned the plugin mechanism that is easily extendable and provides a lot of power for new feature additions. Basically Grails itself is just a set of plugins with a number of default plugins making up the default system.
Grails itself uses the Spring Web MVC call structure and configures Spring Web MVC to simply to delegate to appropriate Grails controllers. Graeme proceeded with the pet clinic demo from Grails 1.1 and – after solving some problems with his notebook – explained the many conventions available to develop applications with Grails. He stressed the fact that it is possible to seamlessly mix existing code with Grails approaches due to the underlying Spring application contexts defining the accessible beans. What I disliked about the demo wa thumber of bugs that occurred during the live presentation – and were somehow fixed. But those fixes were not really obvious – at least for me. That Groovy seems to care for the order of property and method definitions also felt… threatening.
He proceeded to indicate and partially demonstrate that Grails is running on Google App Engine. He announced that GORM soon will be running on App Engine. I’m pretty curious about that since my impression was that Google supplied a pretty specific persistence support that does not work too well with Hibernate.
One interesting question concerning plugins was how to manage dependencies and side effects of mixing plugins to which Graeme responded that the plugin configuration is just a Groovy file that also can contain conditional blocks, etc. which you can use to check for other plugins, etc. I shudder at the thought of having huge conditional chunks in configurations… and then the other plugins change their assumptions and your assumptions in your conditional blocks subsequently fail and… you get the idea.
Side note: Grails 1.1 will be out next month.
Overall the presentation was decent but plagued by many problems with Graemes notebooks. His TextMate editor kept crashing and even Java segmentation faulted once which distracted a bit from the stuff he was showing. Grails – as expected – seems to be a very decent framework if you like convention based approaches. Personally I believe that this is a great approach for some problems but once more too sophisticated for everyday problems – see my last post. Finally the number of bugs during the demos confirmed the initial impressions I got a year ago while trying Grails – I wasted an afternoon without even being able to get a rather simple master-detail-application to work… mostly due to hard to understand problems in the dynamic generation parts. Grails ones more is thus pushed back on my personal agenda for another six months.
