Как же меня бесят все браузеры, а точнее их разнообразие в поддержке css.  Вот сегодня мучился с отрицательным margin-top. Все браузеры, включая «ослика», нормально его обрабатывали, а Опера — нет. И хоть ты тресни! Пришлось лопатить интернет в поисках хука. И он был найден! Css только для Opera.

Исходный css:

А вот это уже для Оперы только:

Надеюсь, кому-то поможет.

Не знаю, кому как, но, по-моему, я сегодня изобретал велосипед. Но что-то немного погуглив, я не нашёл никаких вразумительных примеров, как написать интеграционные тесты для проверки функционала восстановления пароля. Может это никому и не надо, но всё равно было интересно повозиться с этим.

В общем, вот, собственно, весь тест:

Я не знаю, почему плагин так разрисовал код… Но у меня он именно такой.

Распишу, что же тут и как…

ActionMailer::Base.deliveries.clear — тут очищаем очередь писем.

@user.send_reset_password_instructions() — отсылаем письмо только что созданному пользователю с инструкциями, как восстановить пароль.

@mail = ActionMailer::Base.deliveries.last — получаем последнее отосланное письмо

@host = ActionMailer::Base.default_url_options[:host] — откуда оно было отослано

@mail.should deliver_to(@user.email) — в письме должен быть корректный адрес получателя: пользователя, который был создан.

@mail.should deliver_from(Devise.mailer_sender) — отправить должен быть наш Devise, как установлено в настройках.

@mail.should have_subject(/Reset password instructions/) — тема письма тоже должна быть стандартной, если мы сами ничего не меняли.

