Проект: Ассоциации Active Record

Не забывайте использовать Git для фиксации изменений в ваших проектах!

В этом проекте вы наконец погрузитесь в работу с ассоциациями - одну из лучших особенностей, предоставляемых вам ActiveRecord. Руководствуясь Ruby on Rails Tutorial, вы создадите микросообщения для ваших пользователей, а второй проект предоставит возможность добавить некоторые интересные ассоциации в ваши предыдущие наработки.

Подготовка: Сперва обдумай данные

Спроектируйте архитектуру хранения данных, которая потребуется вам для реализации следующих сценариев:

1. Сайт услуг по уходу за питомцами (найм людей для присмотра за животными, пока их хозяева в отъезде). Люди могу брать на попечение несколько питомцев, питомцы могут иметь множество "сиделок".
2. Вы любите принимать гостей и хотите создать сайт для приглашения на званый ужин. Пользователь может создавать события, приглашать людей на события и принимать приглашения на чьи-то события.
3. Дополнительное (усложненное) задание: вы и ваши друзья любите постить разный контент и следить за активностью друг друга. Как вы настроите модели, чтобы пользователь мог подписываться на другого пользователя?

Проект 1: Ruby on Rails Tutorial

Эта глава руководства начинает тяжелый подъем по кривой обучаемости. Для начинающих, пытающихся пройти руководство, это начало фазы "Я выполняю действия, но не понимаю их". К счастью, вы уже выучили все, что будет освещено в руководстве, и это будет отличной возможностью опробовать в действии ваши знания.

Основной сутью является то, что для создания сервиса микросообщений вроде Twitter, вам действительно потребуются микросообщения. Пользователь создает микросообщения, так что можете с уверенностью полагать, что модель пользователя (User) будет иметь ассоциацию has_many с микросообщениями. Как только ассоциация установлена, остается только создать корректные вьюхи (представления) для отображения микросообщений.

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

Ваша задача

• Пройдите главу 11 Ruby on Rails Tutorial, "Слежение за сообщениями пользователей".

Проект 2: Частные события

Вы хотите создать сайт вроде частного(закрытого) Eventbrite, который позволяет создавать события и затем управлять приглашениями пользователей. Пользователь может создавать события и посылать приглашения на вечеринки (звучит знакомо?) События проходят в указанных дате и локации (последнюю вы можете хранить как простую строку, вроде "Дом Андрея").

Пользователь может создавать события. Пользователь может посещать множество событий. Это потребует от вас смоделировать отношение "многие-ко-многим", а также понимать какие внешние ключи и имена классов использовать (подсказка: вы не сможете просто положиться на стандартные установки Rails, как вы делали раньше).

Ваша задача

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

Предустановка и аутентификация

1. Смоделируйте структуры данных для вашего приложения, включая необходимые таблицы.
2. Создайте новое Rails-приложение и Git-репозиторий с именем private-events.
3. Заполните ваш README-файл подробным описанием и добавьте ссылку на этот ресурс.
4. Создайте и выполните миграции для модели пользователя (User). На заморачивайтесь с валидациями.
5. Создайте простой контроллер пользователей и соответствующие маршруты для действий #new, #create и #show. Вам понадобится создать форму, где новый пользователь может зарегистрироваться, и элементарную #show-страничку. Вы должны становиться эффективнее в создании стандартных контроллеров/форм/вьюх.
6. Создайте простую функцию аутентификации, которая не требует пароля - достаточно простого ввода идентификатора или имени пользователя, под которым вы хотите войти на сайт, и нажатия кнопки "Войти". Затем вы можете сохранить идентификатор "залогиненного" пользователя в хэше сессии (session) или куков (cookies), и использовать его при необходимости. Может оказаться полезным всегда отображать имя "залогиненного" пользователя где-нибудь в шапке сайта.

Основа событий

1. Создайте и выполните миграции для модели событий (Event) без использования внешних ключей. Не заморачивайтесь с валидациями. Добавьте поле "Дата" к вашей модели, но пока не беспокойтесь насчет дополнительного функционала.
2. Добавьте ассоциацию между создателем события (пользователем) и самим событием. Назовите этого пользователя "создателем" ("creator"). Добавьте внешний ключ в модель события (Event). Вам потребуется тщательно указать свойства ассоциации (такие как :foreign_key, :class_name и :source).
3. Доработайте Show-страницу пользователя, добавив туда список всех событий, которые создал пользователь.
4. Создайте EventsController и соответствующие маршруты, чтобы позволить вам создавать события (не беспокойтесь насчет редактирования и удаления событий), просматривать конкретное событие и список всех событий.
5. Форма создания события должна содержать только поле :description (описание).
6. Действие #create должно использовать метод #build на ассоциации для создания нового события с предустановленным идентификатором пользователя. Вы также с легкостью можете использовать метод модели события ::new и вручную задавать идентификатор пользователя... но не делайте так.
7. Страница события Show пока должна просто отображать создателя события.
8. Создайте страницу событий Index для отображения всех событий.

Участие в событиях

1. Теперь добавьте ассоциацию между участником события (пользователем) и самим событием. Назовите этого пользователя "участником" ("attendee"). Событие назовите "посещаемое_событие" ("attended_event"). Вам снова понадобится "поколдовать" с нестандартными именами внешних ключей, классов и источников данных.
2. Создайте и выполните миграции всех необходимых таблиц и внешних ключей. Для этого потребуется "сквозная" таблица, так как событие (Event) может иметь множество участников (Attendees), а один пользователь (Attendee) может участвовать в нескольких событиях (Events)... "многие-ко-многим".
3. Теперь сделайте, чтобы страница события Show отображала список участников.
4. Сделайте, чтобы страница Show пользователя отображала список событий, в которых он принимает участие.
5. Доработайте страницу пользователя Show так, чтобы прошедшие события ("Ранее посещенные события") были отделены от тех, что будут проходить в будущем ("Предстоящие события"). Вы можете сделать это, поместив логику в вашу вьюху. Но этого делать не следует. Сделайте получение этих видов событий с помощью вызова отдельных методов модели в вашем контроллере, например @upcoming_events = current_user.upcoming_events и @prev_events = current_user.previous_events. Заодно вы получите некий опыт работы с датами и с построением запросов.
6. Доработайте Index-страницу событий, разбив список всех событий на категории "прошедшие" и "предстоящие". Используйте метод класса событий (например Event.past).
7. Выполните рефакторинг методов получения прошедших и предстоящих событий, преобразовав их в простые скоупы (вы ведь помните, что это?).
8. Поместите ссылки навигации в шапку, чтобы было легче "путешествовать" по сайту.
9. Дополнительное задание: дайте пользователям возможность приглашать других пользователей на события. Добавьте ограничение - возможность посещать событие только приглашенным пользователям.
10. Отправьте ваш проект на Github.

Решения студентов

• Решение 1 | Просмотреть в браузере
• Решение 2
• Решение 3
• Решение 4 | Просмотреть в браузере
• Решение 5
• Решение 6
• Решение 7
• Решение 8
• Решение 9
• Решение 10 | Просмотреть в браузере
• Решение 11
• Решение 12
• Решение 13 | Просмотреть в браузере
• Решение 14 | Просмотреть в браузере
• Решение 15 | Просмотреть в браузере
• Решение 16 | Просмотреть в браузере

Дополнительные ресурсы

Этот раздел содержит полезные ссылки на дополнительные материалы. Они не обязательны, так что расценивайте их как нечто полезное, если вы хотите поглубже погрузиться в тему

• Интерфейс запросов Active Record