Skip to content

Instantly share code, notes, and snippets.

@psylone

psylone/lesson-12.md

Last active November 10, 2016 17:12
Show Gist options
  • Save psylone/2a3a724ae4fbdd6eba9462cabbbea533 to your computer and use it in GitHub Desktop.
Save psylone/2a3a724ae4fbdd6eba9462cabbbea533 to your computer and use it in GitHub Desktop.
Download ZIP
Задания к занятию 12
Raw
lesson-12.md

Задания к занятию 12

  • Модели в Rails приложении
  • Обратные вызовы (Callbacks)
  • Миграции

Ссылки на документацию

Active Record Migrations

Миграции - это компонент Rails для изменения схемы базы данных.

CommandRecorder

Каждая мигарция представляет собой Ruby класс в котором определён метод change или методы up и down. Метод change используется в том случае когда Rails может самостоятельно вывести обратное действие. Например при добавлении новой колонки в таблицу метод add_column можно использовать внутри метода change. Rails самостоятельно поймёт что при откате миграции колонку нужно удалить. Доступные методы для использования внутри change указаны в документации:

Callbacks

Обратные вызовы - это методы которые вызываются автоматически при наступлении определённого события в жизненном цикле объекта.

Модели в Rails приложении

Нам понадобится новая модель для представления сущности задачи. Давайте ещё раз пройдёмся по пути от анализа предметной области до создания файла в Rails приложении.

Итак, у пользователя есть задачи. Понятно что можно представить задачу в виде существующих типов данных в Ruby, например, в виде хэша (ключ - название задачи, значение - её прогресс) или просто в виде строки. Но нам, очевидно, потребуется дополнительное поведение для этой сущности. Например, метод для увеличения прогресса задачи, метод для проверки установлена ли задача в контекст (то есть да над которой мы сейчас работаем) и ещё многое. Это приводит нас к мысли о создании нового типа данных - класса Task.

Следующий вопрос на который мы должны ответить, как этот новый класс размещается в нашем Rails приложении. Явно это не контроллер, потому что класс Task представляет сущность реального мира, описывает состояние (хранит данные) этой сущности и также описывает поведение (методы) сущности. Это конечно же не представление и также не похоже на сервис или презентер (ещё будем о них говорить). Таким образом, приходим к пониманию что этот класс разумно считать Моделью.

1. Новая модель Task

С помощью генератора Rails создайте новую модель Task. Предусмотрите поля:

  • progress для хранения прогресса задачи

  • content для хранения содержания задачи

  • completed признак того является ли задача завершённой

  • current признак того находится ли задача в контексте

2. Модуль аутентификации User::Authentication

Мы написали коллбэк и метод для генерации hashed_password. Однако сейчас этот код находится в модели User. По сути, это самостоятельный фрагмент функциональности который удобно поместить в отдельный модуль.

Создайте модуль User::Authentication в файле /app/models/user/authentication.rb и переместите туда код связанный с аутентификацией, включая коллбэк.

Напишите метод User.authenticate который принимает email пользователя и пароль. Если данные верны, возвращается объект пользователя, если нет - возвращается nil. Метод должен находится в модуле User::Authentication.

3. Имя по умолчанию

Если при создании пользователя значение для поля name не было указано, определите обратный вызов который будет устанавливать это поле в значение по умолчанию. Значение по умолчанию можно сгенерировать с помощью Gem-а Faker.

Контакты для связи

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment