Как обрабатывать 404 данных Ember в пути?

Question

В моем маршруте у меня есть метод, который пытается запросить список моделей с сервера

model: -> 
    App.MyModel.find 
     projectId: (@modelFor "project").id 

Теперь, очевидно, иногда это может вернуть 404.

На тот момент, когда это происходит, Эмбер просто останавливается делать что-либо. Просмотр не отображается, контроллер не настроен.

Итак, как я могу правильно обрабатывать 404 (т. Е. Показывать представление ошибки)?

Answer 1

Плохая новость: прямо сейчас, данные ember-data ничего не делают, когда он получает 404 на find(). Вообще. Модель находится в состоянии «загрузки» навсегда.

Здесь, на мой взгляд, нет абсолютно не тупых вариантов. То, что я, вероятно, сделаю в качестве последнего средства, добавит атрибут notFound на мой DS.Model, а вместо возврата 404 вернет JSON с notFound, установленным на true. Это болезненно, я знаю ...

--- Я изначально предложил решение переопределить find в подкласс RESTAdapter. Тогда я заметил, что find НЕ получает переданный экземпляр записи, который предположительно загружается. Таким образом, не переходите к обработке 404s, помещая запись в состояние ошибки.

[Примечание: уголек-данные резко изменились с марта 2013 года, информация в этом ответе больше не может быть оперативно]

Answer 2

Кстати, «новые» BasicAdapter было выпущено только в настоящее время. Вопрос для меня был, облегчит ли это обработку 404 ошибок.

Подход № 1

Мой первый подход - похоже на то, что Кристофер предлагал - было добавить дополнительное поле, содержащее статус HTTP.

status: DS.attr("number"); 

И тогда я использовал этот AJAX вызов:

$.getJSON(url, data).then(null, function(xhr) { 
    return { 
    id: id, 
    statusCode: xhr.status 
    }; 
}).always(function(data) { 
    return process(data).load(); 
}); 

Что это делает для преобразования ответа об ошибке (XHR) на хэш, содержащий требуемый идентификатор и код состояния. Наконец, успешный результат или неудавшийся хэш передаются в магазин.

Этот вид работ, но не очень практичен: когда вы показываете список всех экземпляров модели, эти «макетные» экземпляры должны быть отфильтрованы вручную.

---

Подход № 2

Другая идея состояла в том, чтобы создать специальную модель ошибок.

App.Error = App.Model.extend({ 
    status: DS.attr("number") 
}); 

И по запросу:

$.getJSON(url, data).then(null, function(xhr) { 
    return App.store.load(App.Error, {}, { 
    id: 0, 
    status: xhr.status 
    }); 
}).done(function(data) { 
    return process(data).load(); 
}); 

Это позволит загрузить и создать новый экземпляр модели ошибок и поместить его в магазин.

Проблема в том, что Эмбер на самом деле не «принимал» это. Приложение просто прекратило маршрутизацию, больше ничего не делая. Так что это похоже на тупик, а :(

Answer 3

Я ударил этот вопрос, а сегодня.

Однако, посмотрев на источник, то появляется модель на самом деле установка использовать Ember.Evented, и мы . можете добавить свои собственные обработчики для этих случаев

эти два события, которые привлекли мое внимание было becameError и didLoad

в моем случае я был в состоянии сделать что-то вроде следующего:.

// Grab a user by id. 
var user_rec = App.User.find(user.id); 

// Oh no! Error! 
user_rec.on('becameError', function() { 
    alert('I could not find you!'); 
}); 

// We should be good! Proceed! 
user_rec.on('didLoad', function() { 
    alert('Your email: '+this.get('email')); 
}); 

Вот источник на github: https://github.com/emberjs/data/blob/master/packages/ember-data/lib/system/model/model.js

Надеюсь, если это действительно так, как мы должны обращаться с вещами, в ближайшем будущем в руководствах будет добавлена ​​дополнительная документация.