I’ve now made it through Chapter 2 and thought I’d comment on it here.
If Chapter 1 was “Ruby for Dummies,” then chapter 2 starts out as “Rails
Dummies,” but doesn’t stay that way. The beginning is a discussion of
classic MVC architecture and how the Rails framework libraries map to
various parts. Since my development box is a Win XP machine, my
structure is a bit different from the one shown, but similar enough that
mappings were clear.
Where life starts to get really interesting is the development of the
app (R4RMusic, short for Ruby for Rails Music Store) that is used in the
rest of the book. As many Rails developers apparently do, the author
started with the database and worked from there. The database consists
three tables and the associations that come with them.
One difference between this book and the others I’ve read is that the
provided to create the database in this case does not try to enforce
key relationships. That’s of course done in the Ruby code, using
and has_many relationships (interestingly, the sample does not use an
relationship at this point), but the SQL creating the tables only lists
items like “composer_id” which will handle the relationship, but doesn’t
include any foreign key constraints in it. The AWDWR book (Thomas and
has an extended discussion of this issue and makes it very clear that
true nature of relationships can’t be inferred from the database, but
in their book they add in foreign key constraints in their SQL.
Rather than try to download the code (a download is mentioned more than
once, but I don’t know if it’s yet available – besides, I wanted the
practice) I typed everything in by hand. I used RadRails 0.5.3 inside
Eclipse 3.1.1, incidentally, but that’s the only deviation I made from
Another major deviation from other Rails books is that the author does
immediately use the scaffold generator. Instead, the “generate model”
“generate controller” scripts were used repeatedly. Since generating
controller winds up generating the view as well, the basic files were
present for editing. The only difference I noticed is that the basic
functionality wasn’t there any more.
Minor typo: In Listing 2.2, the second INSERT INTO line has two
key words in it, one at the end of the first line and one at the
of the second line.
The chapter then shifts to the controllers and illustrates how easily
can use a finder class method to access all the records in each table.
found it notable that in the “Composer.find(:all)” method, the author
to do sorting by appending a Ruby block instead of using the “:order”
in the find. Presumably something like “Composer.find(:all, :order ==>
“last_name, first_name”)” would have worked just as well as the block,
haven’t tried it yet.
The controllers each include a “show” action which sets the relevant
(@work, @edition, or @composer) using the “:id” param. Then we switch
The description of the view included a base layout, which was saved as
rhtml file, then the line “layout ‘base’” was added to the
controller. The author mentioned that the layout could have been saved
“application.rhtml” directly and avoided this, but I agree it was useful
see the separation.
Listing 2.3 has a typo, by the way. Presumably the lines
were meant to be included at the bottom of the listing, especially since
DOCTYPE was for XHTML 1.0 Strict.
The views themselves were all clear and easy to understand. They simply
used some erb to loop through the entities and display them, with
Another unusual part of the demo is that rather than generate an index
method and thereby use the index view, the author created a separate
page and then had to edit routes.rb to make the application go there by
default. That’s not a problem, of course, and it was actually
to see how that was done. I just found it unusual relative to the other
The last few pages of the chapter are the fun part. That’s where the
walks the reader through the actual call sequence, even separating out
web server calls (he uses Apache as an example) from the internal Rails
calls. I found that quite good, though I was expecting him to use the
R4RMusic application as an example rather than talking about a
In conclusion, I really liked this chapter. It’s true that parts of it
overly basic or simplistic, but the demo worked and the walkthrough at
end was interesting.
I’m looking forward to digging into Chapter 3, now that I know it’s
Kenneth A. Kousen, Ph.D.
Kousen IT, Inc.