Создание блога на 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 строки могут давать определённые "порции данных" - одни больше данных, другие - меньше. И для разных моделей мы разграничиваем доступ. А библиотека используется одна.

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