# Onlamp tutorial - questions/comments **URL:** \ **Category:** Rails\ **Created:** [February 27, 2007, 11:54am UTC](https://www.ruby-forum.com/t/onlamp-tutorial-questions-comments/86986 "2007-02-27T11:54:30Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![stickstone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/6f9a4e/32.png) [@stickstone](https://www.ruby-forum.com/u/stickstone)\ **Post date:** [February 27, 2007, 11:54am UTC](https://www.ruby-forum.com/t/onlamp-tutorial-questions-comments/86986/1 "2007-02-27T11:54:30Z")
Hello, I’m a newbie to Rails but a relative old-timer on Ruby. I’ve been going through the Onlamp Rails tutorial at > **[Radar - O’Reilly](https://www.oreilly.com/radar/)** > > Now, next, and beyond: Tracking need-to-know trends at the intersection of business and technology 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. ---
**Author:** ![stickstone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/6f9a4e/32.png) [@stickstone](https://www.ruby-forum.com/u/stickstone)\ **Post date:** [February 27, 2007, 2:08pm UTC](https://www.ruby-forum.com/t/onlamp-tutorial-questions-comments/86986/2 "2007-02-27T14:08:54Z")
> (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 ---
**Author:** ![stickstone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/6f9a4e/32.png) [@stickstone](https://www.ruby-forum.com/u/stickstone)\ **Post date:** [February 27, 2007, 3:13pm UTC](https://www.ruby-forum.com/t/onlamp-tutorial-questions-comments/86986/3 "2007-02-27T15:13:56Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![stickstone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/6f9a4e/32.png) [@stickstone](https://www.ruby-forum.com/u/stickstone)\ **Post date:** [February 27, 2007, 3:46pm UTC](https://www.ruby-forum.com/t/onlamp-tutorial-questions-comments/86986/4 "2007-02-27T15:46:01Z")
On Feb 27, 2:13 pm, “Scott” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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… ---
**Author:** ![stickstone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/6f9a4e/32.png) [@stickstone](https://www.ruby-forum.com/u/stickstone)\ **Post date:** [February 27, 2007, 7:10pm UTC](https://www.ruby-forum.com/t/onlamp-tutorial-questions-comments/86986/5 "2007-02-27T19:10:56Z")
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