On Mon, Dec 29, 2008 at 2:22 PM, Sarah A. <
[email protected]> wrote:
That says to the routing system in Rails (through the magic of the code
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
Look at the top of your routes file. You will see something that looks
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,
would get to exactly the same place via:
If that sort of thing bothers you, you could “consider removing [the
rules] or commenting them out if you’re using named routes and
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
and resources, since that is what is considered to be the best practice
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
the “map.resources” command at the top of the file creates a bunch of
for you that map to the 7 actions you found in your controller. With
in place, you don’t need the two default routes at the end of the file.
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
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
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,
services seem to like to exchange data using XML. I don’t really know
#edit doesn’t include a call to respond_to where each of the other 6
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
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
vein, when you want to edit an existing record, you are first presented
a view of the existing record (via the #edit action). When you click on
“Update” button, the #update action gets invoked. My guess is that, in
web services world, one would never invoke an “update” action without
having some idea of what the data looked like and that one would
have learned that via the #show action, so that rendering something in
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
submit an update.
That’s my guess anyway.