1

メニュー/サブメニューが別のビューであるかなり大きなバックボーン アプリがあります。liメニュービュー内には、クリックイベントを処理して強調表示するロジックがあります。liただし、アプリケーション内から別のビューに移動するときに特定のものを強調表示する方法にこだわっています (ルーターを使用するなど)。

利用可能なオプション:

  1. 各 Views からrender()メニュー div にアクセスし、必要なli
  2. イベント メカニズムを使用し、各ビューから のrender()ようなイベントをトリガーします'CustomerUpdate::render'。

2]が正しい方法だと思います。しかし、私は提案を受け入れています。

どのようなテクニックに従っていますか?

4

1 に答える 1

7

(1)は少し厄介で、メニューの内部状態と構造がいたるところに漏れています。メイン ビューがメニューと密接に結合された結果、小さな泥の玉ができ、小さな泥の玉が常に大きな泥の玉に成長します。

（2）は正しい軌道に乗っていると思いますが、もう少し引き離します。現在のビューはアプリケーションの状態の一部であり、ルーターを介してビューを切り替えると、アプリケーションの状態が変化します。状態と状態の変化を追跡するためにバックボーンで何を使用しますか? モデルと"change"イベントを使用します。アプリケーションの状態専用のグローバル モデルがある場合:

AppState  = Backbone.Model.extend({});
app_state = new AppState;

次に、メニューを管理するビューは、次の変更にバインドできますapp_state。

initialize: function() {
    _.bindAll(this, 'change_current_view');
    app_state.on('change:current_view', this.change_current_view);
}

そして、イベント ハンドラーは<li>s:を処理できます。

change_current_view: function() {
    this.$('li').removeClass('current');
    // This selector is, of course, just for illustration
    this.$('#' + app_state.get('current_view')).addClass('current');
}

次に、ルーターはビューapp_state.set({ current_view: '...'})を切り替えて、補助アクションをトリガーできます。アプリケーションレベルのビューなど、リッスンし"change:current_view"、そのリスナーがビューの交換を処理できるようにすることもできます。これにより、ルーターが簡素化されます。私が話していることを説明するのに役立つ簡単なデモを次に示します。

http://jsfiddle.net/ambiguous/fr8sG/

この「アプリケーション状態モデル」アプローチは、一般的に非常に便利です。app-model に状態のビットを簡単に追加したり、設定エディターをセットアップしたりできます。永続性とアプリケーションの初期化もほぼ無料で利用できます。

于 2012-06-07T05:57:27.897 に答える