Onlamp tutorial - questions/comments

rubyonrails-talk
1

Hello,

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

I've been going through the Onlamp Rails tutorial at

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.

2

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

Scott

3

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...

4

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