2

マスターと詳細のシナリオを扱うバックボーン チュートリアルの大部分は、ルートから渡されたモデルを使用して新しいビューを作成することによって詳細状態を処理します (例)。それぞれの長所と短所は何か、代替オプションは何なのか疑問に思っています。

新しいビューをインスタンス化するこのアプローチについて私がいつも気になっていることは、Backbone のモデルとビューのバインディングを利用する機会を逃しているように見えるということです。つまり、選択したモデルに基づいて更新される単一の詳細ビューを作成します。ただし、これには、UI/アクティブ状態のみに関係する別のモデルが必要になります。

次の 3 つのパターンが考えられます。

  • アクティブなディテールごとにビューを作成/破棄します。(これは潜在的なゾンビの問題は言うまでもなく、余分な作業のように思えます)
  • アクティブな詳細を表す追加のモデルを維持し、モデルが更新されたときにそれ自体を再レンダリングする 1 つのビューを作成します
  • 関連付けられたモデルを交換するメソッドを使用して 1 つのビューを作成します (これはイベント バインディングの問題につながる可能性があり、おそらく良い考えではありません)。

上記のチュートリアルの例のような単純なケースのコンテキストでは、長所と短所は何ですか? UIモデルを使用するという#2のアイデアは悪い習慣ですか? 他の解決策はありますか？

4

1 に答える 1

1

私の経験では、UI モデルは非常に役に立ちました。ContextModelアプリのすべての「ページ」を維持します。本当に素晴らしいのは、「ページ」が完全に初期化されることが保証されているContextModelため、コンテキストが最初に作成された場所は1つだけです。

AppView特定のルートがトリガーされたときに、ページの初期コンテキストの作成を常に処理します。ルート ハンドラーは、コンテキストのデフォルトが設定される場所であり、物事はルートの値から解析されます。

ページ自体が初期化されると、 への変更について心配するだけでContextModel済み、必要な更新を行ってからパスを更新するハンドラーを用意するだけで済みます。

これは、私たちの から直接引っ張ってきた例AppViewです:

onSomeRoute : function (project, category, pivot, tab, item) {

  // Setup page context with defaults.
  var options = {
    category : 'traits',
    tab      : 'population',
    item     : null
  };

  // Figure out what the allowed categories and tabs are from this
  // environment by checking against all schema items.
  [snipped]

  // Resolve the `category` and the `pivot`. Try and match the pivot's
  // slug, else choose the first pivot in the category.
  if (_(categories).contains(category)) options.category = category;

  [snipped]

  if (pivots) options.pivot = pivots.find({ slug : pivot }) || pivots.first();

  // Resolve the `tab` and `item`. Only allow valid tabs, and then try
  // to match the item's slug as well, or choose the first one.
  var tabs = ['population', 'sources', 'engagement', 'retention'];
  if (_(tabs).contains(tab)) options.tab = tab;
  [snipped]

  // Now that we've applied some defaults, make sure the path is
  // updated to reflect what the interface is showing.
  [snipped]

  this.loadPage('some-page', options);
}

次に、PageView問題の変更ハンドラがいくつかあります。

// When category changes, try to match the current pivot against pivots
// in the category, else choose the first pivot from the category.
onCategoryChange : function (context, category) {
  var schema = this.context.get('environment').get(category);
  if (!schema.contains(this.context.get('pivot')))
    this.context.set('pivot', schema.first());

  this.router.update({
    category : category
  });
},

// When the pivot changes, create a new set of segments for the context.
onPivotChange : function (context, pivot) {
  Segmenter.segment(context, function (segments) {
    context.get('segments').reset(segments).each(function (segment) {
      segment.evaluate();
    });
  });

  this.router.update({
    pivot : pivot.get('slug')
  });
},

すべての変更ハンドラーが、コンテキストの変更に基づいてページの URL を更新し続けることに注意してください。(これを非常に簡単にするために、ルーターにいくつかのカスタム メソッドを作成しました。) しかし、それらは、ページで発生する必要がある他のロジックも実行します。

うまくいけば、そのいくつかがあなたにアイデアを与えるのに役立ちます. 一般に、URL に保存されている状態はすべて私たちPageContextのものであり、その状態から派生した他のいくつかのものも便宜上そこに保存されます。

于 2012-07-23T18:24:45.063 に答える