redirect_to von "destroy" zu "index"

Problem erscheint, wenn ich Element aus paginierter Tabelle in "ajaxized" Weise entfernen möchte. Meine Aufgaben Controller ruft zerstören Methode als Reaktion auf [DELETE] /tasks/1234, aber am Ende möchte ich an Index umleiten, um die Liste automatisch aktualisiert zu bekommen.redirect_to von "destroy" zu "index"

Leider was redirect_to tasks_url an dieser Stelle ist [DELETE] /tasks Anfrage.

Gibt es eine Möglichkeit zum Erzwingen GET-Anfrage anstelle von DELETE während der Umleitung von innerhalb zerstören?

Quelle

2012-04-12 Michal

Können Sie die Informationen aus Ihrer Protokolldatei für diese Umleitungsanforderung bereitstellen? – arnep

Sicher, hier ist es: [gist] (https: //gist.github.com/2369726) – Michal

Hinweis: Ich habe genau die gleichen Symptome wie oben beschrieben und aufgelistet. Ein zusätzlicher Datenpunkt: Mein Chrome-Browser gibt an, dass auf der Weiterleitung ein "GET" und kein "DELETE" ausgegeben wird. Die Rails-Protokolle zeigen jedoch an, dass der Umleitungsruf mit "DELETE" wie oben beschrieben ist. – SingleShot

Ok, so um diese Frage zusammenzufassen. Der einfachste Weg, den ich gefunden habe, um das Problem zu beheben, ist ein bisschen in routes.rb durch Hinzufügen von: "tasks" => "tasks#index", :via => :get und redirect_to tasks_url (in meinem Fall) direkt in Aktion in Controller zu zerstören.

Dies wird das Problem mit dem Kaminari Pager auch lösen (die in einigen Fällen seltsame Links macht).

Quelle

2012-05-21 10:58:30 Michal

Aw ... Ich kann dir das Kopfgeld nicht geben. Sieht so aus als ob niemand es bekommen hätte :( – SingleShot

Keine Sorge, ich bin froh, dass ich dir helfen konnte :) – Michal

Verwenden Sie keine Weiterleitung. Verwenden Sie Rendern. Zeichnen Sie die Funktionalität zum Abrufen der Tabellendaten in ein Bibliotheksmodul zusammen und rufen Sie diese dann sowohl aus dem Index als auch aus den Löschmethoden auf und fügen Sie dann den Renderaufruf der Löschmethode hinzu, sodass die Indexansicht als Antwort zurückgesendet wird .

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

in lib/mylibrary

module myModule 
    def getTableData 
     # Table Foo here 
    end 
end

Quelle

2012-05-13 03:33:22 Reuben

Danke - dies aktualisiert die Liste der Elemente richtig. Allerdings sagen meine 'will_paginate' Links nach dieser Aktion'/tasks/2? Page = 2' (was falsch ist) zum Beispiel statt '/ tasks? Page = 2'. Dies geschieht nur nach dem oben beschriebenen Ajaxed Destroy. Gedanken? – SingleShot

Hinweis: Ich habe von 'will_paginate' zu' kanimari' gewechselt, um zu sehen, ob das Problem mit der fehlerhaften URL verschwindet. Negativ. – SingleShot

Entschuldigung, aber es gibt keine Möglichkeit, diesen Teil zu beantworten, ohne zu wissen, wie Ihre App zusammengestellt wird. Wenn Sie dies über XHR versuchen, müssen Sie ändern, wie die Tabellendaten geladen werden. Dies funktioniert nicht, wenn der Index eine komplette Webseite lädt, aber die Zerstörung ist nur ein Teil einer Seite, die über einen Ajax-Aufruf ausgelagert wird. – Reuben

Ich glaube, Sie Ihren Code auf der Clientseite neu ordnen sollten:

Memorize aktuelle Seite
Feuer destroy Aktion, erwarte wahr oder falsch
Anfrage index auf gespeicherte Seite mit Ajax cal l.

Quelle

2012-05-14 11:37:47 flooooo

Interessant - im Grunde "tun die Umleitung selbst". Ich habe den Code nicht so umgestellt, wie Sie vorgeschlagen haben, und stattdessen Michals Vorschlag einer speziellen Route verwendet. Vielen Dank! – SingleShot

Warum nicht zu verwenden: action param?

Quelle

2012-05-17 20:45:04 melekes

Das ist nicht viel anders als das, was wir schon gemacht haben. Die Weiterleitung wird vom Browser empfangen, der Browser gibt ein 'GET' auf' index' aus, aber die Rails verwenden 'DELETE' anstelle von' GET'. Ich glaube, es ist ein Bug in Rails selbst. – SingleShot

Entschuldigung, ich denke du hast Recht. Leider verfügt Rails nicht über die forward() -Methode von Symfony ('Diese Methoden leiten die aktuelle Anfrage ohne einen Round-Trip mit dem Browser an eine andere Aktion weiter.'), so dass es sich lohnt, das Routing zu ändern oder die render-Methode zu verwenden. – melekes

Sie möchten wahrscheinlich nicht eine Standard-Schienenumleitung verwenden, wenn Sie Ajax verwenden. Diese blog post hat einige gute Einblicke in das Problem und die Lösungen. Beachten Sie, dass dies von einer similar question im Januar ist, beantwortet von DGM

Quelle

2012-05-18 19:43:05 Swards

Interessant. Im Gegensatz zu dem, was die ähnliche Frage beschreibt, findet in meinem Fall tatsächlich eine richtige Umleitung statt - automatisch vom Browser. Der Unterschied ist, dass Schienen nicht richtig damit umgehen können. Ich habe das Problem über eine spezielle Route gelöst, wie es in einem von Michals Kommentaren vorgeschlagen wurde. – SingleShot

Verwenden redirect_to mit dem Status 303

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

redirect_to Dokumentation sagt:

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

Wenn Sie XHR-Anfragen anders als verwenden GET oder POST und Umleiten nach der Anforderung dann werden einige Browser folgen die Umleitung mit der ursprünglichen Anfrage-Methode. Dies kann zu unerwünschtem Verhalten führen, z. B. zu einem doppelten DELETE. Um dies zu umgehen, können Sie einen 303 Siehe Anderer Statuscode zurückgeben, dem eine GET-Anfrage folgen wird.

Quelle

2013-09-22 23:14:31

Dies ist die einzig richtige Antwort. Kann es nicht mehr verbessern. !! – Nerve

Thanq so viel gespeichert lottt der Zeit ... – Agnes

Ich sehe erfolgreiche "umgeleitet zu" Nachricht im Terminal, aber aus irgendeinem Grund gilt es nicht für meinen Browser ... – divideByZero

redirect_to von "destroy" zu "index"

Antwort

Verwandte Themen