Wednesday, February 28, 2007

The End of the Tunnel

Ok, so I've finished the book. And first off, I should say that I think Jason Rudolph is a very good author in communicating Grails to the newbie. He really has a skill in taking you organically into the subject matter, and his writing style is relaxed and 'easy on the eyes'. Nice one Jason!

So I finished my last post as I was about to head into authentication. Again, I was impressed with how easy it was to add 'security' to my application, at the method level. It was a closure at the top of my controller class, and I was done. Very slick. I do recall this is how Rails works as well, so wasn't completely taken by surprise.

The rest of the book went into tweaking the UI with improved layout, which uses Sitemesh. For those not familiar with Sitemesh, it was created by the very capable Joe Walnes, and was part of the OpenSymphony suite of frameworks, along with other capable frameworks like WebWork, and OSCache. I've used Sitemesh on former web application projects and it was very capable. Grails uses Sitemesh under the covers but you don't actually realize it until you see the Sitemesh configuration file in the WEB-INF folder - though you don't actually have to edit the file at all. It's just, there. There's also some coverage of CSS tweakage, but that was fairly standard and as expected.

Grails has built-in support for testing, just like Rails. It generates placeholder test classes for you to embellish. I won't testify to being an uber-unit-tester, but it's there, and should I develop the discipline further, it'll be handy. Testing your application, once you've filled out the tests, is as simple as 'grails test-app'.

Grails has built-in support for logging using log4j. From what I can tell it logs error messages by default. I'm not sure if you can use other levels, like INFO or WARN, but there must be a way. The author didn't indicate what that way was though. I'll have to look into that. Nevertheless, there are separate log4j.properties files for development, test and production, which is again slick. It's never pleasant leaving a logging level at DEBUG on a production deployed application.

Lastly there's the deployment of your application. A very nice touch is that 'grails war' will package your app for you in your chosen environment (dev, test, prod), with all the targeted settings, into a neat deployable WAR. 'Production' is the default but you can type 'grails dev war' for instance, and you'll get a development WAR with your development settings.

So, what conclusions do I have? Well I certainly am very impressed with how 'complete' grails is. At v0.4 I almost expected to see lots of "To be done" comments and sections, but really it's quite mature for such a young project. I've done some reading in blogs and such, and there are doubts cast about its maturity and readiness for enterprise deployment, but it's clear from the core developers intent that enterprise is their target. I certainly can see how Grails will be a productive framework to develop with. And I do plan to use it on a greenfield project I'm about to embark on. It's a personal project, but one aimed for an enterprise environment. So we'll see how it goes. I'm still ignorant as to how Grails works once deployed. Are those Groovy scripts reinterpreted on every request/response, or are they compiled to bytecode on the first execution and reused from there. I don't much fancy a 'reinterpret' design to a web application that I'd like to scale to high load. But these things can be subjective, and the proof of the pudding is in the eating.

Pudding anyone?

2 comments:

Anonymous said...

A few quick things for you:

1. Logging. Standard log4j so you can trace/info/debug/error whatever. Only controllers have a log supplied in Grails 0.4. Grails 0.5 head has log objects supplied for you for all artefacts (domain class, services, taglibs etc). By default Grails produces config files with logging set to info level only. It is trivial to edit.

2. Deployment and Groovy code. Groovy code is never interpreted. Groovy code is always compiled to Java bytecodes on the fly, and this results in a normal Java Class in memory. Repeated calls require no new parsing, compilation or interpretation. So like JSP, the first hit is slower, but later hits are "full speed" in groovy terms.

Keep having fun :)

Splab said...

That's excellent news. Thanks for the feedback there Marc.

I figured as much about the logging, just hadn't come across anything on that yet.

Jason's book was an excellent primer on Grails, but now I need to dig under the covers to fully understand everything. Looking good though.