Создание блога на PHP. Урок 1. Вступительный.

Создание блога на PHP. Урок 1. Вступительный.Создание блога на PHP. Урок 1. Вступительный.

Цикл материалов «Создание блога на PHP»

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

Почему мы выбрали именно блог?Блог – наиболее популярный формат сайта. Если вы научитесь создавать с нуля блог, без проблем можно расширить свои умения и на интернет-магазин и на порталы побольше.

Формат блога очень популярен. Кроме того, если вы научитесь создавать с нуля блог, без проблем можно расширить свои умения и на интернет-магазин и на порталы побольше.

Наши рамкиМы используем PHP, MySQL и не используем фреймворки. Веб-сервер у вас уже настроен.

Создание блога – нетривиальная задача (если, конечно, не рассматривать готовые платформы типа LiveJournal или Blogger). Вариантов её реализации – тысячи и нам необходимо определить рамки задачи:

  1. Мы используем PHP. Есть много других языков и платформ для бекенда, использование любого из них – дело вкуса. Мы будем говорить о чистом PHP и о паттернах программирования. Будем считать, что базовые знания по PHP у вас есть.
  2. Мы используем MySQL. В качестве БД можно использовать и другие СУБД, но мы будем использовать MySQL как самую популярную. В будущем можно будет подключить Memcached.
  3. Мы не используем готовые CMS. Поскольку наша цель – подтянуть PHP и изучить архитектуру блога, мы не будем использовать готовые CMS, ведь в большинстве случаев разработка блога на CMS – это всё-таки вёрстка и настройка блога в административной панели.
  4. Мы не используем фреймворки. Фреймворки – это хорошо, классно и правильно, но, опять же, цель нашего урока – глубже изучить PHP, а фреймворки дают некоторый уровень абстракции и отдаляют нас от тех поучительных граблей и тумаков.
  5. Будем считать, что веб-сервер у вас уже настроен.

С рамками определились, продолжаем.

Что нужно знать для того, чтобы создать блог на PHP с нуля?

Полный стек технологий

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

  1. PHP – будет использоваться в качестве языка бекенда.
  2. MySQL – будем использовать в качестве хранилища.
  3. HTML + CSS – базовые знания.
  4. JavaScript – необязательно, но желательно.

Желательно также уметь хорошо и красиво верстать, ну и чувство вкуса тоже не помешает.

Что мы ожидаем от блога? Что в блоге должно быть?

Структурно блог - это...

Блоги бывают разные – простые, сложные, различной тематики, личные и корпоративные, с различными типами записей и т.д. Базовый функционал блога включает в себя определённые страницы:

  1. Главная страница – обычно простая лента новостей. Возможно наличие специфических блоков (обо мне и т.д.).
  2. Страница категории – также лента новостей, иногда есть необходимость её стилизовать, продвигать по определённым запросам в соц. сетях.
  3. Пост (страница записи). Может быть и очень сложной и довольно простой. На странице поста находятся:
    • Текст статьи, форматирование, изображения, цитаты и т.д.
    • Информация – дата поста, кол-во просмотров и комментариев.
    • Блок с комментариями, форма для комментария.
    • Кнопки «поделиться»
    • Связанные статьи (похожие статьи)
    • Метки (теги)
  4. Страница тега. (просмотр записей по тегу)
  5. Поиск по блогу
  6. Карта сайта

Как видите, ничего сложного.

Что такое осень блог?Блог (да и вообще любой сайт) можно представить в виде страниц, функциональных блоков на этих страницах.

Эти все страницы должны взаимодействовать. Различные модули:

  1. Последние комментарии
  2. Модуль поиска
  3. Модуль входа на сайт
  4. Модули меню
  5. Рекомендуем почитать
  6. Вставка произвольного HTML блока (виджет группы в соц. сети и т.д.)

Каким блог должен быть структурно?

Я расскажу на примере своего блога, вы же можете идти другим путём. На каждой странице расположены различные блоки, нам потребуется. Каждый блок (компонент).

Роутер, система взаимодействия. Примеры.

Паттерны программирования. MVC и Singleton

Когда-то давно программистов было мало и каждый программист по куче раз наступал на грабли, изобретал свои велосипеды и писал свои костыли. Потом, когда программистов стало много и они устали изобретать велосипеды, какие-то программисты поняли что часто код структурно можно объединить в группы, такие себе «шаблончики проектирования». Такие вот структурные шаблоны и называются паттерны программирования. В сегодняшней статье мы рассмотрим паттерны MVC, и Singleton.

Паттерн Singleton

Singleton – это.

Паттерн MVC

Структура MVC

