First real-world experience with Grails
I’ve written a little bit about grails before, but until now I haven’t had a real application to build to really put it through it’s paces. At first I was going to build this application with Rails for the same reason, even deploy it on Glassfish with its RoR support. I don’t know though, something about an application that requires a new instance for every request just seems wrong to me. Seems like such a flawed architecture that I just couldn’t bring myself to do it. Yea, there are other Ruby based web frameworks and I might try one at some time, but not this time.
I also have to say that I generally don’t generally like any kind of black-box magic frameworks. Code generation and such tend to make me cringe, but what the hell I was going to give it a shot. Needless to say so far I’m pretty darn impressed. While I’m not quite finished it is moving along very rapidly, and adding features is pretty damn easy. I would say I’ve put in about 50 hours or so over three weeks and I am at about 85% finished.
What I like
This is ironic part. I really hate tools like Hibernate that force you into a specific format. Most of this stems from my corporate application experience where databases are far more complex than what ORMs like Hibernate can handle. However in this case the GORM has been a wonderful time saver. Setting up relationships has been fairly easy, although I had a few head-scratching moments that weren’t quite textbook and the docs weren’t very clear on.
I also really like the URL mapping stuff. I’m sure Rails has a good URL mapping engine as well, but I really like being able to customize these as I see fit. I still get a bit confused on what return/render method to use in the controllers, but it hasn’t been too bad.
What I don’t like
About my only gripe so far is with the BootStrap class. This is a great idea and wonderful for development, but man it can be a pain. Actually the gripe isn’t so much as the BootStrap itself but with GORM. Go figure.
There are cases where I have a three level deep object graph and populating it isn’t as straightforward as it could have been. Most of my problems have been when I populate the leaf object and then I need to get that leaf object later for some other reason. The getBy and findBy methods will sometime return a null object, even when I know the parameters are good. I end up having to retrieve its parent and then getting the child out of there. I would say I’ve spent about 20%-25% of my time just trying to get my simple test data in. I could very well be doing something wrong, but the docs haven’t shown me anything different and what seems intuitive to me apparently isn’t. Oh well.
I haven’t been doing anything nearly as fancy as Glen Smith but isn’t a “hello world” app either. My current stats are:
16 controllers with 864 LOC
12 domain classes with 245 LOC
1 taglib with 22 LOC
I know I’m going to have to write at least one new tag lib for paging, as the provided paging taglib won’t work for me. A shame because I really need it. I should be done with domain classes but I’ll probably add a couple more controllers.
All in all I’m pretty happy with Grails and I look forward to getting this thing public.
Don’t miss anything, subscribe!
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.
Comments
That works fine for building a graph, but where I ran into trouble would be when I needed to pull out an employee (to use their example) and apply it to something else. Calling something like Employee.findByEmail(’blah’) would return null, even that I added them.
Because DomainBuilder extends from ObjectGraphBuilder you may be able to use a reference, like it is shown in the following example
def company = builder.company( name: ‘ACME’ ) {
address( id: ‘a1′, line1: ‘123 Groovy Rd’, zip: 12345, state: ‘JV’ )
employee( name: ‘Duke’, employeeId: 1 ){
address( refId: ‘a1′ )
}
}
Because in Grails id is a valid property that has a meaning other than a reference, you may assign a different id strategy on the builder, something like ‘uuid’ instead of ‘id’, you just need to provide an IdentityResolver/ReferenceResolver pair and you’re in business
Not to beat a dead horse here, but again that works great for the root object, not an object down the graph. In my case I didn’t care what the ID generator was (using the default long). It wouldn’t load the object no matter what method I tried, at least not directly. I would have to do something like company.employees[0] to get the employee reference back.
More of an annoyance than anything else.
Check out Grails DomainBuilder:
http://grails.org/DomainBuilder