Notes

So, after having learned a bit about Ruby, the next logical step for me was to try Ruby-On-Rails.

A bit of background: before going to work at Sapo in the XMPP Messenger product, I was a lead-developer at Novis. My main task there, was to build websites and provisioning systems, and the glue that ties billing systems with technical databases. We used a framework that was developed internally since '99, and in it's latest generation was called Apache::WAF. It was a MVC-style framework, with a strict separation between code and layout. The View was Template Toolkit, but it was extensible to other technologies (we used Mason a lot also). The Model where our own provisioning system libraries and other stuff. Apache::WAF allowed us to build the Controller very quickly. Also, it was pretty fast, using mod_perl.

So using MVC-style frameworks in web development is nothing new to me.

Except that Ruby-On-Rails is much more than that, and in a extremely clean package. You can get up-to-speed in no time, thanks in part to the generation of code that is the base of RoR, and also to the Screencasts available at the Ruby-On-Rails website.

Also, having a clean and powerful language behind it, it sure helps.

It's not perfect. The part of mapping URLs to controllers could be better. RoR uses the same setup that Apache::WAF uses: you register URL namespaces on a special config file and associate them with controllers. The main advantage I see with this approach is that you can look at this single config file and know all the URLs of your app, so clashes are less likely.

The Model part of RoR is just excellent. As far as I can tell, there is no Perl equivalent to ActiveRecord. Yes, yes, I know about Class::DBI and Alzabo, and the others. But those solutions solve the CRUD problem: creating, retrieving, updating and deleting one object at a time. They all have solution for forging relations between tables and objects. But ActiveRecord does all that and more. It's the first framework (and I really expect and would love to see some perl guru to jump on me on this one and say "Have you looked at X on CPAN?"...) I've seen that solves the 1+100 queries problem efficiently.

The 1+100 queries problem is simple to understand: suppose you have a Books table and a Authors table (for simplicity, a book can only have one author), and you want to list all the books with the respective authors.

With a basic CRUD framework, you do a Books->find_all or Books->search to get all the books and for each one, you do something like $book->author->name to get the author name. If the first query for books returns 100 books, you'll then do 100 queries for authors. Yes, yes, you could cache ID->name of authors, but that really is not the point. The point is that something that should be done with a simple join at the database level with a single query, is now being done with multiple queries (and if you write to me saying that "Yeah, but my MySQL is fast enough you wont even notice", I'll warn you right now that I'll verbally abuse you. Real world is a lot different).

ActiveRecord is able to solve this. You can say that "Please give me all the books, and also their respective authors" and with a single query to the database, you'll get a list of Book object with the author method returning a pre-created object. You can even specify which fields you need from author.

It's very very good! The Model in Ruby-On-Rails is for me the part that makes the most difference to the other MVCs I've used in the past.