Rails - Dec 2008 - ApplicationController: understanding generate scaffold

I''m new to Rails and I''m trying to understand the code created
by
generate scaffold.  I''m using Rails 2.2.2.

$ ./script/generate scaffold Task description:string

generated the following code in app/controller/tasks_controller.rb

class TasksController < ApplicationController
  # GET /tasks
  # GET /tasks.xml
  def index
    @tasks = Task.find(:all)

    respond_to do |format|
      format.html # index.html.erb
      format.xml  { render :xml => @tasks }
    end
  end

  # GET /tasks/1
  # GET /tasks/1.xml
  def show
    @task = Task.find(params[:id])

    respond_to do |format|
      format.html # show.html.erb
      format.xml  { render :xml => @task }
    end
  end

  # GET /tasks/new
  # GET /tasks/new.xml
  def new
    @task = Task.new

    respond_to do |format|
      format.html # new.html.erb
      format.xml  { render :xml => @task }
    end
  end

  # GET /tasks/1/edit
  def edit
    @task = Task.find(params[:id])
  end

I noticed that the edit method is missing some code.  If I remove those
same lines from each of the methods above.  The code still works, why?

I couldn''t find ApplicationController in the API docs at
http://api.rubyonrails.org/ ... I figured the behavior must be defined
in the super class, but I can''t seem to find the code for it either.

Can someone point me in the right direction to illuminate this mystery?

Thanks in advance,
Sarah

http://www.ultrasaurus.com/code (where I''m keeping a journal of my
learning Rails so far)
http://www.ultrasaurus.com (primary blog)
-- 
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 respond_to block is optional, and if the block is missing rails
will execute a render :task so for the edit task it will look for the /
controller/edit.html.erb file

Here is information from the api...
http://apidock.com/rails/ActionController/MimeResponds/InstanceMethods/respond_to



On Dec 29, 9:13 am, Sarah Allen
<rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
> I''m new to Rails and I''m trying to understand the code
created by
> generate scaffold.  I''m using Rails 2.2.2.
>
> $ ./script/generate scaffold Task description:string
>
> generated the following code in app/controller/tasks_controller.rb
>
> class TasksController < ApplicationController
>   # GET /tasks
>   # GET /tasks.xml
>   def index
>     @tasks = Task.find(:all)
>
>     respond_to do |format|
>       format.html # index.html.erb
>       format.xml  { render :xml => @tasks }
>     end
>   end
>
>   # GET /tasks/1
>   # GET /tasks/1.xml
>   def show
>     @task = Task.find(params[:id])
>
>     respond_to do |format|
>       format.html # show.html.erb
>       format.xml  { render :xml => @task }
>     end
>   end
>
>   # GET /tasks/new
>   # GET /tasks/new.xml
>   def new
>     @task = Task.new
>
>     respond_to do |format|
>       format.html # new.html.erb
>       format.xml  { render :xml => @task }
>     end
>   end
>
>   # GET /tasks/1/edit
>   def edit
>     @task = Task.find(params[:id])
>   end
>
> I noticed that the edit method is missing some code.  If I remove those
> same lines from each of the methods above.  The code still works, why?
>
> I couldn''t find ApplicationController in the API docs
athttp://api.rubyonrails.org/... I figured the behavior must be defined
> in the super class, but I can''t seem to find the code for it
either.
>
> Can someone point me in the right direction to illuminate this mystery?
>
> Thanks in advance,
> Sarah
>
> http://www.ultrasaurus.com/code(where I''m keeping a journal of my
> learning Rails so far)http://www.ultrasaurus.com(primary blog)
> --
> 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@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mon, Dec 29, 2008 at 12:13 PM, Sarah Allen <
rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
>
> I''m new to Rails and I''m trying to understand the code
created by
> generate scaffold.  I''m using Rails 2.2.2.
>
> $ ./script/generate scaffold Task description:string
>
> generated the following code in app/controller/tasks_controller.rb
>
> class TasksController < ApplicationController
>  # GET /tasks
>  # GET /tasks.xml
>  def index
>    @tasks = Task.find(:all)
>
>    respond_to do |format|
>      format.html # index.html.erb
>      format.xml  { render :xml => @tasks }
>    end
>  end
>
>  # GET /tasks/1
>  # GET /tasks/1.xml
>  def show
>    @task = Task.find(params[:id])
>
>    respond_to do |format|
>      format.html # show.html.erb
>      format.xml  { render :xml => @task }
>    end
>  end
>
>  # GET /tasks/new
>  # GET /tasks/new.xml
>  def new
>    @task = Task.new
>
>    respond_to do |format|
>      format.html # new.html.erb
>      format.xml  { render :xml => @task }
>    end
>  end
>
>  # GET /tasks/1/edit
>  def edit
>    @task = Task.find(params[:id])
>  end
>
> I noticed that the edit method is missing some code.  If I remove those
> same lines from each of the methods above.  The code still works, why?
>
> I couldn''t find ApplicationController in the API docs at
> http://api.rubyonrails.org/ ... I figured the behavior must be defined
> in the super class, but I can''t seem to find the code for it
either.
>
> Can someone point me in the right direction to illuminate this mystery?
>
> Thanks in advance,
> Sarah
>
Try creating a task, and then editing it.  You should find that, when you
remove the lines from "Edit", you don''t get information that
you previously
entered when you created the task.

If you look in app/controllers/application.rb, you will find that
ApplicationController is a task that you derived from
ActionController::Base.  You should be able to find documentation about
ActionController::Base at http://api.rubyonrails.org/

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) "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.

If you leave the #edit action in there, but don''t do anything in it,
the
default behavior is still to render a template with the same name as the
action.

If you leave the code in there as written, the #edit action will fetch the
row from the Task database with the specified ID.  The #edit view will then
have some data to show when it displays the form.

--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
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
-~----------~----~----~----~------~----~------~--~---

Patrick Doyle wrote:
> If you look in app/controllers/application.rb, you will find that
> ApplicationController is a task that you derived from
> ActionController::Base.  You should be able to find documentation about
> ActionController::Base at http://api.rubyonrails.org/
ah.  This solves the first mystery.  Still learning all the stuff that 
gets generated with scaffold.
> 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.
>"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.

Called id for nil, which would mistakenly be 4 -- if you really wanted 
the id of nil, use object_id

Extracted source (around line #3):

1: <h1>Editing task</h1>
2:
3: <% form_for(@task) do |f| %>
4:   <%= f.error_messages %>
5:
6:   <p>

> If you leave the #edit action in there, but don''t do anything in
it, the
> default behavior is still to render a template with the same name as the
> action.
yup.  same behavior.
> If you leave the code in there as written, the #edit action will fetch 
> the
> row from the Task database with the specified ID.  The #edit view will 
> then
> have some data to show when it displays the form.
Makes sense.

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?

Thanks so much,
Sarah
-- 
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
-~----------~----~----~----~------~----~------~--~---

On Mon, Dec 29, 2008 at 2:22 PM, Sarah Allen <
rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> 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
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
-~----------~----~----~----~------~----~------~--~---