2009-03-06 15 views
6

Pracuję z aplikacją zbudowaną w Ruby on Rails z bardzo kiepską obsługą błędów w tej chwili. Jeśli metoda kontrolera jest wykonywana przez ajax, a ta metoda daje wynik 500 (lub 404 lub jakakolwiek inna odpowiedź), strona 500.html jest renderowana i zwracana jako wynik żądania AJAX. Oczywiście javascript nie wie, co zrobić z tym HTML, a strona wygląda na to, że czeka na odpowiedź.Przekierowanie na stronę 500, gdy wywołanie AJAX kończy się niepowodzeniem w Ruby on Rails

Czy istnieje prosty sposób renderowania szablonu error.rjs w przypadku wystąpienia błędu podczas wywołania AJAX?

Odpowiedz

3

Możesz użyć respond_to wewnątrz metody rescue_action lub rescue_action_in_public kontrolera. Rozważmy następujący kontroler:

class DefaultController < ApplicationController 

    def index 
    raise "FAIL" 
    end 

    def rescue_action(exception) 
    respond_to do |format| 
     format.html { render :text => "Rescued HTML" } 
     format.js { render :action => "errors" } 
    end 
    end 
end 
3

Rozwiązałem podobny problem z autoryzacją. I stworzył prosty kontroler autoryzacji z tej akcji:

def unauthorizedxhr 
    render :update do |page| 
     page.replace_html("notice", :partial=>"unauthorizedxhr") 
     page.show("notice")  
    end 
    end 

oto szablon:

<% if flash[:notice] -%> 
    <div id="noticexhr"><%= flash[:notice] %></div> 
<% end -%> 

Kiedy autoryzacja nie powiodła się w sterowniku, chciałbym skierować do: kontroler => „zezwolenie”, : action => "unauthorizedxhr" po ustawieniu wartości flash [: notice]. Pozwoliło mi to dostosować wiadomość, którą wysłałem do użytkownika, i obsłużyło wyświetlanie wiadomości poprzez render: kod aktualizacji powyżej.

Możesz dostosować to do swojego problemu, tworząc kontroler błędów, wychwytując wszelkie błędy w innych kontrolerach, a następnie po prostu przekierowujesz do: controller => "errors",: action => "displayxhr", gdy połączenie nie powiedzie się. W ten sposób ustandaryzujesz swój mechanizm komunikacji błędów, ale pozwolisz sobie na dostosowanie komunikatów o błędach przy każdym działaniu.

Nadal można korzystać z pomysłu cpm powyżej, ale wyświetlacz błędu będzie obsługiwany przez oddzielną i odrębną logikę sterownika. to powinno trochę ułatwić utrzymanie.

Nadzieję, że pomaga. -Chris

1

To było moje ostatnie rozwiązanie:

def rescue_action_in_public(exception) 
    response_code = response_code_for_rescue(exception) 
    status = interpret_status(response_code) 
    respond_to do |format| 
    format.html { render_optional_error_file response_code} 
    format.js { render :update, :status => status do |page| page.redirect_to(:url => error_page_url(status)) end} 
    end 
end 

To w zasadzie do przodu do właściwej statycznej strony HTML bez względu na to, czy wniosek był za pośrednictwem AJAX lub normalny GET/POST.

To NIE jest używane do normalnej obsługi błędów, takiej jak sprawdzanie poprawności itd. Jest używane tylko wtedy, gdy dzieje się coś naprawdę złego - jak nieobsługiwany wyjątek.

0

Można zrobić jak poniżej:

w allpication.js

$(document).ready(function(){ 
    $(document).ajaxError(function(e, xhr, options){ 
    if("500" == xhr.status) 
    { 
     $(location).attr('href','/users/sign_in'); 
    } 
    }); 
}) 

jego pracy dla mnie .....

Powiązane problemy