As mentioned in my last post, I’ve been reading a book about Ruby on Rails. This book, Agile Web Development with Rails, consists of two major sections. In the first, a demo application (a shopping cart) is written. In the second, you get an excellent look through most major features and concepts in the Rails framework. The book also includes a (breif) primer to the Ruby language.
Rails is an interesting beast. It forces the design pattern of MVC down your throat. This, however, is not a bad thing. It allows Rails to make a bunch of assumptions about how your application is going to work. Based on these assumptions, Rails picks lots of sensible defaults. And Rails is all about defaults. Defaults save you time.
So, now, lets ponder the model. The model is the data your application deals with. Normally, this data is stored in a database (Rails supports MySQL, Postgres, Oracle, and more). But, since Ruby is an object oriented language, it would make sense for us to translate the model from a relational database into objects.
This is where Rails’ concept of models comes in. When you start a project, rails generates a lot of files with code stubs for you. In our project/app/models folder, we’ll find a bunch of classes that link together database tables. We can also find things that tell the model what to accept and what not to accept as valid input for a field. Rails even has a number of hooks that allow us to insert our own code to be run before or after a database operation (like, we can add a method to automagically log something every time we save an object).
Rails uses a kickass package called ActiveRecord (not to be confused with Microsoft’s LDAP implementation, ActiveDirectory) to interact with relational databases. Not only does it do all of the cool stuff from above, but it also generates methods for updating/selecting/saving/inserting, has built-in SQL sanetization, and lots of other cool features. You can read more about it in the Ruby on Rails API documentation.
Next up, we have the concept of controllers. Controllers are where a lot of where our application logic resides. Their job is to actually do it. They change the application’s state, find appropriate database records, and generally take care of business. They can then hand off what data they’ve gathered to the view, but more on that in a bit.
Controllers, like models, are also just more classes. One can invoke a controller by going to something like ‘example.org/myapp/controller_name’. Rails would look for a class called ControllerName in app/controllers/controller_name.rb.
Notice how the class name changed from what we specified in the URI to what it looked for. This is something Rails does a lot. The idea behind Ruby on Rails is that you can express ideas cleanly in something that looks human-readable. As such, Rails guesses at things that look nice, so you don’t have to specify them. ActiveRecord also does this by playing with the pluralization of the model to find the approprite database table. For example, if the model was called ‘Book’, the table it would look for is ‘books’.
Yes, I know. That sounds like a really, really bad idea. I agree with you, one hundred and ten percent. I have the feeling that I am going to be burned by Rails when I start developing in it because someone had the bright idea to teach their development framework the English language. This is my single biggest complaint with Rails (keeping in mind that I haven’t done much with it yet, having only read a book on it).
Finally, the view. Rails has two templating systems, rhtml and rxml. They’re pretty self-descriptive; rhtml is for HTML, and rxml is for XML. Rxml was covered very breifly, but it looks nifty for generating feeds. Rhtml was discussed much more completely. It offers all of the features of the Ruby programming language, making it incredibly flexible. Additionally, the book demonstrated how one could add a new templating system to Rails. It was not very hard.
Ruby also supports writing little modules that you can drop in and out, along with creating ‘helpers’. I’m not sure of their practical usefulness just yet.
There is a little Rails features that really makes Rails shine. When one generates form elements using the built-in form helpers, Rails can automagically highlight fields that have invalid input in them, with almost no work on the part of the developer. That’s really cool!
All in all, Ruby on Rails looks like it’ll be interesting. It seems easy. Agile Web Development with Rails was a great read. In fact, it was the first book of its class that I was able to read cover-to-cover in just a few days. I strongly advise it to anyone who is interested in developing under Rails.
