Rails, as you’ll no doubt be aware from the recent spate of blog-hype (sometimes so breathless in it’s praise that I fully expect some bloggers to keel over after choking on their own spleens) can be considered as a cross between AppFuse and NakedObjects, only for Ruby.
Like AppFuse Rails takes a series of technologies and with the help of some scripts creates a project for you in which most of the simple configuration and wiring is done for you. Like NakedObjects, Rails gives you a UI and persistence mechanism based on a domain model. Unlike NakedObjects Rails is highly flexible – you are free to change pretty much anything you want.
Initially the thing that makes you sit back and start to listen to at least some of the hype is the amount of work the helper scripts can do for you. Once you’ve created a DB table, you simply have to type:
ruby scriptgenerate model MyModel
To generate a persistable domain model and test stubs (I’ll talk more about the pattern used here later). Then you can generate the controller, with this simple command:
ruby scriptgenerate controller MyModel
Adding scaffold :recipe to the resulting controller dynamically enables all views required for CRUD operations for your Model. This can be shortened to:
ruby scriptgenerate scaffold MyModel
This does both of the above steps, and exposes all the scaffolding code inside your controller. For the most part, this code is there (in rails-speak) as scaffolding around your application. It’s there to get yourself started. As such you are encouraged (expected even) to edit virtually all the code generated for you – the obvious conclusion from which is that the generation steps have to be considered to be a one-shot deal. If you change the Rails version, you may now be required to edit much of your code by hand. This is by no means a fatal flaw – but when analysing the productivity gains of Ruby, the initial benefit of code generation should be seen as just that – an initial benefit. Rails will stand (or fall) based on Ruby itself – both its technologies, tools and workforce.
magpiebrain 
5 Responses to “Ruby on Rails and why code generation isn’t the bomb”
Rails, as you well know judging by the links on the side of the page, is more than a bit of code generation, it is accurately described as a “full-stack framework”. AppFuse is a “build file and directory structure” (the author’s description) that builds upon Erik Hatcher’s work in his Ant book.
Rails does do some code generation, yes, and it does set up your application such that it’s immediately ready for testing much like Appfuse. But you, as someone who has at least played with Rails, cannot possibly discount the usefulness of the underlying Rails libraries, or the ease with which they integrate, and Ruby of course plays a huge role in how clean Rails app code looks. The last few Rails releases have required zero changes to existing Rails apps, and the generated code for scaffolding is already pretty minimal.
AppFuse, on the other hand, is more useful to developers who want a jumpstart on stitching together the myriad Java application/persistence frameworks. Once that stitching is done however, you’re on your own and you have to learn Spring/Hibernate/Whatever (both the intricacies of their apis and configuration files, not to mention integration between them) to do your job, and you’ll have to use XDoclet generation every time you want to build. And you’ll also have to worry about incompatibilities between those myriad frameworks, and when errors strike, it’s hard to know where to start because of all the players involved: http://raibledesigns.com/page/rd?anchor=how_do_i_attach_a
They’re both useful, but you’re comparing apples to suspension bridges. I could go on, but I’d prefer my spleen to stay where it is.
(sorry about the problems with your comment not displaying – naughty MT).
The comparisons with AppFuse might be a little unfair, but I was focusing on the percieved benifit of the helper scripts, which as I said really isn’t the big deal. You then talk about how good the rails libraries are – I’m going to say something potentially controversial here – the only thing that makes Rails libraries better/easier to use/more elegant than the Java alternatives is the language itself, not the implementation. If Java had similar language features to Ruby, you’d have similar libraries – they’re all solving the same problems, and in the same way.
You are saying that Rails libraries are:
better/easier to use/more elegant than the Java alternatives because they are written in Ruby.
No controversy, man. It’s the truth.
I’ve seen a few people get hung up on the code generation aspect of Rails, but it really isn’t an important feature of the system. If you look at the code it generates (with the exception of scaffold) it’s literally only creating two or three line class definitions – it’s a bit like using an IDE which sets up your Java class definitions for you. Rails’ code generation is passive, not active, which means you are expected to fire it once and edit the code yourself from then on.
What makes Rails interesting (and exciting and productive and hype-worthy) is that it’s exceedingly well designed. I say this as someone who has experimented with pretty much every Python web framework out there – Rails is a extremely elegant, and solves the web problem in a much more natural way.
Forget about code generation: examine Rails based on the merits of the framework itself. You’ll almost certainly be impressed.
Which was kind of the point of my post, but it did get lost in translation from my brain to blog š