Ruby on Rails Tutorial （Michael Hartl）中文翻译第二章 演示程序 （3）

（接上篇，第二章才过一半，加油~上篇讲了一个Rails 中 MVC的运用步骤）
我从浏览器（如IE）的地址栏出入URL或者点击一个链接开始发出一个请求，这个请求将会先会请求rails的“路由器router”，路由器将会基于URL选择目标控制器和ACTION（在BOX3.1中我将看到请求的方法。）。下表中的代码会为用户资源创建一个URL到控制器action的映射，这些代码会创建如前面表2.1所示的那样URL/action 对应关系。

Listing 2.2. Rails的映射Users 资源的路由.
config/routes.rb

DemoApp::Application.routes.draw do
  resources :users
  .
  .
  .
end

在第2.2.1中的页面对应了User控制器中的各个action。控制器是由Rails的scaffold生成器生产的，结构如listing 2.3所示。
提示， class UsersController < ApplicationController 的写法是Ruby中类继承的写法。（我们将会在第2.3.4中简短的介绍继承，在第4.4中详细介绍。）

Listing 2.3. Users控制器示意图。
app/controllers/users_controller.rb

class UsersController < ApplicationController

  def index
    .
    .
    .
  end

  def show
    .
    .
    .
  end

  def new
    .
    .
    .
  end

  def create
    .
    .
    .
  end

  def edit
    .
    .
    .
  end

  def update
    .
    .
    .
  end

  def destroy
    .
    .
    .
  end
end

你可能注意到了，在这个控制器中已经有几个action存在。Index，show，new，和edit等几个action对应第2.2.1中提到的页面，但是同时还有附加的create，update和destroy三个方法，通常这三个方法是不会去产生页面（并不绝对），相反，他们的主要作用是去修改数据库中User的信息。如表2.2所示，这基本是一个控制器的所有action，表中还显示了，Rails的REST运用。从表中看，有的URL是重复的，例如，控制器的show和update方法对应URL：“/users/1”，不同之处只是两者之间响应的HTTP请求方式不同。我们将在第3.2.2中详细学习HTTP请求方式。

HTTP 请求方式	URL	Action	目的
GET	/users	index	请求一个用于列出所有用户的页面
GET	/users/1	show	请求显示id为1的用户的页面
GET	/users/new	new	请求创建用户的页面
POST	/users	create	根据前面表单中的信息，向数据库创建用户
GET	/users/1	edit	请求编辑id为1的用户的页面
PUT	/users/1	update	将更新的信息更新到数据库
DELETE	/users/1	destroy	删除数据库中id为1的用户

表2.2 Listing 2.2 中提供的用户资源的RESTful架构的路由

引用

BOX 2.2 REpresentational State Transfer (REST)表述性状态转移
如果你阅读了很多关于Ruby on Rails的阅读材料，你就会发现有很多地方提到“REST”（表述性状态转移的简写）REST是一种开发分布式应用例如网络应用程序例如web程序的一种架构。
REST原始的很抽象的，具体到Rails下的REST应用就是指大部分程序的组件（例如上文的users,microposts）都是可以视为资源，都是可以被创建，读取，更新和删除，这几个动作就是关系数据库常说的CRUD操作和四个基本的HTTP请求方式：POST，GET，PUT和删除。（我们将在第3.2.2，特别是Box3.1更详细的学习）；

作为一个Rails运用程序的开发人员来说，RESTful的开发方式有助于知道写哪个控制器和哪个action，你可以使用资源的CRUD构造程序的简单结构。在上面的users，microposts中，只要他们是你权限范围内的资源，你都可以直接的CRUD。在12章中，我们将看到一个例子，REST原则允许我们自然方便地塑造一个微妙的问题，“following users”。

检查user控制器和user模型之间的关系，让我们来看看精简版本的index 方法（action翻译成方法。）吧。如下代码2.4（listing 翻译成代码。前面的就不去改了）：
代码2.4 演示程序中user简化版的index方法

class UsersController < ApplicationController
  def index
    @users = User.all
  end
  .
  .
  .
end

在index方法中有 @users = User.all，这是告诉User模型去数据库检索出所有的用户，并把值赋给@users变量（发音“at-users”），User模型的代码如下2.5所示。尽管他非常的简单，但是它却有着非常牛B的功能，因为它继承了那个东西（可见2.3.4节和4.4）。特别是，因为使用Rails的Actuve Record库，下面的代码已经可以接受User.all来返回所有的用户了。

代码2.5. 演示程序的user模型
app/models/user.rb

class User < ActiveRecord::Base
end

一旦@users被定义（赋值）之后，控制器就可以条用视图（View），如代码2.6。以“@”符号开始的变量成为类变量，可以自动的在视图中调用，在这里，index.html.erb（代码2.6）中的游标将会遍历@users数组变量然后为每一项输出一串HTML代码。
代码2.6. 用户index的视图(现在你不明白没关系。)
app/views/users/index.html.erb

<h1>Listing users</h1>

<table>
  <tr>
    <th>Name</th>
    <th>Email</th>
    <th></th>
    <th></th>
    <th></th>
  </tr>

<% @users.each do |user| %>
  <tr>
    <td><%= user.name %></td>
    <td><%= user.email %></td>
    <td><%= link_to 'Show', user %></td>
    <td><%= link_to 'Edit', edit_user_path(user) %></td>
    <td><%= link_to 'Destroy', user, :confirm => 'Are you sure?',
:method => :delete %></td>
  </tr>
<% end %>
</table>

<br />

<%= link_to 'New User', new_user_path %>

这个视图将会被转换成HTML然后传回给浏览器，显示给用户。

2.2.3 当前用户资源的缺陷
初步了解了Rails生成用户资源的优势之后，我们也该知道，他目前存在着不少的缺陷；

• 没有数据验证：模型接受一些非法的数据，例如空名字，不合法的email地址等。没有反馈
• 没有认证：没有登录/退出的概念，这样我们就没办法阻止随便一个用户操作某些操作。
• 没有测试：其实这不是非常准确，因为scaffolding会自己产生一些测试，但是生成的测试难看且死板，他们不会测试上面说的那2点或者其他用户自定义的一些需求。
• 没有布局：没有一致的网站风格和导航。
• 还没有正理解：其实你要是真的理解了scaffold的代码，你或许就不会来看这本书。

================（分割线，下一节我们将通过学习microposts资源来学习其他的知识，谢谢支持，我坚持每天都翻译一点，希望对人能有帮助）================================