Глава 6 Моделирование и просмотр пользователей, часть I
Главу 5 мы закончили заглушкой страницы для создания новых пользователей (Раздел 5.3); в течение следующих трех глав мы выполним обещание, неявное в этой начинающейся странице регистрации. Первый важный шаг это создание модели данных для пользователей нашего сайта, вместе со способом хранить эти данные. Завершение этой задачи является целью для ближайших двух глав, и мы дадим пользователям возможность зарегистрироваться в системе в Главе 8. Как только пример приложения сможет создавать новых пользователей, мы позволим им входить и выходить (Глава 9), и в Главе 10 (Раздел 10.2) мы узнаем, как защитить страницы от несанкцонированного доступа.
Взятые вместе, материалы с Главы 6 по Главу 10 разрабатывают полную Rails систему входа и аутентификации. Как вы знаете, там, в стране Rails, есть различные готовые решения для аутентификации; Блок 6.1 объясняет, почему (по крайней мере, сначала) это - хорошая идея - прикрутить свою собственную.
Фактически все веб-приложения в настоящее время требуют какую либо систему входа и аутентификации. Неудивительно, что у большинства веб-платформ есть множество возможностей для реализации таких систем, и Rails не исключение. Примеры систем аутентификации и авторизации включают в себя Clearance, Authlogic, Devise, and CanCan (так же как не-Rails-специфичные решения, построенные на OpenID or OAuth). Разумно спросить, почему мы должны повторно изобретать колесо. Почему бы просто не использовать стандартное решение вместо того, чтобы прикручивать собственное?
Есть несколько причин, почему создание нашей собственной системы аутентификации является хорошей идеей. Во-первых, стандартного решения для аутентификации в Rails не существует; а привязав учебник к какому либо конкретному проекту мы рискуем тем, что, что выбранный проект может выйти из моды или устареть. Кроме того, даже если бы мы угадали, то кодовая база проекта продолжала бы развиваться, тем самым превращая учебник в устаревший хлам. Наконец, представление всей машинерии аутентификации сразу было бы педагогическим бедствием - к примеру, Clearance содержит более чем 1 000 строк кода и создает сложную модель данных с самого начала. Системы аутентификации - захватывающее и богатое программированием упражнение; прикручивание нашего собственного означает, что мы можем рассмотривать одну маленькую часть за один раз, что приведет к намного более глубокому пониманию - и аутентификации и Rails.
Я призываю Вас изучить 6 - 10 Главы чтобы дать себе хорошую основу для будущих проектов. Если Вам однажды случится использовать стандартную систему аутентификации для своих собственных приложений, то Вы будете в хорошей позиции чтобы понять и адаптировать его под Ваши потребности.
Параллельно с нашим моделированием данных мы также разработаем веб-страницу для того, чтобы показать пользователя, которая будет служить первым шагом к реализации архитектуры REST для пользователей (вкратце обсуждается в Разделе 2.2.2). Хотя мы не будем заходить так далеко в этой главе, наша конечная цель для страниц профиля пользователя состоит в том, чтобы показать аватар пользователя, основные данные пользователя, и список микросообщений, как на макете в Рис. 6.1.1 (в Рис. 6.1 есть наш первый пример lorem ipsum текста, который имеет захватывающую историю и ее определенно стоит прочитать в свободное время.) В этой главе, мы положим начало странице, показывающей пользователя, и мы начнем заполнять ее деталями, начиная с Главы 7.
Как обычно, если Вы продолжаете использовать Git для управления версиями, сейчас было бы хорошее время, чтобы сделать отдельную тему ветки для моделировния пользователей:
$ git checkout master
$ git checkout -b modeling-users
(Первая строка здесь только для того чтобы удостовериться, что Вы находитесь на master ветке, чтобы тема ветки modeling-users была основана на master ветке. Можно пропустить эту команду, если Вы уже находитесь на master ветке.)
# coding: utf-8