@mail.should have_body_text(/#{@user.email}/) — в теле письма опять же должен упоминаться пользователь, вернее, его электронная почта, для которого восстанавливается пароль.

- небольшая регулярка для проверки, что в теле письма есть ссылка на восстановление пароля

- проверка, что в теле письма есть данная ссылка

- получаем ссылку из тела письма

visit change_password_link — переходим по этой ссылке

Ну а дальше уже всё просто: убеждаемся, что открылась нужная страница, заполняем новыми данными, и убеждаемся, что всё хорошо.

 
Не знаю, почему плагин так изуродовал код…..

Сегодня затронем наиболее  обширную тему: отображения(views). Думаю, что будет две части, так как тема всё-таки достаточно большая.

Итак, начнём. Для начала разберёмся с терминологией. В backbone.js отображения (views) — это совсем не то же самое, что в «рельсах». Если Вы помните, то в «рельсах» views представляют из себя просто шаблоны, в которые вставляются некоторые данные. Иногда в них присутствует некоторая простейшая логика, позволяющая отображать список однотипных элементов и т.п. В backbone.js же views больше похожи на контроллеры в «рельсах»: они оперируют данными и ответственные за то, какие данные в каком шаблоне будут отображаться. Шаблоны тоже присутствуют, но они никак отдельно не выделены.

Views будем изучать на примере пользователей — users. И начнём, как бы странно это не казалось, с роутеров. Почему? Да потому что там мы впервые сталкиваемся с вызовом классов views. Но и это не самое начало. Если помните, то в части про роутеры, я рассказывал ,что в момент инициализации нашего приложения, создаются две коллекции: для постов и для пользователей. На данный момент нас будет интересовать коллекция пользователей. Вот строчки из конструктора App.Routers.Posts:

В первой строке мы создаём экземпляр класса коллекции для пользователей, а во второй вызываем метод reset(), который загружает данные в нашу коллекцию. Об этом я уже говорил раньше. Таким образом, на момент полной загрузки странички с нашим приложением, у нас есть вся необходимая информация для работы с пользователями.

Теперь представим, что пользователь кликает по ссылке или в адресной строке набирает путь «/#users«. В соответствии с нашими роутерами, управление передаётся функции users() из всё того же класса App.Routers.Posts:

Первые две строчки не представляют интереса — это всего лишь украшательства. А вот последние две строчки как раз и отвечают за то, чтобы мы увидели правильную информацию. В 3-ей строке мы создаём экземпляр класса App.Views.UsersIndex, который и будет отвечать за отображение пользователей в приложении. Настоятельно обращаю Ваше внимание, что ему в качестве аргумента передаётся наша коллекция пользователей (@users), которую, собственно, нам и предстоит отобразить. Рассмотрим теперь, собственно сам класс App.Views.UsersIndex:

Как видим, данный класс наследуется от Backbone.View — это и не удивительно, т.к. мы и хотим создать отображение. (-:  В следующей строке задаётся функция, которая указывает, где и какой шаблон использовать для построения html-разметки.  В данном случае мы будем использовать Javascript Template(JST). Но и это ещё не всё, что касается шаблонизатора. Лично я буду использовать Eco Template Engine, который позволяет легко и просто делать шаблоны с применением синтаксиса, похожего на erb. Если Вы посмотрите на файлы в директории /templates, то там все файлы с расширением *.jst.eco — это невероятно удобно (-: Кстати, вот содержимое самого файла /templates/users/index.jst.eco:

В данном файле просто задётся разметка, для дальнейшего отображения пользователей.

Но вернёмся к нашему классу  отображения. Дальше следует конструктор нашего класса:

Тут у нас всего одна единственная строчка, которая выполняет очень важную функцию: привязывает функцию-обработчик @render() к событию reset для коллекции @collection, которая будет вызываться каждый раз, когда сработает событие reset. В переводе на русский язык, когда в нашу коллекцию будут загружены данные(reset), их необходимо будет отобразить(@render()). @collection — это та коллекция, которая нам была передана в момент создания экземпляра данного класса, в нашем случае это users.

Рассмотрим теперь саму функцию render().

Набор каких-то мало понятных символов, не так ли? (-: На самом деле всё достаточно просто. Но обо всём по-порядку.

el — это DOM-элемент нашего документа, куда будет вставлено наше отображение.

@el указывает на то, что это внешняя переменная, что она нам была передана на момент вызова нашей функции.

$(@el) — это просто jQuery способ выбрать соответствующий DOM-элемент в разметке страницы.

А теперь вся эта строка:
$(@el).html(@template()) — заменить содержимое элемента el нашим шаблоном. Только и всего.

Следующая строка не что иное, как перебор всех экземпляров в коллекции и для каждого вызов функции appendUser().

Функция appendUser() выполняет абсолютно туже функцию, только касательно не коллекции, а отдельной записи — модели. Попробую описать, что это и для чего. Я сделал так, что каркас для коллекции строится сам по себе, а уже в этот каркас добавляются данные для каждой модели отдельно. В принципе, можно было сделать так, что уже в шаблоне пробегать по все коллекции и отрисовывать каждую модель. Но такой способ ведёт к неприятным последствиям. Представьте, например, что Вам на странице надо отобразить сотню или тысячу элементов. Не вопрос, отобразить не проблема: ну подумаешь отрисовываются все элементы, это не проблема. Проблемы начинаются, когда над эти данными начинают производить какие-то операции: добавление, удаление и т.п. Так вот при всех этих процессах придётся каждый раз прорисовывать все сто или тысячу элементов! А это уже не оправданная нагрузка. Чтобы этого не происходило, за отрисовку каждого элемента отвечает свой собственный класс, всё просто и красиво (-:

Мне остаётся только добавить, что в функции appendUser() я использую jQuery функцию prepend(), чтобы в результате недавно добавленные пользователи были выше в списке, чем давно добавленные.

Ну и последняя строка в фукции render() — это просто песня: символ @. (-: Это просто Coffeescript аналог, синоним слова this из Javascript-а. Просто приведу цитату из документации backbone.js, для чего это необходимо:

Хорошее соглашение — делать return this в конце render, чтобы иметь возможность делать цепочечные вызовы.

Так как Coffeescript намного упрощает написание кода, то нам просто достаточно написать «@», что и означает return this. Красота! (-:

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

Сегодня коротенько пробежимся по моделям и коллекциям. Расскажу, что это и с чем это едят.

Начнём с модели:

В большинстве случаев это всё, что будет указываться при описании модели: указываем, что модель наследуется от Backbone.Model, а потом указываем путь, по которому Backbone будет слать RESTful-запросы.

Я несколько слукавил, когда сказал, что это всё, что Вам надо будет писать при описании модели (-: В более-менее серьёзном приложении необходимо будет задать ещё значения по умолчанию для модели (defaults), а так же некоторую проверку вводимых значений (validation). Всё это, в принципе, выходит за рамки ознакомительной части, однако, валидацию я добавлю чуть позже, но не в слое модели, а в слое отображения (view), при помощи плагина jquery.validation: он гораздо гибче, чем встроенный в Backbone. Ну а так же покажу, как реализовать проверку на стороне сервера и отображение ответа на клиенте.

Теперь, что касается коллекций. Опять же, пример коллекции:

Предлагаю сразу разъяснить, что такое и чем отличаются коллекции и модели, чтобы не было путаницы. Особенное ,если Вы имели опыт работы с моделями в тех же «рельсах».  Модель — это единичная запись, а коллекция — это набор этих записей, моделей. Т.е. когда вы получаете или устанавливаете атрибуты какого-то объекта, например, имя пользователя или его электронный адрес, — это работа с моделью. А вот когда вы делаете запрос к серверу, получаете, а потом отображаете всех пользователей — это уже работа с коллекцией. Коллекция — это множество моделей. И коллекция работает с моделью, о чём и указывает свойство model: App.Models.Post. А так как коллекция работает тоже с данными на сервере, то и путь указывается такой же, что и в модели.

Вот и всё, что касается моделей и коллекций. Более тесно с ними познакомимся, когда коснёмся отображений(views), т.к. картинки строятся на основании данных, полученных с сервера, а так же при создании, изменении или удалении информации пользователем.

Не теряйтесь (-:

Вчера я в общих чертах описал процесс подключения Backbone.js в приложение на «рельсах». Кто не читал, тому рекомендую сначала бегло пробежать по той статье.

Сегодня расскажу о, пожалуй, самой важной части Backbone.js: о роутерах. Почему я считаю роутеры самыми важными? Всё просто: чтобы что-то увидеть в окне браузера, пользователь сначала должен набрать URL, кликнуть ссылку или что-то в этом духе. Так вот роутеры и решают, что и в какой момент времени показывать пользователю, в зависимости от URL-а. Они являются как бы связующей частью между пользователем и серверной частью приложения. Впрочем, ничего сверхъестественного.

В моём приложении всего один роутер, этого вполне достаточно, думаю, для большинства приложений. При желании, можно для каждой части приложения делать отдельный файл — это уже дело личных предпочтений.

Для начала давайте рассмотрим файл app/assets/javascripts/app.js.coffee:

Обращаю внимание, что моё приложение называется App. Запуск приложения - App.init() — происходит, когда уже DOM полностью загружен. Функция init() — это своего рода конструктор, если кто-то знаком с другими языками программирования. И она выполняет всего две, но очень важные функции:

1. new App.Routers.Posts() — инициализирует наши роутеры

2. Backbone.history.start() — запускает механизм сохранения истории нашего перемещения по приложению. Вы же хотите пользоваться кнопками «Вперёд» и «Назад» своего браузера? Вот это именно для этого.

Теперь перейдём непосредственно к роутерам. Все файлы, содержащие роуты, находятся в одной директории: app/assets/javascripts/routers/. У меня там всего один файл: posts.js.coffee. В данном файле находится всего один класс App.Routers.Posts, который наследуется от Backbone.Router. Собственно, сегодня я буду рассказывать в основном про этот класс.

Начинается этот класс с перечня роутеров, которые допустимы в нашем приложении:

Думаю те, кто привыкли работать с роутами в «рельсах», найдут много общего. Слева указывается часть URL-а, который в адресной строке, справа — функция, которая обрабатывает данный путь. Ничего сложного и необычного.

Далее следует функция конструктор для данного класса: она будет вызываться каждый раз, когда кто-то будет пытаться создать экземпляр данного класса:

Что же делает наш конструктор?? Первые две строчки аналогичны третьей и четвёртой, разница лишь в разных данных. Сначала мы инициализируем коллекцию

а после этого загружаем в коллекцию данные

Данный приём является примером хорошего тона, когда при загрузке и старте приложения не приходится делать ещё один или несколько запросов к серверу, чтобы получить данные. Кроме этого, не происходит задержки при отображении данных. Но позвольте, скажут некоторые, а откуда эти данные взялись на странице??? Ответ очень прост: стоит ознакомиться с содержимым файла app/views/main/index.html.erb. В самом конце есть две вот такие строчки:

В данном случае мы создаём два div-а, в которые в поле data осуществляем загрузку данных из наших таблиц на сервере. Таким образом, на момент отрисовки странички пользователю, приложение имеет уже некоторый первоначальный набор данных для отображения и манипуляций ими, без необходимости обращения к серверу. По-моему, очень даже симпатично.

Но вернёмся к нашему конструктору класса. Остались не рассмотренными ещё две строчки:

Данные строчки выполняют всего одну функцию: отображают на экране меню с левой стороны. Только и всего.

В принципе, большинство остальных функций в данном классе выполняют одно и то же действие:  формируют необходимую картинку на экране, в зависимости от URL-а. Рассмотрим на примере метода index.

Первые 4-ре строки — это не что иное, как украшательства: осуществляют подсветку необходимого пункта меня слева и вверху. Не более.

Следующая строка view = new App.Views.PostsIndex(collection: @collection)  осуществляет создание экземпляра view класса App.Views.PostsIndex, ответственного за отображение всех постов приложения. Почему всех? Да потому что в качестве аргумента передаётся коллекция, в которую были загружены все данные, полученные с сервера. Впрочем, об отображениях (views), мы поговорим в следующих постах.

Сейчас же стоит обратить внимание на функцию showView(), которая, собственно, и осуществляет вывод на экран. Вот что представляет из себя эта функция:

Может возникнуть резонный вопрос: а почему так сложно? почему бы просто не заменить содержимое элемента новым содержимым? В принципе, так можно, и так делают. Только вот есть одно «но»: как только Ваше приложение начнёт разрастаться, когда у него появится большое количество обработок действий пользователя(events), от тогда начнут возникать всякие неожиданные результаты — нажимаете одну кнопку, а действие происходит для других данных, появляются ошибки и всё такое. Чтобы этого не происходило, необходимо текущее отображение корректно закрыть, прекратить (unbind) действие всех ранее объявленных событий(events), а вот на его место уже отобразить новые данные.

Закрытие текущего представления(view) происходит при помощи функции close(), объявленной в самом начале файла:

О действии функций remove() и unbind() рекомендую ознакомиться на сайте jQuery.

Вот, в принципе, и всё о роутерах. Теперь Вы должны знать, как происходит процесс обработки и отображения данных, в зависимости от того, какой URL набран в адресной строке.

В следующий раз поговорим о моделях и коллекциях.