Well, it finally happened. I launched my first grails app. There were really only two of us working on it, but my counterpart was mainly a style guy, so really its *my* first grails app. (Believe me, if you saw it, its nothing to really brag about but I'm still proud of my baby.) Being a Java guy from 8 to 5 and a PHP guy after-hours, I thought I'd contrast my experiences in comparison to my experience in doing something in grails.
First off, no you can't see this app, its for my current client and we don't want a ton of bunk data in our database etc considering its mainly a sales lead generation tool for my client. Sorry, I'd love to show it to you...but I can't, so I realize I'm losing credibility already. That being said, lets get to it.
The application itself is basically a wizard that walks a prospective client through a rather long application process. At certain times throught this process, depending on the user's choices, a sales lead is created and updated or an application is created and updated with the ultimate goal ending in taking the users credit card and enrolling them in the program.
I had half of the app written in PHP before it was decided we'd use grails so it could be deployed on the JVM and make integrating with existing Java apps easier. I was sad to have to say goodbye to PHP since I found PHP (along with Code Igniter) to be a refreshingand light vacation away from heavy, layer-infested clunkers that Java applications seem to have become. However I had read about grails and been to a few talks and was excited to give it go.
Already having a good clue of what our object model "should" look like, I found myself getting started rather easily. I kept the grails reference manual open on another tab in Firefox the whole time and my Groovy Recipes book was never more than a few inches away.
I really liked that I could define my objects first and have the database create the tables on the fly, and then be able to modify that object and see those results immediately. With PHP/Code Igniter I had written a code generator so the code generation wasn't a really big deal to me, and it does/did generate my sql, but completely lacked this "hot deploy" of changes. That made things really nice. And the look and feel of the "out of the box" admin interface was much slicker than my generated default styles. With Java...well, I'll never go back to traditional Java as long as grails is an option for me.
I'm used to the controller flow, so again I was used to the simplicity of architecting an app in this manner, however, I find that my Groovy code inside that controller is much more concise than what I've written in Code Igniter. My controller felt lighter and cleaner. Again, traditional Java compared to the grails approach...*vomit*
The grails gsp tag library is where I really was impressed, not because is was anything new, but because it was so easy to extend and create custom tags. I wound up creating a state drop down list that would generate a drop down list for states and their abbreviation for use on several areas of our application. It checks for a passed in selection and show that one or just lists them alphabetically with a "Select..." option at the top. Anywhere I needed that list to appear, I simply had to enter: <g:stateDropDown selected="${state}>" /> and I was done. It was _very_ easy to add. I've done similar things in PHP, but I must admit, outside of using Smarty or some of Code Igniters HTML helpers, I'm really not impressed with some of PHP's "views" and it tends to get cluttered. (I must admit it really doesn't bother me that much, but I'm comparing here...).
Another thing I want to compare was the ease in which I could wrap security into this whole thing. We didn't need a huge implentation so we went with JSecurity. It was as easy as running "grails install-plugin jsecurity" and then ran a couple scripts specific to JSecurity and I had security. There are apparenlty some pretty good plugins for PHP/Code Igniter for this as well and I can't compare them accurately here since I've always rolled my own. In Java...I woudln't know where to begin to be honest, but I certainly wouldn't want to roll my own in that world.
Oh yeah...deployment...I'd much rather deploy a PHP app anyday, especially compared to Java, but Grails made deploying a Java app pretty damned simple. Running "grails war" created a war file that we could just drop in place. However at this point grails can suffer from gotchas that tradition java apps have. Normally we can just drop the war file in place in tomcat and things are fine. However we were using one of the apache mail jar files and our installation of tomcat (on RHEL 5) came with some javamail jar and for some reason that is still unclear, the email portion of our app was failing miserably and the stacktrace was really not helpful. (Not all tomcat installations have this issue, but apparenlty our rpm install did, once we removed the link to javamail.jar, it worked like a charm). I've never had such issues with deploying a PHP application. Also, I couldn't find a way to prevent grails from displaying the stacktrace on the page, and in some cases the information grails was reporting is/was very dangerous information to be displaying.
In the end, I know I'm going to use grails again and again. I have no intention of leaving the PHP world, and certainly not with the changes on the way and the affordability and availabilty of hosting. I have a feeling my grails stuff will likely be limited to the corporate world especially where Java is already in the door. (I also think it'd be an easier "sale" in that world). In situations where my client may not be able to afford their own infrastructure or dedicated server, I'll definitely be choosing PHP.
I'm glad to say that I've got both of these tools under my belt and look forward to my next grails implementation, but I'm also looking forward to getting back to Code Igniter. I geeks work is never done, but we like it that way I think.
~
:wq!
~
:wq!
~
:wq!
~
:wq!
~
:wq!
~
:wq!
Copyright 2008 -- all rights reserved