13

「ajaxized」の方法でページ付けされたテーブルから要素を削除したいときに問題が発生します。私のタスクコントローラーは、に応答してそのdestroyメソッドを呼び出しますが、最後にインデックス[DELETE] /tasks/1234にリダイレクトして、リストを自動的に更新します。

残念ながら、redirect_to tasks_urlこの時点で行うのは[DELETE] /tasksリクエストです。

destroyの内部からリダイレクトしているときにDELETEではなくGETリクエストを強制する方法はありますか？

4

6 に答える 6

23

ステータス303でredirect_toを使用します

def destroy
  @task = Task.find(params[:id])
  @task.destroy
  redirect_to :action => :index, status: 303     
end

redirect_toのドキュメントによると：

http://api.rubyonrails.org/classes/ActionController/Redirecting.html

GETまたはPOST以外のXHRリクエストを使用していて、リクエスト後にリダイレクトする場合、一部のブラウザは元のリクエスト方法を使用してリダイレクトに従います。これにより、二重DELETEなどの望ましくない動作が発生する可能性があります。これを回避するには、GETリクエストを使用して追跡される303SeeOtherステータスコードを返すことができます。

于 2013-09-22T23:14:31.833 に答える
3

リダイレクトは使用しないでください。レンダリングを使用します。テーブルデータをライブラリモジュールに取得し、それをインデックスメソッドとdeleteメソッドの両方から呼び出してから、render呼び出しをdeleteメソッドに追加して追加し、インデックスビューが応答として返されるようにする機能を抽象化します。 。

require 'myLibrary'
include myModule

def index
    getTableData
end

def destroy
    flash.now[:notice] = "Delete operation failed" unless Task.destroy(params[:id])
    getTableData
    render 'myController/index'
end

lib/myLibraryにあります

module myModule
    def getTableData
        # Table Foo here
    end
end
于 2012-05-13T03:33:22.263 に答える
0

クライアント側でコードを再配置する必要があると思います。

  1. 現在のページを記憶する
  2. 発砲destroyアクション、真または偽を待つ
  3. indexajax呼び出しを使用して記憶されたページでリクエストします。
于 2012-05-14T11:37:47.563 に答える
0

：action paramを使用しないのはなぜですか？

def destroy
  @task = Task.find(params[:id])
  @task.destroy
  redirect_to :action => :index    
end
于 2012-05-17T20:45:04.433 に答える
0

ajaxを使用する場合、おそらく標準のRailsリダイレクトを実行したくないでしょう。このブログ投稿には、問題と解決策に関するいくつかの優れた洞察があります。これは1月の同様の質問からのものであり、 DGMが回答したことに注意してください。

于 2012-05-18T19:43:05.487 に答える
0

さて、この質問を要約します。この問題を修正するために私が見つけた最も簡単な方法は、以下を追加してroutes.rbを少し混乱させることです。"tasks" => "tasks#index", :via => :getそして、redirect_to tasks_url（私の場合は）コントローラーの破棄アクションで直接使用します。

これにより、kaminariページャーの問題も解決されます（場合によっては奇妙なリンクが表示されます）。

于 2012-05-21T10:58:30.030 に答える