On Mon, Dec 29, 2008 at 2:22 PM, Sarah Allen < [email protected]> wrote:
> Patrick Doyle wrote: > > From one newbie to another... > > Look at the links created in the index view for your tasks controller. > > With > > the default scaffold, you should see three links to the right of each > > task > > listed: Show, Edit, and Destroy. If you mouse-over the Edit link, you > > will > > probably see something that looks like: > > http://localhost:3000/tasks/1/edit. > > That says to the routing system in Rails (through the magic of the code > > you > > wrote in config/routes.rb) > > hmm. If I look at the routes that were auto-generated for me, I see: > map.connect ':controller/:action/:id' > > which would lead me to believe that the URL should be: > http://localhost:3000/tasks/edit/1 > > while semantically it makes more sense to apply the edit action last, I > don't see how that maps to the code. Is it considered bad practice to > leave these as is. The comment says "consider removing the them or > commenting them out if you're using named routes and resources." I'm > not quite sure what "named routes and resources" are and whether I'm > using them. > Look at the top of your routes file. You will see something that looks vaguely like: map.resources :tasks That creates routes that match /tasks/1/edit Oh cool... I just realized that using the RESTful routes created by map.resources, and using the default route at the end of routes file, you would get to exactly the same place via: http://localhost:3000/tasks/1/edit and http://localhost:3000/tasks/edit/1 If that sort of thing bothers you, you could "consider removing [the default rules] or commenting them out if you're using named routes and resources" Oh, I just saw the part in your email about the "named routes and resources". Since you are using the scaffold, you are using named routes and resources, since that is what is considered to be the best practice by those who brought you Rails. Google "RESTful routing" and you will find much more information than I could provide in an email. But, in a nutshell, the "map.resources" command at the top of the file creates a bunch of routes for you that map to the 7 actions you found in your controller. With those in place, you don't need the two default routes at the end of the file. > >"Invoke the 'edit' action in the 'tasks' > > controller, and, by the way, set the 'id' parameter to '1'". > > > > When your #edit action is invoked, it searches the Task table in your > > database for the entry with an ID of 1. Then Rails, by default, will > > render > > a view (a web page) named "edit". You can see the template for that web > > page in app/views/edit.html.erb. > > > > If you completely remove the #edit action, the default behavior is still > > to > > render a template with the same name as the action. > > Yes, it does this, but when the template is rendered, it causes the > error below, which I assume is because '@task' is not defined, although > I don't really understand the error message. > Oops, I thought about that after I sent my email. But by then I figured you would have noticed it yourself :-) The error message is produced because @task evaluates to nil. Something somewhere in the #form_for helper tried to call @task.id, which got evaluated as nil.id, which triggered an exception, which displayed an error message indicating that you probably didn't want to do that. I see empirically how it works; however, I'm still curious how does > Rails "know" whether I've called respond_to in my edit method? > > The respond_to stuff has to do with "Web Services" whatever those are. (Keep in mind, I'm a newbie here too.) From what I've intuited so far, web services seem to like to exchange data using XML. I don't really know why #edit doesn't include a call to respond_to where each of the other 6 actions do, except to note the use of #edit in the world of RESTful routing. In that world, when you want to create a new record in a table, you are first presented with a view of a blank record (via the #new action). When you click on the "Create" button, the #create action gets invoked. In the same vein, when you want to edit an existing record, you are first presented with a view of the existing record (via the #edit action). When you click on the "Update" button, the #update action gets invoked. My guess is that, in the web services world, one would never invoke an "update" action without first having some idea of what the data looked like and that one would probably have learned that via the #show action, so that rendering something in XML for #edit is not necessary. In the web brower world, the "show" view displays data on a page while the "edit" view would presumably display a form (with the exact same data) allowing the end user to change the data and submit an update. That's my guess anyway. --wpd --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
