Ответ 1
Прежде всего я хотел бы взглянуть на книгу Backbone.js on Rails, которая является отличной отправной точкой, хотя и нацелена на промежуточной и продвинутой аудитории. Я купил эту книгу, уже работая с рельсами, но в качестве базового новичков backbone.js, и она мне очень понравилась.
Помимо этого, есть некоторые фундаментальные проблемы с объединением этих структур, которые выходят за рамки деталей, описанных в этой книге и других книгах. Ниже приведены некоторые вещи, которые я предлагаю вам подумать, исходя из моего собственного опыта, связанного с RoR и backbone.js. Это длинный ответ и немного отличается от специфики вашего вопроса, но я надеюсь, что это может помочь вам понять "большую картину" понимания проблемы, с которой вы сталкиваетесь.
Rails: веб-Framework vs API
Первое, с чем вам приходится столкнуться при использовании backbone.js поверх приложения rails, - это то, что нужно делать с представлениями, но это на самом деле просто поверхность гораздо более глубокой проблемы. Проблема заключается в том, что означает создание веб-службы RESTful.
Rails настроен из коробки, чтобы побудить своих пользователей создавать сервисы RESTful, структурируя маршрутизацию с точки зрения набора ресурсов, доступных в унифицированных URI (определенных в вашем файле routes.rb) с помощью стандартных действий HTTP. Поэтому, если у вас есть модель Post, вы можете:
- Получить все сообщения, отправив
GETзапрос на/posts - Создайте новое сообщение, отправив запрос
GETна/posts/new, заполнив форму и отправив ее (запросPost) на/posts - Обновите сообщение с id
123, отправив запросGETна/posts/123/edit, заполнив форму и отправив ее (запросPUT) наposts/123 - Уничтожьте сообщение с id
123, отправив запросDELETEна/posts/123
Ключевым моментом, который следует помнить об этом аспекте Rails, является то, что он принципиально без гражданства: независимо от того, что я делал ранее, я могу создать новый Post, просто отправив запрос Post с действительными данными формы правильный URI, скажем /posts. Конечно, есть предостережения: мне может потребоваться войти в систему (иметь идентификатор сеанса cookie, который идентифицирует меня), но по существу Rails действительно не заботится о том, что я делал, прежде чем отправил этот запрос. Я мог бы следить за ним, обновляя другое сообщение или отправляя действительное действие на любые другие ресурсы, доступные мне.
Этот аспект создания Rails упрощает превращение веб-приложения Rails в Javascript-light в API: ресурсы будут похожи или одинаковы, веб-фреймворк возвращает HTML-страницы, в то время как API (обычно) возвращает данные в формате JSON или XML.
Backbone.js: новый слой с состоянием
Магистраль также основана на ресурсах RESTful. Всякий раз, когда вы создаете, обновляете или уничтожаете модель backbone.js, вы делаете это посредством стандартных HTTP-действий, отправленных в URI, которые предполагают архитектуру RESTful, описанную выше. Это делает его идеальным для интеграции с сервисами RESTful, такими как RoR.
Но здесь следует подчеркнуть тонкую точку: backbone.js легко интегрируется с Rails как API. То есть, если вы отмените представления HTML и просто используйте Rails для обслуживания ресурсов RESTful, интегрируясь с базой данных, выполняя управление сеансом и т.д., Тогда он очень хорошо интегрируется со структурой, которую backbone.js предоставляет для клиентской стороны код. Многие люди утверждают, что нет ничего плохого в использовании рельсов таким образом, и я думаю, что во многих отношениях они правы.
Сложности возникают из-за вопроса о том, что делать с той частью Rails, которую мы только что выбросили: представления и то, что они представляют.
Люди с государственным статусом, машины без гражданства
Это действительно более важно, чем может показаться на первый взгляд. Представления HTML представляют собой интерфейс без состояния, который люди используют для доступа к ресурсам RESTful, предоставляемым вашим сервисом. Уход с ними оставляет вас с двумя точками доступа:
- Для людей: богатый клиентский интерфейс, предоставляемый слоем backbone.js(stateful)
- Для машин: ресурсо-ориентированный API RESTful, предоставляемый слоем рельсов (безстоящий)
Обратите внимание, что для людей уже нет интерфейса без гражданства (RESTful). Напротив, в традиционном приложении rails с API нам было что-то ближе к этому:
- Ресурсы HTML для людей (без гражданства)
- Ресурсы JSON/XML (API) для машин (безстоящие)
Последние два интерфейса для доступа к ресурсам гораздо ближе по своей природе друг к другу, чем предыдущие два. Просто подумайте, например, о рельсах respond_with, в котором используется сходство для обертывания различных респондентов RESTful в унифицированном методе.
Совместная работа
Все это может показаться очень абстрактным, и я не знаю. Чтобы попытаться сделать его более конкретным, рассмотрите следующую проблему, которая вернется к вашему вопросу о том, как заставить рельсы и backbone.js работать вместе. В этой проблеме вы хотите:
- Создайте веб-сервис с богатым опытом на стороне клиента, используя backbone.js, с рельсами в качестве сторонних сервисов в формате JSON.
- Используйте
pushState, чтобы дать каждой странице в приложении URL-адрес (например,/posts/123), к которому можно получить доступ напрямую (путем ввода его в панель браузера). - Для каждого из этих URL-адресов также служит страница HTML для клиентов без javascript.
Это не необычные требования к современному веб-сервису, но они создают сложную задачу. Короче говоря, теперь вам нужно создать два "ориентированных на человека" слоев:
- Пользовательский клиентский интерфейс (шаблоны и представления backbone.js)
- Неактивные HTML-ресурсы (Rails HTML-представления)
Сложность фактического выполнения этого приводит многих к тому, чтобы отказаться от последнего из этих двух и просто предложить богатый клиентский интерфейс. То, что вы решите сделать, зависит от ваших целей и того, чего вы хотите достичь, но стоит тщательно обдумать эту проблему.
В качестве еще одной возможной ссылки для этого, я бы предложил взглянуть на O'Reilly RESTful Web Services. Может показаться странным рекомендовать книгу о REST в вопросе о Rails и Backbone.js, но на самом деле я думаю, что это ключевая часть, которая подходит для этих очень разных фреймворков, и понимание ее более полно поможет вам воспользоваться преимуществами сильные стороны обоих.