Nathan Crause

After having worked in Ruby on Rails and Grails for a bit now, something occurred to me that's a little odd about their designs. In this particular observation, both the frameworks end up with the same net effect (but achieve it in different ways). The issue in question is how to declare different methods within your objects, and using HTTP-related objects (such as request and response objects).

The issue is most readily observed in the controller syntax of both frameworks. RoR is a little more OO in this regards in that your controller must extends a basic controller object from the framework. Rails then exposes all the public methods in the controller as "actions" which can be called via a URL. However, there are no parameters passed (this is likely because polymorphism isn't supported in the Ruby language). So how, then, are we to gain access to the HTTP request and response objects? Rails seems to favour using globals for this task. The obvious problem here is that multithreading is ignored entirely - a known and understood shortcoming of Rails, and we can clearly see here how to came to be so.

Grails, on the other hand, does not require extending any base class. As with domain classes, the framework seems to fudge the class at runtime. However, instead of using methods to expose actions, Grails favours the use of named closures. Presumably, therefore, the HTTP request and response objects are passed in as closures variables, which are ultimately invisible in the declaration of the closure. This is marginally better than Rails in that thread-safety is maintained.

My problem with both approaches, however, is the lack of formal parameter declaration. Love it or hate it, knowing what parameters are passed, and what exceptions  can be thrown often helps a programmer. It's almost as if both development teams were so fanatical about reducing the amount of typing a programmer has to do that they ignored debugging. This can be particularly seen in Grails, where any underlying domain class problem requires modifying the Log4J settings to display all hibernate messages (I know that this is being addressed somewhat is Grails 1.2, but the point is still valid).

I do understand the point of coding speed, really I do, but what I'm finding is that the learning curve is actually quite brutal for both frameworks because of the amount of things are not immediately visible. To me, having to Google everything seems more tedious than typing maybe a dozen or so letters out.

Most of this is really just personal preference, so ultimately it's all moot, but this is my opinion.