Изучение MVC на стороне клиента с Backbone.js

app / assets / templates / posts / item.jst.eco

<td><%= @post.get 'title' %></td>
<td><%= @post.get 'body' %></td>
<td><a href="#posts/<%= @post.id %>">show</a></td>

Еще одна вещь, которую нам нужно сделать, прежде чем мы сможем просмотреть нашу домашнюю страницу в браузере: мы должны загрузить маршрутизатор нашего приложения.

приложение / активы / JavaScripts / blog.js.coffee

window.Blog =
  Models: {}
  Collections: {}
  Views: {}
  Routers: {}
  init: ->
    new Blog.Routers.Posts
    Backbone.history.start()

$(document).ready ->
  Blog.init()

Обработчик события onDOMReady вызывает функцию init, которая создает PostsRouter и сообщает Backbone начать мониторинг всех событий hashchange. Все наши клиентские страницы будут использовать хеш-фрагменты в качестве URL. Backbone будет прослушивать изменения фрагментов хеша и направлять их, используя маршруты, указанные в нашем PostsRouter.

Наконец, теперь мы можем запустить наш сервер Rails и открыть наше приложение по адресу http: // localhost: 3000 / posts . К сожалению, у нас пока нет сообщений. Итак, давайте перейдем к созданию поста.

Создание сообщения

Внизу нашего существующего домашнего шаблона находится ссылка для создания нового сообщения:

приложение / активы / шаблоны / сообщений / index.jst.eco

<a href="#posts/new">new post</a>

Это означает, что нам нужно добавить другой маршрут и действие к нашему PostsRouter.

Приложение / активы / JavaScripts / маршрутизаторы / posts_router.js.coffee

class Blog.Routers.Posts extends Backbone.Router
  routes:
    '' : 'index'
    'posts/new' : 'new'
  index: ->
    # same code from above...
  new: ->
    post = new Blog.Models.Post
    posts = new Blog.Collections.Posts
    posts.bind 'add', =>
      triggerRouter = true
      @navigate '', triggerRouter
    view = new Blog.Views.PostsNew
      collection: posts
      model: post
    view.render()

В нашем новом действии мы создаем модель Post, затем создаем коллекцию Posts и привязываем анонимный обработчик к его событию add. Коллекция будет запускать событие добавления всякий раз, когда к нему добавляется новая модель. Наш обработчик события добавления эквивалентен перенаправлению на стороне сервера, переместив маршрутизатор на «пустой» маршрутизатор (домашнюю страницу). Наконец мы создаем и визуализируем представление для отправки нового сообщения.
приложение / активы / JavaScripts / просмотров / сообщений / posts_new.js.coffee

class Blog.Views.PostsNew extends Backbone.View
  el: '#app'
  template: JST['posts/new']
  events:
    'submit form' : 'create'
  render: ->
    $(@el).html(@template(post: @model))
    @
  create: (event) ->
    event.preventDefault()
    @collection.create
      title: @$('#title').val()
      body: @$('#body').val()

