Over a million developers have joined DZone.

Grails for PHP developers I

DZone's Guide to

Grails for PHP developers I

· Web Dev Zone ·
Free Resource

Access over 20 APIs and mobile SDKs, up to 250k transactions free with no credit card required

Michael Kimsal shares his thoughts on Grails from a PHP developer perspective. In the first part of this series you'll find what motivated Michael to give Grails a look and some gotchas you may find when trying Grails coming from PHP.


I’ve been developing with PHP since 1996, since the days of PHP/FI. During that time, I’ve also used other platforms (ASP, ColdFusion, Perl primarily), PHP as a language, even with all its quirks, has generally been the most comfortable. Yes, its got its faults, but its felt like a good balance between pragmatism and idealism to me, and has powered millions of sites around the world for over a decade.

In the last couple years though, I’ve gotten the itch to start looking at other platforms. The Ruby/Rails phenom came about, and I took a look. I saw some power, but it didn’t excite me. I followed a lot of the 3rd generation PHP frameworks out there, but it felt so much like warmed over ideas I’d dealt with years prior, and the answers in PHP didn’t seem much better than they did years ago. I looked in to both .NET and standard Java as avenues for new exploration. Both were interesting, but neither ‘got’ to me. I certainly learned a lot going through some exercises with them, but ultimately neither hooked me. Part of that was that at work, I was still doing PHP day to day, and there wasn’t enough chance to spend time on .NET (for example) with ‘real’ problems, but that’s only a partial rationalization.

Early Grails

Enter Grails. I can’t remember exactly when I first heard about Groovy and Grails, but I believe it was early 2007. A colleague at work was learning a bit of Groovy, and as luck would have it, both a Groovy and a Grails presentation were happening in my backyard at our local Java User Group (trijug.org). Scott Davis‘ presentation on Groovy was inspiring, and opened my eyes to the possibilities of running a dynamically typed language (Groovy) on the power of the JVM. Having done PHP and Perl for so long, the rigor required in learning so much ‘extra’ stuff to deal with straight Java always felt like way too much work for really little benefit. flame away if you must, but I’m certainly not alone in this thinking. Being able to write ‘Java’ in Groovy, and avoid most of the boilerplate notations the language requires just to compile was, as I said, inspiring, and I began to look at Groovy in more detail. The next month (or perhaps two later), Jason Rudolph presented his tutorial on Grails. Although Grails was only at an 0.6 release, I could see a lot of the power behind the system.


Like many other popular frameworks, Grails is a ‘convention over configuration’ platform. Similarly, many of the choices a Java developer has to make before starting a project are made for you. Sure you can swap components out if you know what you’re doing, but out of the box, Grails provides an in-memory database which needs no configuration (HSQL), a templating framework (Sitemesh), an ORM (GORM) and a persistence layer (Hibernate), all tied together with everything in its place, and functional with no additional configuration.

Another attraction for me was the newness of the project and community. This was a project that I could get involved in early enough to perhaps have some impact, or just start early enough such that fewer people could have more experience than me at it. While perhaps a bit selfish, this had certainly not been a bad thing when I’d picked up PHP back in 1996. Few people had even heard of PHP, and most people doing serverside work were using Perl, or clunky MS HTC components, or other equally awkward technologies. There was a bit of a shakeout in the late 90s, and we were left with PHP, CF, ASP, Perl and Java/JSP as the ‘big 5′. PHP has continued to climb, mostly at the expense of CF and Perl, but having years of experience around the same time as PHP was beginning to have a higher profile certainly didn’t hurt my marketability.

With Grails and Groovy, it’s not quite the same. As everything ultimately compiles down to Java, I’m still at a disadvantage from that perspective. I’m not a seasoned Java veteran, so some things that just ‘make sense’ in the Java world are still foreign to me. But being able to use the relatively rapid development aspect of Grails and Groovy has helped cut down on my learning curve such that I’m now more comfortable in at least certain aspects of the Java web app world, and am getting more fluent every month. It’s those foreign aspects to life in the Java world that I’m going to present more here, in hopes of making Java development less painful for non-Java people thinking about giving it a try.

Objectives / Topics

So, after that long intro, what is the purpose of this article? This will serve to document some of the issues I’ve had working on some ‘real’ Grails projects over the past several months, and do so from a PHP developer perspective. Ultimately most of the issues I faced might confuse any non-Java developer, but I’ll be making my comparisons mostly to PHP. Also, this won’t just be a list of things that are ‘wrong’. I will cover some of the goodness that Groovy and Grails offer that interested me in the first place.

Some of the key pain points I hit during development were:

  • arrays/lists/maps
  • form arrays
  • hosting
  • gsp rendering
  • output buffering
  • getHeader vs getXXXX
  • sending emails
  • Java scoping

Some of the good bits - things that seem significantly easier in Grails and Groovy:

  • O/R Mapping
  • XML processing
  • Domain driven development
  • Closures
  • Builders
  • Save/reload/test development cycle

Let’s start off with some of the ‘gotcha’ issues that hit me during my Grails development.

Lack of $_SERVER

I think many PHP developers get used to looking in $_SERVER for anything they need about the request. Well, not *anything*. Values incoming that are directly from the user or client that represent client input generally reside in $_POST, $_GET, or sometimes $_FILES. We’ve had these ’super globals’ in one form or another for 7 years, if memory serves correctly. Things in the $_SERVER array include the PATH_INFO, HTTP_REFERER, USER_AGENT and such. Surprise, surprise, but all these things are not available in one spot.

Frankly, I didn’t see a whole lot of documentation in the Grails world at all on this topic, but that’s to be expected I think, based on what Grails *is*. It’s a standard way of doing servlets, and there’s already documentation out there for servlet processing. However, for most developers accustomed to PHP, having to wade through (yes Java guys, that’s what it feels like!) mountains of sterile Javadoc pages just to find a method signature with no code examples is not the most enticing way to attract developers. I can’t even remember exactly where I saw anything to indicate the following, but eventually I discovered that the ‘request’ object which is injected in to your controllers’ methods has some methods of its own to get you this information. Here are a few comparisons:

PHP Grails
$_SERVER[’REMOTE_ADDR’]; request.getRemoteAddr()
$_SERVER[’HTTP_USER_AGENT’] request.getHeader(’User-Agent’)

Right there, the Java model had me lost. For *some* pieces of information - PathInfo, QueryString, etc - there are specific getXXXX() methods defined. For others - UserAgent, for example - the information is just stuck in a generic ‘headers’ list, which you access as shown in the example above. And don’t think that you can just use the getHeader() approach for all the data you want - it’s not all in there. For someone used to the consistency of all data being in one array list, this was definitely confusing. I also realize it’s not going anywhere, as this is a defined servlet interface and has been this way for years. See this java documentation for more information.


#1 for location developers in quality, price and choice, switch to HERE.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}