53
Рисунок 15. Адаптивная верстка, экран «планшет»
Как видно на изображении, относительно экрана «десктоп», произошли
следующие изменения: верхнее меню навигации из открытого доступа скрыто
под кнопкой (зеленая кнопка в правом углу header). Бывшая боковая колонка
«Ассортимент» с выбором категории продуктов теперь расположена центрально
для обеспечения более удобного нажатия на разделы. Карточки с продуктами
располагаются ниже, по две в ряд.
При просмотре той же страницы со смартфона в верстке происходят новые
изменения, позволяющие пользователю более удобно рассматривать товар.
Поскольку экран смартфона довольно мал, то карточки товаров располагаются
уже по одной в ряд (рисунок 16).
54
Рисунок 16. Адаптивная верстка, экран смартфона
Адаптивная верстка сайта возможна благодаря сетке Bootstrap и медиа-
запросам. Bootstrap помогает автоматизировать процесс разметки web-страницы,
используя в файлах определенные в классы разметки, работающие по уже
созданным правилам. Например, для использования сетки Bootstrap в шаблоне,
отвечающем за вывод продукции на экран, тэгам div заданы соответствующие
классы <div class="col-xs-10 col-xs-offset-1 col-sm-6 col-sm-offset-0">, стили же
для этих классов прописаны в файле main.css.
3.3 Разработка базы данных
База данных интернет-магазина представляет собой совокупность
связанных данных конкретной предметной области.
Сущностью будем называть любой значимый объект, который может быть
представлен в базе данных. Между сущностями в базе данных присутствуют
связи. В реляционных базах данных сущности и связи между ними отражаются
с помощью таблиц.
55
Атрибут сущности - это именованная характеристика, являющаяся некоторым
свойством сущности. [16] Например, сущность «Покупатель» в базе данных
интернет-магазина TheCake имеет следующие атрибуты: имя, фамилия, телефон,
дата рождения и некоторые другие.
Для того, чтобы определиться с набором необходимых сущностей, нужно
понять, какие задачи должен выполнять интернет-магазин. В нашем случае это:
отображение продукции
фильтрация продукции по категориям
отображение корзины покупок
оформление заказа
регистрация пользователей
сохранение сообщений обратной связи от пользователей
возможность загрузки изображений товаров в административной части
интернет-магазина
возможность изменения общих настроек из административной части
интернет-магазина.
Данные задачи находят отражение в создаваемых сущностях. База данных
интернет-магазина TheCake включает десять таблиц.
Рассмотрим их подробнее.
Таблица products
Одна из важнейших таблиц интернет-магазина — таблица products. Ее структура
представлена на рисунке 17.
Рисунок 17. Структура таблицы products
56
Поля таблицы: уникальный идентификатор id (который также принято называть
primary key), название, слаг, описание, изображение продукта, внешний ключ
category_id, цена и так называемые timestamps: created_at, updated_at, deleted_at
(даты создания, обновления и удаления). Особо стоит отметить наличие поля
deleted_at - данное поле отвечает за так называемое «мягкое удаление». По
умолчанию ему присвоено значение null, однако при удалении записи ему
присвоится дата удаления записи. Сама же запись при этом останется в базе
данных, однако будет неактивна. Тем не менее, так способ удаления записей
предотвращает необратимую потерю данных, что особенно ценно при
ошибочном или злоумышленном удалении.
Таблица categories
Структура таблицы categories довольна проста. Она состоит из уникального
идентификатора id, названия (которое должно быть уникально для каждой
записи, о чем нам говорит слово unique), слага и timestamps.
Таблица users
Таблица users также является одной из ключевых для интернет-магазина. Ее
структура представлена на рисунке 18.
Рисунок 18. Структура таблицы users
Таблица users включает уникальный id, имя пользователя, email пользователя
(должен быть уникальным), пароль (хранится в зашифрованном виде). Поле
remember_token хранит токен, который создается при выборе пользователем
функции «Запомнить меня», позволяющей не вводить каждый раз при входе
57
логин и пароль. Далее идут стандартные timestamps, поле «статус пользователя»
и два не встречавшихся ранее поля can_manage_sales и can_manage_users. Эти
атрибуты ответственны за привилегии пользователя на сайте. Обычные
пользователи имеют в данных полях значение «0», означающее, что простой
пользователь не имеет прав на управление торговыми операциями и управление
пользователями. Управлять торговыми операциями (can_manage_sales) могут
пользователи, имеющие статус «менеджер» или «админ». Привилегия
управления пользователями (can_manage_users) доступна только
администратору интернет-магазина.
Таблица customers
Таблица customers является дополнением к таблице users и содержит
дополнительную информацию о покупателях. Между данными двумя таблицами
имеется смысловое разделение: пользователем (user) является любой
зарегистрированный посетитель, а покупателем (customer) только тот, кто сделал
хотя бы один заказ. По этой причине таблица customers содержит такую
информацию, как имя, фамилия покупателя, дата рождения, телефон, а также
внешний ключ user_id, связующий данную таблицу с таблицей users.
Таблица orders
Таблица orders (заказы) служит для хранения информации о заказах. Содержит
уникальный id, внешний ключ customer_id, связующий ее с таблицей customers,
поле «сумма заказа», дату и адрес доставки, три статусных поля is_paid
(«оплачен?»), is_shipped («доставлен?»), is_active («активен?») и стандартные
timestamps.
Таблица order_product
Данная таблица реализует связь «многие-ко-многим» между заказами и
продуктами. Состоит она всего из трех полей: order_id, product_id, quantity
(количество единиц конкретного товара в заказе). Именно наличие данной
связующей таблицы позволяет не хранить данные о заказанных товарах в
таблице orders.
Таблица messages
58
Содержит информацию об оставленных на сайте сообщениях обратной связи:
имя и e-mail отправителя, текст сообщения, стандартные timestamps.
Таблица uploads
Данная таблица хранит информацию о загружаемых на сайт файлах. Речь,
прежде всего, об изображениях товаров. Таблица uploads включает следующие
поля: путь к файлу, его размер, расширение, mime-тип, старое имя и стандартные
timestamps.
Таблица settings
Данная таблица содержит общую информацию об интернет-магазине, в
частности, такие данные как название сайта, название компании, адрес, телефон,
e-mail, e-mail менеджера.
В описании таблиц неоднократно упоминались связи между ними. Фреймворк
Laravel позволяет прописывать связи между сущностями на уровне моделей. На
рисунке 19 мы видим реализацию модели Order (Заказ). Метод customer()
отвечает за реализацию связи «один-ко-многим» между сущностями Customer и
Order. Метод products() обеспечивает связь «многие-ко-многим» между
таблицами Orders и Products.
Рисунок 19. Реализация связей между сущностями
Аналогичным образом прописаны необходимые связи и между другими
таблицами.
59
3.4 Программирование, тестирование, перенос на хостинг
Весь процесс разработки производился с активным использованием
официальной документации Laravel.
Установка фреймворка Laravel была выполнена при помощи composer. В
консоли, перейдя в нужную директорию, вводится команда «composer create-
project --prefer-dist laravel/laravel laravel.local». Laravel.local в данной команде —
это название проекта.
После установки фреймворка прописываем в файле .env данные для
подключения к базе данных.
Следующий шаг - формирование маршрутов. Файлы настройки маршрутов
хранятся в папке routes корневого каталога. На рисунке 20 представлен фрагмент
кода с маршрутами. На данном рисунке прописаны маршруты для работы с
продуктами, корзиной, заказами, а также маршруты для осуществления входа и
выхода. Все указанные маршруты относятся к клиентской части интернет-
магазина. Маршруты, работающие на административной части, сгруппированы
в файле admin.php (в папке routes).
Рисунок 20. Маршрутизация
60
Работу с роутами можно детальнее рассмотреть на примере маршрута для входа
на сайт (строка 50 на рисунке 20):
Route::get('/login', 'LoginController@showLoginForm')
→name('login');
Эта запись означает следующее: при поступлении GET-запроса по адресу
site.ru/login - обработку данного запроса выполнит контроллер LoginController, а
конкретно — его метод showLoginForm, ответственный за показ пользователю
формы для введения логина и пароля.
Следующий этап разработки — написание контроллеров. Именно они
отвечают за основную работу с пользователем. Контроллеры хранятся в папке
app\Http\Controllers. Для удобства некоторые контроллеры сгруппированы по
смысловым подпапкам, например, контроллеры, отвечающие за
функционирование административной части, собраны в папке
app\Http\Controllers\Admin, а те, что отвечают за работу личного кабинета - в
папке app\Http\Controllers\Cabinet.
Рассмотрим подробнее реализацию контроллеров на примере
ProductController, отвечающего за работу с продуктами на клиентской части
интернет-магазина TheCake. Часть кода данного контроллера представлена на
рисунке 21.
Код контроллера начинается с указания пространства имен (namespace) и
подключения необходимых моделей, фасадов и библиотек при помощи
директивы use.
Далее следует название класса и указание на родительский контроллер
Controller. Внутри класса прописаны методы. В данном фрагменте представлены
два метода: метод index() и метод byCategory($slug).
61
Рисунок 21. Контроллер ProductController
Метод index() обеспечивает вывод всех продуктов на странице
«Ассортимент». В данном методе прописано соединение с таблицей products
базы данных и выбор из нее продуктов, соответствующих условию:
where('is_active', '1'). Данное условие позволяет выбрать только активные
продукты, то есть те, которые в данный момент можно заказать. Далее прописано
правило для пагинации (simplePaginate(6)), которое обеспечивает постраничный
вывод на странице шести карточек продуктов.
В 19-ой строке кода идет обращение к таблице categories и получение из
нее всех доступных категорий. Эти данные потребуются для вывода списка
категорий в боковом меню.
Метод index() возвращает шаблон представления, передавая в него
необходимые переменные.
Второй метод контроллера ProductController (метод byCategory($slug))
выполняет функцию фильтрации продуктов по категории и отрабатывает в тот
62
момент, когда пользователь выбирает в боковом меню нужную ему категорию
продукции.
Следующим этапом разработки было внедрение валидации и
аутентификации. Внедрение валидации уже было рассмотрено выше, в разделе
3.1.1, на примере валидации пользовательского ввода в форме регистрации. Что
же касается аутентификации (то есть процедуры проверки корректности логина
и пароля пользователя), то данная процедура была реализована при помощи
встроенной функции Laravel. Ниже представлен фрагмент кода контроллера
LoginController, отвечающего за аутентификацию:
if (Auth::attempt($credentials, $remember)) {
if ($routeUri == 'admin/login' && ($request->email == 'adm@mail.ru')) {
return redirect()->route('admin.welcome')->withInput();
}
if (Auth::user()->status != 0) {
return redirect()->intended();
}
}
return back()->withErrors(['Ошибка авторизации'])→withInput();
Auth::attempt — функция Laravel, проверяющая соответствие хэша
введенного пользователем пароля с захэшированным паролем этого
пользователя, хранящимся в базе данных. Если эти два хэша совпадут, то для
пользователя создается новая аутентифицированная сессия. Далее происходит
проверка, не является ли пользователь администратором и в случае
положительного ответа, администратор попадает в админку. И последняя
проверка условия — это проверка статуса пользователя. Если статус не равен
нулю, то пользователь успешно переходит на нужную страницу; в противном
случае пользователь перенаправляется вновь на страницу ввода логина и пароля,
и ему выдается сообщение «Ошибка авторизации», поскольку статус «0» у
пользователя означает то, что он забанен.