Элемент (PostsNew # el), используемый в нашем новом представлении сообщений, является глобальным «#app» <div>. Новое представление сообщения заменит содержимое этого <div> своим собственным шаблоном, содержащим форму для отправки нового сообщения.

Представление также регистрирует обработчик для события submit из <form> в своем шаблоне. Этот обработчик останавливает поведение отправки формы по умолчанию, а затем просит свою коллекцию сообщений создать новое сообщение. Это приведет к HTTP-запросу POST на сервер, и в случае успеха коллекция вызовет событие add. Это то же событие, к которому наш PostsRouter в своем новом действии привязал анонимный обработчик «перенаправления».

А вот и новый шаблон представления поста:

приложение / активы / шаблоны / сообщений / new.jst.eco

<h1>New post</h1>

<form>
  <div class="field">
    <label for="title">Title</label><br />
    <input type="text" name="title" id="title" />
  </div>
  <div class="field">
    <label for="body">Body</label><br />
    <textarea name="body" id="body"></textarea>
  </div>
  <div class="actions">
    <input type="submit" value="create" />
  </div>
</form>

<a href="#">back</a>

Отлично, теперь мы можем создавать сообщения. Однако мы не можем позволить людям создавать посты без заголовка и тела. Давайте посмотрим, что мы можем сделать, чтобы проверить наши новые сообщения.

Проверка сообщения

Adding some client-side validation will help improve the responsiveness of our UI. We’ll still validate posts on the server-side, but for the user’s sake, I feel this duplication is worth the tradeoff.

Backbone models include a validate method that can be used to perform custom validations. However, as Rails developers we’re used to ActiveRecord‘s high-level, declarative approach to validation. And thanks to the jQuery validation plugin, we can have declarative validation on the client-side too.

First, download the plugin (after downloading and unzipping it, remember to restart your Rails server).

$ wget http://jquery.bassistance.de/validate/jquery-validation-1.9.0.zip --directory-prefix vendor/assets/javascripts
$ unzip vendor/assets/javascripts/jquery-validation-1.9.0.zip -d vendor/assets/javascripts

Затем добавьте плагин в файл манифеста JavaScript нашего приложения.

приложение / активы / JavaScripts / application.js

//= require jquery
//= require jquery_ujs
//= require underscore
//= require backbone
//= require jquery-validation-1.9.0/jquery.validate
// other default initialization

Теперь мы можем добавить некоторые проверки в наши новые сообщения.

приложение / активы / JavaScripts / просмотров / сообщений / posts_new.js.coffee

class Blog.Views.PostsNew extends Backbone.View
  # same code as above...
  render: ->
    $(@el).html(@template(post: @model))
    @$('form').validate
      rules:
        title: 'required'
        body: 'required'
    @
  create: (event) ->
    # same code as above...

Плагин jQuery validate позволяет вам задавать правила проверки для каждого атрибута. Здесь нам требуется заголовок и тело. Метод validate остановит отправку формы при сбое проверки. Это также предотвратит выполнение обработчика отправки формы представления нового поста, #create.

Идите и попробуйте в браузере. Отправка сообщения без заголовка и тела теперь не удастся и отобразит сообщение об ошибке.

Просмотр сообщений

Хорошо, пока мы можем отобразить список сообщений, создать сообщение и проверить сообщение. Далее идет просмотр отдельного поста.

На нашей домашней странице каждая строка сообщения содержала следующую ссылку для просмотра сообщения:

приложение / активы / шаблоны / сообщения / item.jst.eco

<td><a href="#posts/<%= @post.id %>">show</a></td>

Давайте добавим маршрут и действие в наш маршрутизатор для этой страницы поста (т.е. #show).

Приложение / активы / JavaScripts / маршрутизаторы / posts_router.js.coffee

class Blog.Routers.Posts extends Backbone.Router
  routes:
    '' : 'index'
    'posts/new' : 'new'
    'posts/:id' : 'show'
  index: ->
    # same code from above...
  new: ->
    # same code from above...
  show: (id) ->
    post = new Blog.Models.Post id: id
    view = new Blog.Views.PostsShow model: post
    collection = new Blog.Collections.Posts [post]
    post.fetch()

Этот новейший маршрут включает в себя именованный параметр: id. Backbone автоматически передаст значение именованного параметра в качестве аргумента нашему действию #show.

В настоящее время в Backbone выбор отдельной модели не очень элегантен. Выше один из самых чистых способов. Сначала вы создаете модель с запрошенным идентификатором, затем добавляете модель в коллекцию и, наконец, говорите модели, чтобы она сама выбирала.

Наше действие #show также создает экземпляр следующего представления PostsShow для отдельной записи.

приложение / активы / JavaScripts / просмотров / сообщений / posts_show.js.coffee

class Blog.Views.PostsShow extends Backbone.View
  el: '#app'
  template: JST['posts/show']
  initialize: ->
    @model.bind 'change', @render, @
  render: ->
    $(@el).html(@template(post: @model))
    @

Во время инициализации представление добавляет обработчик к событию изменения своего сообщения. Почта запустит событие изменения после того, как оно было успешно получено.

Элемент (PostsShow # el) для этого представления — это тот же глобальный контейнер «#app» <div>, который использовался списком сообщений и новыми представлениями сообщений. Как и эти два представления, отдельное представление поста также заменит содержимое этого <div>.

А вот посты показывают шаблон представления представления:

приложение / активы / шаблоны / сообщений / show.jst.eco

<p>
  <b>Title:</b>
  <%= @post.get 'title' %>
</p>

<p>
  <b>Body:</b>
  <%= @post.get 'body' %>
</p>

<a href="#">back</a>

Ссылка «назад» возвращается на нашу домашнюю страницу.

Клиентская MVC

Backbone.js brings the power and maintainability of MVC to the client-side. Routers can be used like Rails server-side controllers to create responsive, single-page apps. Views are also like controllers, but instead of responding to url changes, they respond to DOM level events, such as link clicks and form submissions. Templates contain the app’s markup, they’re what Rails calls views. Models and collections round out Backbone.js, providing traditional class-based, client-side domain modeling.

We’ve only covered the first two letters in CRUD, but it was a lot! I hope this article can give you some direction in implementing the rest of them. The client-side JavaScript MVC space is growing rapidly. Backbone’s quick and easy Rails integration makes it an easy sell but there are other options. Be sure to research other frameworks before evaluating what works best for you.

Source: http://blog.carbonfive.com/2011/12/19/exploring-client-side-mvc-with-backbonejs/