Pull to refresh

Анонс и история Explay CMS 3 (Core)

Reading time 4 min
Views 1.3K
Explay

Немного истории



Где-то в конце августа — начале сентября, постепенно понимая парадигмы объектно-ориентированного программирования и приходя в ужас от своего старого кода, я решил забыть Explay 2.1 как страшный сон и взялся писать все с чистого листа. Да, это, вероятно, было не самым лучшим шагом в сторону пользователей Эксплея, но вы уж извините мою глупую натуру.

Основная идея Explay 3 — это дать разработчику сайта полный контроль над типами данных: добавить к статье 10 полей, необходимых именно на этом проекте или же вовсе ввести новый тип данных, например, подарки а ля Вконтакте. При всем этом разработчик, внедряя новые типы, не должен тратить время на написания PHP-кода или собственных модулей. В основном из-за такой универсальности система за несколько месяцев разработки имеет только ядро и довольно нелегкое.

В этот раз воплощение планов по захвату мира мыслей началось не с index.php, а с чистого листа бумаги. Исписав несколько листов вдоль и поперек, я определился со структурой БД. Сама же идеология была ясна заранее: основная сущность — объект, а объекты классифицируются по типам. Таким образом к концу первого этапа в базе данных появилось 6 обязательных/главных/исходных таблиц, описывающих всё и вся, в том числе сами себя.

В проектировании БД мне очень помогла утилита MySQL Workbench 5.0 OSS.


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

С декабря я стал почти свободным человеком и вплотную занялся движком — разработка пошла быстрее. Таким образом сейчас представляю вам ядро движка Explay CMS 3. Работоспособность, примерно, 70-80%.

Кто-то может видел мои попытки рассказывать о процессе написания движка, но, к сожалению, меня снова надолго не хватило :(


Технические характеристики



Код



Код полностью на ООП. ООП используется на всю катушку со всем вытекающими плюсами и минусами. Ядро CMS — это 24 класса: контроллеры и объекты представляющие их записи в БД — ORM (поля, типы и простые объекты). Все без исключения методы уже комментированы для дальнейшего составления документации.

Лирическое отступление:

Три основополагающие сущности движка — это три вида объектов: объект типа, объект поля и обычный объект.

Тип (Type) — это категория (вид) обычных объектов. В физическом смысле — это таблица, в которой и хранятся объекты определенного типа.
Поле (Field) — это описание свойства объекта. В физическом смысле — поле (столбец) таблицы. Но поле не всегда может описывать столбец таблицы типа, которому оно принадлежит; поля могут быть связанные («JOIN» свойства другого типа) и справочники (селекторы, значения которых хранятся в отдельной таблице).
Объект (Object) — это запись в таблице его типа.

Для получения объекта необходимо знать его тип и id. Все свойства объекта описаны полями.


MVC



Паттерн «Модель-Представление-Контроллер», к моему счастью, оказался в проекте не как дань моде, а как потребность. Благодаря нему на модель/бизнес-логику/модуль уходит мизерное количество кода. Как следствие красота кода и низкая стоимость разработки.

ModuleResponse — обязательный объект «ответа» вызванного метода модуля. Он содержит данные (объекты), которые будут представлены в виде XML-таблицы.


image
Рис. 1. Жизненный цикл страницы

Шаблоны



В качестве стандартного шаблонизатора используется XSLT. Тут говорить особо нечего, красиво :)

Реализация на уровне PHP-кода: необходимый шаблон задается объекту ответа модуля (ModuleResonse) в странном формате: относительный путь до xsl-файла без расширения (предполагается, что шаблон может быть и tpl). Например в my::__default(): $response->setTemplate ('my/__default');

Если метод модуля вызывается из адресной строки, например example.com/module/method, то шаблон указанный в его ответе будет использоваться как «точка вхождения».

К слову, благодаря макросам и модулям, не требующи никакой установки (за исключением, есть они связанны с какими-либо типами), последние могут выступать как плагины, подключаемые из шаблонов.

Для упрощения жизни разработчика и верстальщика были введены макросы. Синтаксис: {{имя_модуля:: название_метода(параметры)}}. Шаблон, собранный согласно ответу указанного модуля, будет просто вставлен на место макроса. Может, это не самый красивый вариант сборки шаблона, но он явно быстрее подгрузки XML-таблиц прямо в XSLT через document().

Высокие нагрузки и кеширование



Поскольку CMS ориентирована на создание социальных сетей и интернет-сообществ, то кеширование — это все. Идеология кеширования — сохранение целых объектов, которые, к слову, никогда не будут устаревшими, т.к. при их изменении сбрасывается соответствующий кеш.

Архитектура движка не позволяет выбирать несколько объектов одним запросом к БД — для каждого объекта свой запрос. Здесь сидит самая главная проблема и самая вкусная изюминка. Например, у нас 100 комментариев к статье (100 запросов + 1 некешируемый на выборку списка id). При выключенном кешировании у нас всегда будет 101 запрос (обоги), а при включенном — минимум 1. При изменении одного комментария модератором — минимум 2, то же самое при добавлении нового объекта. Таким образом, имея быстрый движок кеширования мы получаем довольно гибкую и относительно легкую систему. А вот использование CMS без кеширования я бы рекомендовал только для домашней разработки.

~/explay/classes/CacheController — фронт-енд контроллер кеша. В комплекте файловый и Memcache бэк-енд.

Возможно различное время жизни для обычных и системных объектов (прим. автора).


Системные требования



Обязательные:
  • PHP 5.x
  • XSLT
  • MySQL с поддержкой InnoDB (желательно 5.1)
  • mb_string
  • mod_rewrite

Рекомендовано:
  • Memcahced


Запуск



Текущая версия в SVN скорее для ознакомления с кодом и собственно архитектурой в целом.

В корневой папке лежит файл dump.sql — его в базу данных. Настройки в explay/config.php. Рабочий модуль my.

Основное правило ЧПУ: example.com/имя_модуля/имя_метода/param0/param1/.../paramN
example.com/something/uri/to/hell.xml — выдаст Вам XML-таблицу ответа модуля :)
example.com/something/uri/to/hell?debug — немного Debug-информации.

Цель этой статьи



Данная статья — это всего-лишь ознакомительное описание к CMS. А Хабрахабр — это, пожалуй, единственное место, где я могу услышать независимые и профессиональные отзывы и мне они очень нужны. Так же я хотел бы понять, будет ли кто-нибудь работать с ней в будущем. Критика, советы, деловые предложения приветствуются.

Посмотреть код в SVN

Спасибо за внимание!
Tags:
Hubs:
+48
Comments 79
Comments Comments 79

Articles