再度実行するようにイベントハンドラを定義しています。基本的な考え方になります。続いて、個別のノートに対応したビューを見てみましょう。@model.destroy()こちらのポイントはテンプレートを使った描画とユーザーの操作に対するイベントハンドラの定義です。このテンプレートに対して、描画に必要な情報をシリアライズして渡す事で、描画を行っています。プロパティにオブジェクトを渡すことで、ユーザーの操作で発生するイベントに対するハンドラを定義します。セレクタを指定し、値がハンドラメソッドの名前を指定します。モデルが削除された時に、ノートの描画を画面から削除するためのイベントハンドラも定義されています。フレームワークではビュー側で行われた変更とモデル側で行われた変更を上手く同期させる事がとても重要です。この同期処理が必要になるケースは頻繁に存在します。いった機能は組み込まれていません。拡張するライブラリを利用します。データバインディングのためのライブラリで良く利用されているのがbackbone.stickitです。利用することで、ユーザーがフォームに入力したデータをモデルに反映させたり、逆にモデルが変更された時にビューの描画を即座に更新する、といった処理が簡単に定義できるようになります。ノートの入力フォームを表示しているビューの実装を見てみましょう。プロパティの定義に注目してみてください。オブジェクトを返すようになっています。キーが入力フィールドのセレクタ、値が対応するモデルの属性名です。定義を有効化しています。属性に即座に反映されるようになります。メソッドの呼び出しを忘れると、バインディングのためのイベントハンドラが定義されないので注意してください。よるタイトルの表示で利用しているように実際にはフォームに関わらず利用する事ができます。hljs.highlightBlock(e)ルーターによるディスパッチこれまでに定義してきたビューを画面に描画するためのディスパッチ処理を行っているルーターについても知っておきましょう。読み込みとアプリケーションの起動を分けておくことです。単体テストのコードを書くのが非常に難しくなってしまいます。あれば定義してあるメソッドを呼び出す仕組みになっています。ルーターは定義しただけでは動作しません。()_;を実行します。遷移させたい時は、_Backbone.history.navigate_を呼び出します。イベントをトリガーするかどうかは、オプションで指定できます。パス部分を直接利用してマッチするかどうかを判別できます。末尾にハッシュを付与して、ハッシュ部分にパスを擬似的に設定しマッチするかどうかの処理に利用します。利用できなくても適切にディスパッチが行われるように工夫する必要があります。利用できないと、ブラウザのリロードが発生した時に、実行されるアクションが固定されてしまうので、どういったアクセスパターンがあるかを考え、ディスパッチの動作を設計しなければいけません。ディスパッチ処理に渡す場合があります。それによって初回の無駄なリクエストを減らす事ができます。ダイレクトアクセスに対してどのように対応するか、を考えておく必要があります。遷移する必要が無く、アプリケーションのエンドポイントが固定できるなら、ルーターを使わずに直接ディスパッチのためのメソッドを呼び出すことも一つの手段です。フレームワークで守っておくべき基本的な事項は、レイヤーの責任を守る、ということです。ここまでで紹介してきたように、モデルはデータを取り扱い保持すること、そしてサーバーサイドと通信する事等が主な役割です。発生したイベントを受け取って処理を行うことがその役割です。通信が実行されている様な状況になっていると、境界が守れていないサインです。内部に限定して処理を行うべきです。ないと、イベントの定義が分散して、どの処理がどこに実装されているかが分からなくなる事に繋がります。ビューの担当範囲についても責任範囲を守ることが大事です。用意する必要が無くなり、テストが容易になるというメリットもあります。各コンポーネントが連携して動作しなければならない場合は、できるだけイベントを拾って処理するのが基本です。イベントを経由する形にすることで、各コンポーネントはお互いの詳細や自身に依存する対象の存在を知る必要が無くなります。利用するならさっきのアプリケーションではいくつかイケてない部分があります。ルータークラス自体が、アプリケーション全体の画面切り替えを兼ねています。簡単なアプリケーションならそこまで見通しに影響はありませんが、複雑なアプリケーションになると、ルータークラスが肥大化する危険性があります。全体の画面を切り替える処理等の様に、汎用的に利用されそうな部分まで色々と自分で実装しなければならないのは少し面倒です。段階的に機能拡張していくと継ぎ接ぎな実装になる危険もあります。そのシンプルさ故に、よくある処理を何度も実装する必要があったり、アプリケーションが複雑になると、実装が混乱して上手く構造化できなくなったりする場合があります。上に色々な機能を追加した機能強化版のフレームワークを利用するのが良いでしょう。基に機能を追加したフレームワークはいくつかありますが、その中でもメジャーなものは以下の二つだと思います。