
Цикл материалов «Создание блога на PHP»
Первая лекция – вступительная. Практических примеров и задач будет минимум, мы поговорим о более абстрактных вещах. Но уже на втором уроке мы перейдём к практических задачам.
Почему мы выбрали именно блог?Блог – наиболее популярный формат сайта. Если вы научитесь создавать с нуля блог, без проблем можно расширить свои умения и на интернет-магазин и на порталы побольше.
Формат блога очень популярен. Кроме того, если вы научитесь создавать с нуля блог, без проблем можно расширить свои умения и на интернет-магазин и на порталы побольше.
Наши рамкиМы используем PHP, MySQL и не используем фреймворки. Веб-сервер у вас уже настроен.
Создание блога – нетривиальная задача (если, конечно, не рассматривать готовые платформы типа LiveJournal или Blogger). Вариантов её реализации – тысячи и нам необходимо определить рамки задачи:
- Мы используем PHP. Есть много других языков и платформ для бекенда, использование любого из них – дело вкуса. Мы будем говорить о чистом PHP и о паттернах программирования. Будем считать, что базовые знания по PHP у вас есть.
- Мы используем MySQL. В качестве БД можно использовать и другие СУБД, но мы будем использовать MySQL как самую популярную. В будущем можно будет подключить Memcached.
- Мы не используем готовые CMS. Поскольку наша цель – подтянуть PHP и изучить архитектуру блога, мы не будем использовать готовые CMS, ведь в большинстве случаев разработка блога на CMS – это всё-таки вёрстка и настройка блога в административной панели.
- Мы не используем фреймворки. Фреймворки – это хорошо, классно и правильно, но, опять же, цель нашего урока – глубже изучить PHP, а фреймворки дают некоторый уровень абстракции и отдаляют нас от тех поучительных граблей и тумаков.
- Будем считать, что веб-сервер у вас уже настроен.
С рамками определились, продолжаем.
Что нужно знать для того, чтобы создать блог на PHP с нуля?
В данном цикле статей я буду рассказывать об архитектуре, местами я расскажу о нюансах того или иного подхода, но для начала у вас уже должны быть знания следующих языков программирования / технологий:
- PHP – будет использоваться в качестве языка бекенда.
- MySQL – будем использовать в качестве хранилища.
- HTML + CSS – базовые знания.
- JavaScript – необязательно, но желательно.
Желательно также уметь хорошо и красиво верстать, ну и чувство вкуса тоже не помешает.
Что мы ожидаем от блога? Что в блоге должно быть?
Блоги бывают разные – простые, сложные, различной тематики, личные и корпоративные, с различными типами записей и т.д. Базовый функционал блога включает в себя определённые страницы:
- Главная страница – обычно простая лента новостей. Возможно наличие специфических блоков (обо мне и т.д.).
- Страница категории – также лента новостей, иногда есть необходимость её стилизовать, продвигать по определённым запросам в соц. сетях.
- Пост (страница записи). Может быть и очень сложной и довольно простой. На странице поста находятся:
- Текст статьи, форматирование, изображения, цитаты и т.д.
- Информация – дата поста, кол-во просмотров и комментариев.
- Блок с комментариями, форма для комментария.
- Кнопки «поделиться»
- Связанные статьи (похожие статьи)
- Метки (теги)
- Страница тега. (просмотр записей по тегу)
- Поиск по блогу –
- Карта сайта –
Как видите, ничего сложного.
Что такое осень блог?Блог (да и вообще любой сайт) можно представить в виде страниц, функциональных блоков на этих страницах.
Эти все страницы должны взаимодействовать. Различные модули:
- Последние комментарии
- Модуль поиска
- Модуль входа на сайт
- Модули меню
- Рекомендуем почитать
- Вставка произвольного HTML блока (виджет группы в соц. сети и т.д.)
Каким блог должен быть структурно?
Я расскажу на примере своего блога, вы же можете идти другим путём. На каждой странице расположены различные блоки, нам потребуется. Каждый блок (компонент).
Роутер, система взаимодействия. Примеры.
Паттерны программирования. MVC и Singleton
Когда-то давно программистов было мало и каждый программист по куче раз наступал на грабли, изобретал свои велосипеды и писал свои костыли. Потом, когда программистов стало много и они устали изобретать велосипеды, какие-то программисты поняли что часто код структурно можно объединить в группы, такие себе «шаблончики проектирования». Такие вот структурные шаблоны и называются паттерны программирования. В сегодняшней статье мы рассмотрим паттерны MVC, и Singleton.
Паттерн Singleton
Singleton – это.
Паттерн MVC
MVC – это аббревиатура Model-View-Controller. Каждый компонент (визуально – блок) на сайте мы представляем в следующем виде.
При этом Модель определяет работу с данными.
Часто можно комбинировать различные модели и view. Например:
- Боковые блоки (разные модели, один view);
- Блог и список материалов (Одна модель, разные View).
Почему MVC? Расширяемость, гибкость, .
Приметы использования.
Структура
Получение данных выносим в ещё один абстрактный слой – библиотеки. Это бывает полезно когда у нас есть админка. Тогда нам не приходится по нескольку раз заниматься выборками из базы, кешированием и прочими вещами в каждой модели.
- Libraries – папка с библиотеками;
- Components – папка с компонентами;
- Templates – папка с шаблонами.
Итог
Домашнее задание:
- Разобраться в паттернах программирования MVC и Singleton.
- Попробовать рассмотреть структуру работы популярных CMS.
- Попробовать сделать набросок своей CMS (скачать набросок CMS от konservs.com).
На следующем занятии мы изучим:
- Отладка и логирование в CMS.
- Язык SQL. Работа с MySQL.
- Написание Singleton класса для MySQL и выполнение простых запросов.
Оглавление уроков
Ну, и напоследок, краткое оглавление уроков:
- Урок 1. Вступительный.
- Урок 2. Логирование на сайте. Язык SQL.
- Урок 3. Фабрика, кеширование.
- Сессии. Вход и регистрация.
- Поиск.
Поздравляю всех, кто осилил такой большой урок. До встречи!
Комментарии
вообще вот связка понятий одной CMS, описанной на сайте и остальных фреймвоков то будет:
CMS Фреймворки
libraries model
view view
model функция в controller
а еще! Всеми считается что ответ(как и 404) обязан отдавать контроллер, а не роутер.
и еще окошко для написания коммента хотелось чуть побольше
Но никто же не мешает нам в модели получать данные из библиотек
Библиотеки помогают нам использовать одни и те же данные в разных моделях.
Хотя суть, в принципе, ясна - можно в моделях подгружать другие модели, так ведь?
По поводу контроллера не понял. Он у нас и так может вернуть 404 или 403, который потом (всё равно через роутер или, допустим, назовём этот класс BApplication) вернётся пользователю как код ответа.
Вся суть - в том, чтобы разделить блоки на сайте в отдельные MVC-структурки, ответы которых потом можно удобно обрабатывать.
P.S. Готов обсудить любые улучшения, ведь это принесёт пользу всем.
Суть в том что у нас есть модель статьи. Она ответственна за всю работу с данными.
а контроллер выглядит так
Class BlogController{
function actionSingleArticle(){
$id=Request::get('id');
$data['article']=ArticleModel::getWithId($id);
return $viewSingleArticle->show($data);
}
function actionBlogArticles(){
$blogid=Request::get('blogid');
$data['articles']=ArticlesModel::getFromCat($blogid);
$data['cat']=CategoryModel::getWithId($blogid);
$return $viewBlogArticle->show($data);
}
}
То есть все что связано с пользователем(даже получение $_GET) должно идти в контроллере, модель вообще не должна знать и существовании пользователя.
А в чём плюс?
И можно ли рассматривать вариант изолированной админки? Например, когда в админке свои компоненты и шаблоны. Типа как в Joomla.
P.S. Когда разрабатывал архитектуру - ориентировался в том числе и на статью https://habrahabr.ru/post/175465/. Цитирую: В рамках этой концепции считается, что по мере возможности логику приложения (вроде бизнес-логики из примера выше) лучше всего помещать в модель, а не контроллер или представление.
В моём случае логика работы (проверка доступов и т.п.) помещается в модель, а библиотеки служат для универсальной работы с "сырыми" данными.
а большинство наших "моделей" на само деле заключаются только лишь в получении данных из базы, что вполне логично было бы навесить как функцию контроллера и не создавать целую модуль
Изолированная админка - пожалуйста. ты просто делаешь новый изолированный контроллер, который может взаимодействовать с библиотеками и все. админка готова
Модель никогда не должна знать ничего о внешнем воздействии. Проверку доступов нужно либо помещать в контроллер, либо обезличенно проверять в библиотеке
Плюс такого способа - отсутствие большого количества файлов в которых функционального смысла по 2 строки
Например, несколько моделей в 2 строки могут давать определённые "порции данных" - одни больше данных, другие - меньше. И для разных моделей мы разграничиваем доступ. А библиотека используется одна.
А если бы всё это оперировалось только в моделях - пришлось бы "костылить", наверное. Была бы "крутая" модель, которая оперирует наборами сущностей, и модели попроще, которые используют "крутую" модель. По сути то же самое, только всё на одном уровне.
Adding comments is temporarily disabled for unregistered users.