Onlamp tutorial - questions/comments

Rails
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

(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?

I believe the <%= @content_for_layout %> was the original method to
serve as the placeholder for your logic. I just created a new app with
Rails 1.2, and the <%= yield %> method is used.

-Kevin

3

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

Scott

On Feb 27, 8:08 am, Kevin T. [email protected]

4

On Feb 27, 2:13 pm, “Scott” [email protected] wrote:

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

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…

5

Hi Brian,

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