Onlamp tutorial - questions/comments

Hello,

I'm a newbie to Rails but a relative old-timer on Ruby.

I've been going through the Onlamp Rails tutorial at
http://www.onlamp.com/pub/a/onlamp/2007/01/05/revisiting-ruby-on-rails-revisited-2.html
which is an excellent piece of work.

I have a few questions:

(1) On page 2 (and elsewhere), the following appears:

    link_to %Q{#{recipe.title}}, ...

I don't understand why the %Q{#{...}} construct has been used. Why not just

    link_to recipe.title

or

    link_to recipe.title.to_s ?

(2) On page 3, the layout contains

    <%= yield %>

but in my installation of Rails (Ubuntu rails package 1.1.2-1), the template
had

    <%= @content_for_layout %>

So I decided to stick with the latter format. However, I just want to know,
is one preferred over the other? Is one deprecated?

(3) On page 4, in the recipe controller, the following lines are added:

  @recipes = Recipe.find(:all,
                        :conditions => ["category_id = ?", params[:category_id]])
  params[:category_id] = nil

But why set the parameter to nil after you've finished using it?

I also have a few comments.

(4) The database defines a column called 'date'. However I'm using an Oracle
database as the back-end, and it rejects this as a column name.

It might have been possible to quote the column name everywhere that it's
used, but I thought that was a bit of a risky strategy, so I just changed
the column name to date_ent. This meant I had to make corresponding changes
to the example code snippets.

So not a major problem, but it could make the example more portable if a
different name were used.

(5) On page 4, the narrative says:

"The error message is telling us we just tried to delete a record that has
children. Rails stopped us from accidentally deleting a bunch of recipes."

To be accurate, *the database* has stopped us from accidentally deleting a
bunch of recipes. The exception shows that Rails went ahead and tried to
delete the category, but the DB didn't allow it.

(If you had configured the database with "ON DELETE CASCADE" then all of
those recipes would have been deleted as well...)

Anyway, those are just a couple of minor observations. This is a really
excellent tutorial and I'm sure will whet the appetite of many a newcomer,
as it has done for me.

Regards,

Brian.

The %Q is used to quote the contents... it usefulness becomes more
apparent when you have lots of embedded single and double quotes.

Scott

Well, I know what %Q{..} is, but I still don't see why it is needed
here.

We are calling a method, "link_to", with several arguments: link_to
arg1, arg2, arg3

If I write %Q{#{arg1}}, or equivalently "#{arg1}", then I am:
1. evaluating arg1
2. if it's not a string, calling its to_s method
3. inserting that string inside another string

It would make sense if I wanted to add some more text before or after
the argument: e.g. %Q{http://#{arg1}?foo=bar}. However I don't see why
it's needed here; it just looks like line noise. Maybe I am missing
something deep and fundamental and Rails will break without it, but if
so, I want to know what it is...

Hi Brian,

Brian Candler wrote:

(1) On page 2 (and elsewhere), the following appears:
   link_to %Q{#{recipe.title}}, ...

I don't understand why the %Q{#{...}} construct has
been used.

It's been 6 months since I started the tutorial, but IIRC, I'd intended to use that do a little explaining. %Q to explain that the quotes that are shown in the documentation examples aren't needed when you're passing in something that Rails knows is a string. #{} to explain that you don't need to evaluate variables if they're used within eRb. The explanations fell by the way-side. The artifact remained. My bad.

(2) On page 3, the layout contains
   <%= yield %>
but in my installation of Rails (Ubuntu rails
package 1.1.2-1), the template had
   <%= @content_for_layout %>

As someone else has responded, <%= @content_for_layout => was the original way to tell Rails 'here's where to render the stuff that varies by request.' It's been depracated in favor of <%= yield %>.

(3) On page 4, in the recipe controller, the following lines are added:
@recipes = Recipe.find(:all,
                       :conditions => ["category_id = ?", params[:category_id]])
params[:category_id] = nil
But why set the parameter to nil after you've finished using it?

That's just a personal style I've come to use over the years to help me flush hidden problems. If the method were somehow called from somewhere other than the page it's supposed to come from, the find wouldn't work and I'd get explicit notification of a problem.

(5) On page 4, the narrative says:
To be accurate, *the database* has stopped us
from accidentally deleting a bunch of recipes. The
exception shows that Rails went ahead and tried to
delete the category, but the DB didn't allow it.

(If you had configured the database with "ON DELETE
CASCADE" then all of those recipes would have been
deleted as well...)

You're absolutely right. The wording was a conscious choice on my part between 'absolute accuracy' and 'ok to think about it this way at this stage'. My belief was that the target audience might try to understand what was going on if I kept it simple. Once folks get incented to learn, they can be taught. Take them down a path that might seem to imply they need to have a profound understanding of all the many pieces in order to start using Rails and ...

Anyway, those are just a couple of minor observations.

And they're much appreciated.

This is a really excellent tutorial and I'm sure will whet
the appetite of many a newcomer, as it has done for me.

Thank you. If it your whet your appetite to learn Rails, then it accomplished all it was intended to accomplish. Curt's original did exactly the same for me.

Best regards,
Bill