レンダリングの背後にある根拠：redirect_toの代わりに新しく、POST作成のために新しい？

Question

はレールRESTfulなコントローラパラメータをキャプチャし、検証が失敗した場合render :new代わりのredirect_to new_widget_pathに慣例である理由検証メッセージをレンダリングするよりも、他の

class WidgetsController 
    def new 
    @widget = Widget.new 
    end 

    def create 
    @widget = Widget.new(params[:widget]) 
    render :new and return unless w.save 

    redirect_to widget_path(@widget) 
    end 
end 

を考えると？

URLは/widgets/newから/widgetsに変更されるため、検証に失敗した場合、これはRESTの概念を破るものではありませんか？

Answer 1

レンダリングされるものは、別のリクエストが生成されないことです。対応するビューに移動して表示します。ただし、リダイレクトを使用すると、ブラウザへのリダイレクト要求が生成されます。これにより、サーバーに対して別の要求が発生します。

Answer 2

レンダリングはコントローラアクションを呼び出さないため、作成アクションで設定したインスタンス変数は新しいビューに移動されます。これは、検証エラーが新しいビューに固執することを意味

...

新しいのためのコントローラのアクションを実行するため、モデルの新しいインスタンスを作成しredirect_to ...そしてあなたがエラーを失うだろう。 ..

希望するこれは役に立ちます

Answer 3

新しいアクションをレンダリングする代わりにこれを実行できますか？新しい/編集アクションをレンダリングするために必要とされるあなたのコントローラでいかなるロジックを持っている場合はそうでない場合、あなたは繰り返す必要があるため

flash[:thing] = params[:thing] 
    redirect_to new_thing_path 

は次に、新しい

@thing = Thing.new(flash[:thing] || params[:thing]) 

でこれは正直私にはよりよいそうですそのロジック（あるいは、いくつかのbefore_filterか何かを作成する）をupdate/createに追加します。これにはもう1つのリクエストが含まれていますが、それを除けば、コードは単純で安全であるように見えます（レールの規則を破っている点を除いて）。そして、ユーザーに同じURLを見たり/もの。

リフレッシュすると、値が失われますが、これは送信前のどのフォームでも当てはまります。そして、それは私にはもっと奇妙な再送信の警告をもたらすよりも賢明であるように思われる。ユーザーはどのようにしてフォームをクリアするはずですか？

このrails-ismはいつも私を盗んだ。私が検討していないこれに関する深刻な問題はありますか？他のアプリケーションフレームワークもすべて同じですか？