From 6704e90c900555196080165c242d6999d1fcfaba Mon Sep 17 00:00:00 2001 From: James Miller Date: Wed, 10 Sep 2008 11:26:40 -0700 Subject: Briefly discuss the reason for the respond_to block generated by the scaffold --- .../guides/getting_started_with_rails/getting_started_with_rails.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'railties/doc') diff --git a/railties/doc/guides/getting_started_with_rails/getting_started_with_rails.txt b/railties/doc/guides/getting_started_with_rails/getting_started_with_rails.txt index 135b599c05..7a0d23777e 100644 --- a/railties/doc/guides/getting_started_with_rails/getting_started_with_rails.txt +++ b/railties/doc/guides/getting_started_with_rails/getting_started_with_rails.txt @@ -292,6 +292,9 @@ def index end ----------------------------------------- +In this action, we're setting the `@posts` instance variable to a hash of all posts in the database. `Post.find(:all)` or `Post.all` (in Rails 2.1) calls on our model to return all the Posts in the database with no additional conditions. + +The `respond_to` block handles both HTML and XML calls to this action. If we call http://localhost:3000/posts.xml, we'll see all our posts in XML format. The HTML format looks for our corresponding view in `app/views/posts/index.html.erb`. === The View The view is where you put all the code that gets seen by the user: divs, tables, text, checkboxes, etc. Think of the view as the home of your HTML. If done correctly, there should be no business logic in the view. -- cgit v1.2.3