¿Hay forma de vincular un controlador de errores para solicitudes ajax que se realiza por backbone.js?Controlador de error global para solicitudes backbone.js ajax
Mi situación: Puedo obtener 401 (no autorizado) en cualquier momento, así que necesito mostrar la ventana emergente de inicio de sesión.
Utilice jQuery directamente para esto.
$(document).ajaxError(function (e, xhr, options) {
// do your stuff
});
Puede hacer lo mismo para CSRF en rieles, por ejemplo (utilizando ajaxSend).
se puede leer más aquí: http://api.jquery.com/jQuery.ajax#advanced-options
La sincronización de Backbone desencadena un evento de "error" cuando se producen errores. Entonces, un enfoque que podría tomar es extender los objetos Modelo y Colección de Backbone para agregar estas comprobaciones de error de complemento. Se vería algo como esto:
ErrorHandlingModel = Backbone.Model.extend({
initialize: function(attributes, options) {
options || (options = {});
this.bind("error", this.defaultErrorHandler);
this.init && this.init(attributes, options);
},
defaultErrorHandler: function(model, error) {
if (error.status == 401 || error.status == 403) {
// trigger event or route to login here.
}
}
});
OtherModel = ErrorHandlingModel.extend({
});
y harías algo similar para el objeto Collection. No he probado lo anterior, pero creo que es bastante cercano. Obviamente, elegirías mejores nombres de clase. El método init solo permite a las subclases tener la oportunidad de hacer su propia inicialización.
¿Debería un modelo realmente tener la tarea de manejar un 401 no autorizado? – Ben
Buena pregunta. Lo hicimos puramente porque los modelos y las colecciones eran nuestro conducto para el servidor. No parece una responsabilidad tradicionalmente asignada a una cosa similar a un modelo, así que tal vez haya una mejor manera. En mayo, no había mucho arte previo para reflexionar, así que este es el enfoque que se nos ocurrió. –
no funcionó para mí. –
Lo que encontré es posiblemente la "forma más correcta" en Backbone:
var GeneralErrorView = Backbone.View.extend({
events: {
'ajaxError': 'handleAjaxError'
},
handleAjaxError: function (event, request, settings, thrownError) {
//...handling goes here
}
});
this.view = GeneralErrorView({el: document});
se puede poner cualquier error de lógica de manejo sin extender modelos o colecciones. Haga uso de backbone.Events manejador interno y transmita mensajes a otros manejadores de errores o algo así.
¡Acercamiento inteligente! –
Esto funciona, sin embargo la solicitud, la configuración, los parámetros de throwwnError no están definidos cuando recibí un error 500 del servidor. Realmente no puedo usar esta solución si no recibo información sobre el error. ¿Hice algo mal? –
Esto podría estar desactualizado porque utilicé esto hace casi dos años, necesita verificar si se pasó algo a la devolución de llamada en absoluto –
Puede manejar esto mediante el método jQuery .ajaxSetup. Tenemos una situación idéntica (aplicación columna vertebral que puede obtener un error 401 en cualquier momento) y lo manejamos mediante el uso de ajaxSetup de jQuery en el punto de entrada de nuestra aplicación:
var appView = new AppView(options);
$.ajaxSetup({
cache: false,
statusCode: {
401: function() {
appView.signIn();
}
}
});
appView.render();
Backbone.history.start({ root: config.rootUrl, pushState: true });
Este enfoque da error global manipulación sin la necesidad para extender las clases base Backbone.
Tenga en cuenta que esta devolución de llamada se ejecutará para todos los errores de JQuery ajax, no solo aquellos relacionados con solicitudes de red troncal. Es posible que haya otras bibliotecas en la página que realizan solicitudes ajax a través de jquery, probablemente no desee la devolución de llamada en esos casos. – cerberos
hm, esa es una forma demasiado global ... – wik
Este enfoque de utilizar la devolución de llamada global ajaxError no funciona con modelos/colecciones Backbone si los métodos fetch, sync, create tienen una devolución de llamada de error proporcionada como opción. –