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.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
> (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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 Tambascio <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > (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 > > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Feb 27, 2:13 pm, "Scott" <tamosu...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---