MVC – это аббревиатура Model-View-Controller. Каждый компонент (визуально – блок) на сайте мы представляем в следующем виде.

При этом Модель определяет работу с данными.

Часто можно комбинировать различные модели и view. Например:

  • Боковые блоки (разные модели, один view);
  • Блог и список материалов (Одна модель, разные View).

Почему MVC? Расширяемость, гибкость, .

Приметы использования.

Структура

Получение данных выносим в ещё один абстрактный слой – библиотеки. Это бывает полезно когда у нас есть админка. Тогда нам не приходится по нескольку раз заниматься выборками из базы, кешированием и прочими вещами в каждой модели.

  • Libraries – папка с библиотеками;
  • Components – папка с компонентами;
  • Templates – папка с шаблонами.

Итог

Домашнее задание:

  • Разобраться в паттернах программирования MVC и Singleton.
  • Попробовать рассмотреть структуру работы популярных CMS.
  • Попробовать сделать набросок своей CMS (скачать набросок CMS от konservs.com).

На следующем занятии мы изучим:

  1. Отладка и логирование в CMS.
  2. Язык SQL. Работа с MySQL.
  3. Написание Singleton класса для MySQL и выполнение простых запросов.

Оглавление уроков

Ну, и напоследок, краткое оглавление уроков:

Поздравляю всех, кто осилил такой большой урок. До встречи!

Комментарии

11.02.2016 07:32:55
Avatar of shiziksamashiziksama
В большинстве популярных фреймворков моделью считают то что в статье описано под видом библиотек. а контроллер выполняет действия над моделями.
вообще вот связка понятий одной CMS, описанной на сайте и остальных фреймвоков то будет:

CMS Фреймворки
libraries model
view view
model функция в controller

а еще! Всеми считается что ответ(как и 404) обязан отдавать контроллер, а не роутер.
11.02.2016 07:34:02
Avatar of shiziksamashiziksama
парсер сьел пробелы(
и еще окошко для написания коммента хотелось чуть побольше
11.02.2016 09:29:21
Avatar of КонсервКонсерв
@shiziksama
Но никто же не мешает нам в модели получать данные из библиотек :-)

Библиотеки помогают нам использовать одни и те же данные в разных моделях.

Хотя суть, в принципе, ясна - можно в моделях подгружать другие модели, так ведь?

По поводу контроллера не понял. Он у нас и так может вернуть 404 или 403, который потом (всё равно через роутер или, допустим, назовём этот класс BApplication) вернётся пользователю как код ответа.

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


P.S. Готов обсудить любые улучшения, ведь это принесёт пользу всем.
13.02.2016 02:19:10
Avatar of shiziksamashiziksama
@Консерв
Суть в том что у нас есть модель статьи. Она ответственна за всю работу с данными.

а контроллер выглядит так

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) должно идти в контроллере, модель вообще не должна знать и существовании пользователя.
15.02.2016 05:11:52
Avatar of КонсервКонсерв
@shiziksama
А в чём плюс?

И можно ли рассматривать вариант изолированной админки? Например, когда в админке свои компоненты и шаблоны. Типа как в Joomla.

P.S. Когда разрабатывал архитектуру - ориентировался в том числе и на статью https://habrahabr.ru/post/175465/. Цитирую: В рамках этой концепции считается, что по мере возможности логику приложения (вроде бизнес-логики из примера выше) лучше всего помещать в модель, а не контроллер или представление.

В моём случае логика работы (проверка доступов и т.п.) помещается в модель, а библиотеки служат для универсальной работы с "сырыми" данными.
13.06.2016 08:19:22
Avatar of shiziksamashiziksama
исходя из этой статьи оказывается что наши библиотеки полностью выполняют роль моделей
а большинство наших "моделей" на само деле заключаются только лишь в получении данных из базы, что вполне логично было бы навесить как функцию контроллера и не создавать целую модуль

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

Плюс такого способа - отсутствие большого количества файлов в которых функционального смысла по 2 строки
14.06.2016 11:42:47
Avatar of КонсервКонсерв
Согласен. Однако мне так удобнее :-). Ещё один уровень абстракции позволяет писать более гибкие приложения.

Например, несколько моделей в 2 строки могут давать определённые "порции данных" - одни больше данных, другие - меньше. И для разных моделей мы разграничиваем доступ. А библиотека используется одна.

А если бы всё это оперировалось только в моделях - пришлось бы "костылить", наверное. Была бы "крутая" модель, которая оперирует наборами сущностей, и модели попроще, которые используют "крутую" модель. По сути то же самое, только всё на одном уровне.
21.09.2017 03:32:53
Avatar of lElenaFutlElenaFut
Работа в интернете
Captcha Обновить
Go Top