Как создать простой, расширяемый блог с помощью Elixir и Phoenix

kak sozdat prostoj rasshiryaemyj blog s pomoshhyu elixir i

автор Роман Сах

В этой публикации мы обсудим, как создать шаблонное веб-приложение Phoenix с проверкой подлинности пользователя и панелью администратора, а также загружать изображения в Elixir.

TodoMVC стал де-факто инструментом для сравнения различных фреймворков MV* на основе JavaScript. Так же я считаю, что приложение для блога может стать отличным фактором в выборе новой серверной части или фреймворка API.

Давайте начнем и построим его в Фениксе. Мы будем выполнять настройки по умолчанию, то есть Phoenix, подключенный к Ecto, работающий на PostgreSQL.

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

1*x59piiG96eAfObns-aPzvQ

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

1*mxWIdSAc-p9elJI3x2yQKw

У нас будет информационная панель, которая будет показывать краткую статистику. Для доступа к этой странице требуется вход пользователя администратора.

1*xwuFgK253CAjphO0IVu8Ow

Будет отдельный раздел с обзором всех публикаций. Здесь вы можете публиковать/изменять/удалять сообщения.

1*fkzXp5iJjFJPzyk-bu1NFg

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

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

Теперь сохраним название проекта как CMS. Итак, мы начнем с создания нового проекта с mix phx.new cms. Беги mix deps.get чтобы установить зависимости.

Создайте файл миграции для пользователей и сообщений соответственно.

# User migration file
mix phx.gen.schema Auth.User users name:string email:string password_hash:string is_admin:boolean
# Posts migration file
mix phx.gen.schema Content.Post posts title:string body:text published:boolean cover:string user_id:integer slug:string

В базе данных нужно сделать две таблицы, представляющие юзеров и сообщения. Я сделал это достаточно простым, сохраняя только необходимые поля и расширяя, когда возникает потребность.

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

user.ex

пост.пр

@derive {Phoenix.Param, key: :slug}

Поскольку мы хотим, чтобы сообщения имели читабельную и удобную для SEO структуру URL-адресов, мы сообщаем помощникам маршрутов, чтобы они ссылались slug вместо id в пространстве имен URL-адресов.

Маршруты описаны здесь:

Ресурсы, специфичные разделу администратора, объединяются вместе и назначается конвейер, который заставит аутентификацию.

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

Выполнение mix phx.routes дает мне этот выход:

1*C0G1-utBGFbtv8332dWFfA

Представление разделено на три логические части:

  1. Панель навигации
  2. Боковая панель
  3. Основное содержание

Хотя панель навигации всегда видна, боковая панель появляется только в том случае, если пользователь вошел в систему. Просмотр содержимого будет осуществляться внутри контекста администратора. Ссылки на боковой панели будут расти по мере развития программы.

1*UkNS-kHZ4Dpo9lgMpzqSdA

Контроллер Admin.Post следует типичной архитектуре CRUD и включает действие для переключения опубликованного состояния данной публикации.

1*xwuFgK253CAjphO0IVu8Ow

Многие элементы управления находятся на индексной странице раздела публикаций администратора. Здесь сообщения можно удалять, публиковать и изменять.

templates/admin/post/index.html.eex

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

views/admin/post_view.ex

Arc совместно с arc_ecto предоставляет готовые способности загрузки файлов. Поскольку сообщение содержит изображение обложки, мы должны определить конфигурацию дуги в нашем приложении.

Для каждой публикации в нашем блоге нужны две версии изображений обложки — оригинал, отображаемый внутри определенного вида публикации, и версия для большого пальца с меньшей площадью для заполнения карт. Теперь давайте использовать разрешение 250×250 для большой версии.

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

controllers/page_controller.ex

Этот проект исследует Phoenix как структурированная программа Phoenix и как разобрать проект на основе Phoenix. Надеюсь, вы чему-то научились и получили удовольствие!

Полная рабочая программа находится на Github: Вы можете клонировать? и хлопайте, если вы считаете этот блог полезным?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *