4

一般的なバックボーンビューコードをどこに配置するか疑問に思っています。たとえば、「NewPosts」ビューには次のものがあります。

  createPost: (event) ->
    #...
    @collection.create attributes,
      #...
      error: @handleError


  handleError: (entry, response) ->
    if response.status == 422
      #...

そのhandleError関数は、さまざまなビューの中で使用されます...これを配置する場所に関するベストプラクティスについてはよくわかりません。これを入れることができるビューヘルパーに相当するバックボーンはありますか？他の攻撃方法はありますか？

4

4 に答える 4

4

注：私のCoffeeScriptは錆びているので、JSでこれに答えていますが、アイデアは翻訳されるべきです。

明らかに、これを解決する1つの方法は、すべてのビューに親クラスを与えてから、handleErrorのようなメソッドをそのクラスに配置することです。ただし、メソッドを追加する方法のような、より「ミックスイン」を探している場合は、それも可能です。

バックボーンビューは、次のように、extendメソッドへの引数で初期化されます。

var MyView = Backbone.View.extend({
    someMethod: function(){ doSomething();}
});

その議論は魔法のようなものではありません。これは単なるJSオブジェクトなので、次のように_.extendを使用して拡張できます。

var myCommonMethods = {
    handleError: function ...
}

var MyView = Backbone.View.extend(_({
    someMethod: function(){ doSomething();}
}, myCommonMethods));

このアプローチの利点は、必要な数のメソッドセットを「ミックスイン」できることですが、親クラスを使用する場合は、はるかに制約があります。ただし、親クラスのアプローチはより単純です。

var BaseView = {
    handleError: function ...
}

var MyView = BaseView.extend({
    someMethod: function(){ doSomething();}
});

だからそれは本当にあなたの特定のニーズに依存します。

個人的には、私のコードでは両方のアプローチを使用しています。すべてのビューが拡張するBaseViewがあり、非常に一般的なロジック（ほとんどのビューが使用するテンプレートシステムなど）をその中に入れています。次に、機能を追加するさまざまなメソッドセットの「ミックスイン」があります。

たとえば、elとして「select」要素を持つすべてのビューのメソッドのミックスインセットがあります。これにより、これらのビューには、意味のある基本クラスがありますが、共通のメソッドセットもあります（たとえば、すべてのビューには、ビューのel内の特定のオプションに「selected」属性を追加できるselectOptionメソッドがあります）。お役に立てば幸いです。

于 2012-10-27T00:48:16.853 に答える
2

これは、いくつかの方法で行うことができます。このメソッドを使用してベースビューを定義してから、Backbone.Viewではなくこのビューから他のすべてのビューを拡張します。

var Base = Backbone.View.extend({
    handleError:function() {...}
});

var MyView = Base.extend({ ... });

または、ヘルパーを使用して既存のビューを拡張します

var Helper = {
    handleError:function() {...}
};

var View1 = Backbone.View.extend({ ... });
var View2 = Backbone.View.extend({ ... });
$.extend(View1, Helper);    
$.extend(View2, Helper);
于 2012-10-27T00:47:58.647 に答える
1

イベントをリッスンするエラー処理モデルを実装します。独自のカスタムイベントを作成することも、デフォルトを使用することもできます。大規模で複雑なbackbone.jsアプリを作成しましたが、イベントモデルを活用する方法を学ぶまで、アーキテクチャに関しては非常に困難でした。これにより、懸念事項間の処理関係が大幅に節約されました。

イベントディスパッチャーを作成し、初期化するときにビューに引数として渡します。

このようなもの：

var dispatcher = {};

_.extend(dispatcher, Backbone.Events);

dispatcher.on("event", function(msg) {
  // delegate to error handler
});


view = new View([dispatcher: dispatcher])
view.dispatcher.trigger('event', {})

イベントディスパッチャーを使用して見つけたので、ビュー、コレクション、モデルが分離され、テストが非常に簡単になりました。Chromeのコンソールでイベントを発生させて、さまざまなコンポーネントが個別にどのように動作するかを確認できました。ディスパッチャーをロガーに公開することで、デバッグが非常に簡単になり、コードがよりクリーンになりました。

于 2012-10-27T01:02:00.590 に答える
1

申し訳ありませんが、コード例はありませんが、リファクタリングの概念の1つは、すべてのサブクラスがコードを再利用できるように、共通コードを基本クラスに移動することです。

しかし、オブジェクトやディスパッチャーなどのイベントソースからのエラーイベントをビューがサブスクライブするというRimianのアイデアは本当に気に入っています。これにより、すべてのビューが相互に分離され、エラーイベントを受信したときにエラーが処理されます。

于 2012-10-27T06:22:48.997 に答える