web-dev-qa-db-ja.com

バックボーンmodel.destroy（）が正常に機能している場合でもエラーコールバック関数を呼び出しますか？

ユーザーがモデルのビューでリンクをクリックしたときに破棄しようとしている Backbone.js モデルがあります。ビューはこのようなものです（質問の最後にある CoffeeScript で実装されているため、疑似コード）。

var window.ListingSaveView = Backbone.View.extend({
  events: {
    'click a.delete': 'onDestroy'
  },

  onDestroy: function(event){
    event.preventDefault();
    this.model.destroy({
      success: function(model, response){
        console.log "Success";
      },
      error: function(model, response){
        console.log "Error";
      }
    });
  }
});

ブラウザでdeleteリンクをクリックすると、関連するデータベースレコードの破棄がサーバーで正常に記録され、200応答が返されても、常にErrorがコンソールに記録されます。ページを更新すると（コレクションがDBから再レンダリングされるため）、削除したモデルが失われます。

興味深いのは、エラーコールバックにresponseを記録すると、ステータスコード200は成功を示しますが、レポートもstatusText: "parseerror" それがどのような意味でも。サーバーログにエラーはありません。

何が悪いのですか？

これはサーバーからの応答です：

  Object
    abort: function ( statusText ) {
    always: function () {
    complete: function () {
    done: function () {
    error: function () {
    fail: function () {
    getAllResponseHeaders: function () {
    getResponseHeader: function ( key ) {
    isRejected: function () {
    isResolved: function () {
    overrideMimeType: function ( type ) {
    pipe: function ( fnDone, fnFail ) {
    promise: function ( obj ) {
    readyState: 4
    responseText: " "
    setRequestHeader: function ( name, value ) {
    status: 200
    statusCode: function ( map ) {
    statusText: "parsererror"
    success: function () {
    then: function ( doneCallbacks, failCallbacks ) {
    __proto__: Object

Destroyが（Ruby on Rails）と対話するサーバーアクションは次のとおりです

  # DELETE /team/listing_saves/1.json
  def destroy
    @save = current_user.team.listing_saves.find(params[:id])
    @save.destroy
    respond_to do |format|
      format.json { head :ok }
    end
  end

そして、これはそのようにそれを好む人々のためのバックボーンビューの実際のCoffeeScript実装です：

class MoveOutOrg.Views.ListingSaveView extends Backbone.View
  tagName: 'li'
  className: 'listing_save'
  template: JST['backbone/templates/listing_save']
  events:
    'click a.delete_saved': 'onDestroy'

  initialize: ->
    @model.bind 'change', this.render
  render: =>
    renderedContent = @template(@model.toJSON())
    $(@el).html(renderedContent)
    this
  onDestroy: (event) ->
    event.preventDefault() # stop the hash being added to the URL
    console.log "Listing Destroyed"
    @model.destroy
      success: (model, response)->
        console.log "Success"
        console.log model
        console.log response

      error: (model, response) ->
        console.log "Error"
        console.log model # this is the ListingSave model
        console.log response
javascriptruby-on-railsruby-on-rails-3backbone.jsjavascript-framework
36
David Tuite

@David Tuiteコメント：

「わかりました。わかりました。Backboneは、JSON応答が破棄されたレコードのJSONシリアル化であると想定しているようです。ただし、Railsコントローラジェネレータは、デフォルトではヘッド：okのみを返します。私はJSON応答をレンダリングjsonに変更しました：@listing_save @listing_saveは、私が破棄したばかりのレコードで、成功を記録します。」

参考までに-破棄を行う場合、破棄されたモデルの完全なJSONを返す必要はありません。あなたは空のjsonハッシュを返すことができ、それはうまくいきます。モデルのjsonを返す必要があるのは、保存/更新時のみです。

52
Derick Bailey

私も同じ問題を抱えていました。サーバー（Java）での私のdeleteメソッドでは、何も返しませんでした。ステータスは200/OK（または204 /コンテンツなし）です。そして、「parsererror」の問題は、jqueryが空の応答をJSONに変換しようとしたために発生し、失敗しました（「json」がデフォルトのデータ型であるため）。

私の解決策は、代わりに "text" dataTypeを使用することでした。これはオプションで設定できます。

model.destroy({ dataType: "text", success: function(model, response) {
  console.log("success");
}});
16
ccallendar

コンテンツを返さないため、応答にはステータスコード204が必要です。バックボーンはRESTインターフェースを使用するため、タスクに応じて異なるhttpステータスコードを返す必要があります。

7
David Rios

URLを確認してもよろしいですか？ Backbone.Model URLの最後に.jsonを追加しますか？これをサーバー側で確認するため（respond_to do | format | ... end）、正しいhead :ok応答を送信しない可能性があります

このdestroy Railsメソッドで試して、これが問題であるかどうかをテストします。

def destroy
  @save = current_user.team.listing_saves.find(params[:id])
  @save.destroy
  head :ok
end
0
Tricote

LAMPサーバーでSlim Frameworkを使用すると、 [Response Status to [〜＃〜] delete [〜＃〜] ルート（または返されないカスタムルート）を追加できます何でも）

$app->response()->status(204);//204 No Content

また、これはContent-Typeをtext/htmlに戻し、空の本文を許可します

0
mhume