读《应用rails进行敏捷web开发》第2版-6

  3年前写的一个读取二代身份证信息自动填入其他应用程序输入框的外挂 的源代码找不到了，郁闷。最近公司又准备用，只好先把执行文件扔过去，将就着用。有时间再重写吧。

 

 

p151

 

#判断请求是否是post if request.post? #判断请求是否get if request.get?

如果在控制器里包括上面的机制，那么原来的new+Create，其实可以合并成一个action，原来的new用来显示界面、录入数据，然后把数据提交到create这个action，然后create进行校验、处理，存入数据库。。。

 

分开的action肯定逻辑更清晰，不知为何非要分成两个？不过合并后的代码，看起来很专业。呵呵。

def new_item #从读取表单item的信息，创建一个新的item @item=Item.new(params[:item]) #如果是表单 同时存盘成功，那么显示一个新的item录入界面 if request.post? and @item.save flash[:notice] = "item 创建好了" @item= Item.new end end

这几行代码满足了action的几个功能

1.get访问时，显示一个空的录入表单

2.填好表单后，提交时，进行存盘，然后显示成功，继续显示空表单用于继续添加

3.如果存盘失败，那么@item还是原来的数据，表单可以继续显示之

 

同时也需要rhtml的配合：不加参数的form_for，会执行渲染视图的控制器的action，也就是上面代码中的action

<%form_for :user do |form| %> <%form.text_field :name %> <%end%>

其中的:user,就是后文中提到的“使用模型对象做中介”

 

 

再看另一种写法，

<%form_tag do %> <%text_field_tag :name,params[:name] %> <%end%>

params[:name]是默认值，同样可以起到出错时，给用户更正的机会。

 

其实第2种写法，相当于自己去对应表单和字段，比较适合表单数量比较少的情况，通常用第一种写法，代码更简单些。

 

request.request_uri 可以知道用户要访问的url

 

before_filter :logon ,:except =>:login

before_filter :find_cart,:except=>empty_cart

 

哈哈，貌似下一章就要开始rest了，终于快递归完了——我就是看不懂rest的嵌套路由，才开始翻这本书的。