DC.CMS и причем тут казалось бы Уроборос?! (часть №1)

  • написал: MpaK
  • 171
Уроборос имеет несколько символических значений. Первое основано на символе змеи, кусающей свой хвост, – это олицетворение вечного возвращения в циклической форме или вечности вообще. В алхимической картине мира змея играет роль символа циклически протекающих процессов (испарение, конденсация, испарение – в многократном повторении)

DC.CMS система управления содержанием сайтаВ своей первой статье я рассказал свою историю пути по созданию DC.CMS, все шаги, варианты и вопросы которые на данный момент решены мною в новой версии системы или еще не совсем получили должное решение. Уже в этом тексте я бы хотел подробнее рассказать архитектуру своей новой системы, поделиться так сказать с общественностью, чтобы возможно увидеть какие-то замечания, предложения или вопросы. Так сказать от «глаз не замыленных».

Теперь уже не DataCenter CMS, а в сокращенном варианте DC.CMS. Почему?
Тут три ответа:
1. DataCenter — изначально это название было выбрано не совсем верно и сейчас больше ассоциируется с хостинг компаниями, которые поддерживают свои ДатаЦентры. Думаю очевидно, что и на слуху больше ассоциации другие, да и поисковые системы будут думать так же.
2. Изначально у системы была идея, что «в центре данные», они сами решают как им показаться и что их будет преобразовывать. Конечно, так и осталось, что данные главные, но была еще и идея единой типизации данных, от этого пришлось отказаться за неоптимальностью. Как пример: статья в разделе о компании, на самом деле ничем особо не отличается от новости, кроме как поля даты. Возможно, в будущем при переходе Document Oriented Database например MongoDB будет смысл вернуться, но сейчас всё же данные разрознены, никаких EAV (позднее объясню свой отказ) и их только объединяет стандартный модуль поиска своим индексом и связи блоков со страницами, это будет видно позднее, когда расскажу чуть больше деталей архитектуры.
3. DC.CMS звучит короче, даже само понятие Direct Current как постоянный ток уже само по себе интересное понятие и будоражит воображение похлеще. Хотя идея завернута в другом и не совсем явно отображена конечно в названии, но надеюсь будет отображена доступно в логотипе.

DC.CMS вход в систему
Начну с самого начала, основ DC.CMS, что легко в фундамент, как пришло понятие блоков, типов, лэйаутов и т.п.

Фундамент.
Так как система рождалась довольно долго, причем в поисках, пробах, удачах и не совсем удобных решениях, времени было полно, экспериментов тоже. Ей нужна была основа. Перепробован очень большой инструментарий, вплоть до желания отколоть лучшее из CakePHP, влить туда классы Zend Framework’а и еще кучу других бредовых идей. Но в тот момент самым удобным для меня инструментом на PHP оказался CodeIgniter. Отличная документация, простота с которой можно было создать первое приложение и даже совместимость с PHP4 была плюсом. Потому CI можно считать бензином, запалом который дал движение системе. Конечно, много уже систем созданных на базе CodeIgniter это и ImageCMS, Cogear, PyroCMS, MaxSite CMS или же MojoMotor. Но всё это было не совсем то, или заточены под определенную сферу, например блоги и социальные сайты или же какие-то слишком простые страничные сайты. Их идеи внутри систем меня не впечатляли.

Что желаем получить от CMS – это пожалуй самый главный вопрос?
На него нужно смотреть двояко, с разных сторон и глазами разных людей.
Как разработчик мне нужна была удобная в установке и разворачивании система. Которая позволяла бы мне быстро сверстать макет, повесить страницы, закрепить модули, заполнить первоначально сайт и отдать клиенту. Но самое главное я хотел видеть удобное API разработчика, список определенных действий, чтобы было видно, как сделать новый модуль и разместить его на сайте.
Как клиент или контент редактор, который будет поддерживать сайт, я бы хотел все удобства заполнения. Чтобы я мог всегда сменить разделы. Указать некие meta для SEO продвижения. Чтобы я мог просто перетащить нужный мне модуль, например гостевой книги и тем самым установить его на данной странице. Я хотел удобства в этом плане. Это как раз 3ий вопрос из первой статьи, но пока я считаю, его не решил.
Как менеджер проектов, я бы хотел видеть стабильную систему, которая бы позволяла моей студии устанавливаться и разворачивать как можно быстрее и удобнее сайты для заказчиков.

DC.CMS гостевая книга

Идея.
Как уже говорил, идея вынашивалась очень долго. Были ошибки, были пробы, откаты назад и почти не совместимые со старыми версиями изменения, но для одного сайта я даже написал модуль перехода, уж больно важный был для меня сайт. Сейчас я вижу весь путь системы могу честно сказать, что самое сложное это было для меня модульность, блоки установленные на странице, сделать так, чтобы свести минимум излишней повторяемости.

И вот ряд идей, которые я вынес и реализовал, сейчас я поделюсь ими с вами.
1. Модульность. Если учесть, что CodeIgniter это MVC система, то это не совсем удобно возиться в роутингах, даже динамических и зависеть от одной страницы – контролер. Скорее в классических проектах создаваемых именно под проект с нуля и на базе MVC фрейморка это удобно, но для CMS системы, которую есть желание быстро разворачивать и настраивать сайт такой подход слишком трудозатратный и не совсем эффективный.

Ядро. Потому было решено создать единое ядро Core, на которое приходят все запросы системы. Ядро занимает настройками, авторизацией и проверкой доступа, проверкой URI и существованием страницы. Но основная функция это формирование нужной на страницы, найти для неё шаблон представления, вызвать все модули установленные на странице и отобразить результат их работы на нашей странице. Как раз в плане модулей на помощь пришло расширение HMVC. Которое как раз позволяет собрать в «модуль» контроллер, его модель, хэлперы и view шаблоны в отельную единицу, папку.
Модуль это одна боевая единица. Вообще в ближайшее время даже появится модуль пакетов, который позволит эту самую единицу устанавливать в систему. Дистрибуцию я решил свести к .zip пакетам, которые содержат контроллер модуля, его представления, хэлперы, библиотеки, sql файлы инсталляции и деинсталляции и ряд указаний на нужные зависимости.
На самом деле ядро это тот же самый модуль-контроллер, который при некотором простом желании можно заменить своим модулем. Звучит конечно ужасно, но в целом понимая структуру системы, да и так как всё внутри модулей занимается своим делом по MVC то это не так страшно, главное не перегибать палку.

2. Второе решение было отказаться от разделения модуля на front-контроллер и backend-контроллер, например для администрирования. Пусть контроллер модуля будет цельным. В любой момент может пригодится вызов во frontend стороне к примеру вызов формы редактирования поста блога, а в друг захочется сделать некий Хабр, где прямо на сайте захочется заводить новые сообщения? Такое решение позволяет ощущать целостность нашей боевой единицы.

3. Третье решение так же касается функциональности модулей. Модули в DC.CMS могут содержать внутри себя много методов и каждый метод модуля может быть установлен в страницу то есть стать «блоком» или еще не плохой термин «встать в слот». Я даже придумал ахинею, что «каждый хороший модуль мечтает стать блоком».

Например «новостная лента» Newslist, у этого модуля есть три метода: index – который показывает список имеющихся в разделе новостей, last – показывает нужное кол-во последних новостей и методо show – который показывает определенную и нужную нам новость по id. Согласитесь, неудобно каждый раз создавая новую страницу на сайте размещать в ней опять модуль «3 последние новости в правую колонку», «меню» в левую и «текст» в основное содержание? Конечно можно ряд этих вещей сразу зашить в шаблон представления, но это так же не эффективно и неудобно для рядового пользователя.

DC.CMS редактирование контента, установка модуля

Эта способность модулей связываться как с блоком, так и со страницей очень удобна в плане будущей поддержки созданных сайтов. Если решив, что в какой-то момент нам захотелось, чтобы на всех внутренних страницах изменился модуль меню, мы удалим старый и вставим новый. Или же нам захочется добавить баннерный блок в самый низ сайта, мы так же просто свяжем наш модуль «Баннеры» с типом этой страницы.

4. Потому было решено ввести типы страниц, например тип «внутренняя страница» и «главная страница» это как раз четвертое решение. С типом связан шаблон «вывода дизайна» — представления, например с первым inside.html, а со вторым index.html.
Так вот и удобно получается связать некоторые модули с типом страницы, чтобы например все внутренние страницы заставляли исполняться модули newslist::last(3), menu::index() и засовывать результаты своей работы нужные шаблону переменные. Тогда при создании новой страницы нам остаётся только вставить модуль «текст» и заполнить его, остальные модули:: методы будут связаны с типом и их не надо будет заполнять каждый раз и связывать с новой страницей. Это очень удобно и повышает производительность в разы. Это наложило ряд эффектов на модуль:: метод, у них появились свойства «можно ли его вставить в страницу (p) или в блок (b) или в то и другое. Это позволяет запретить вставлять модуль гостевой книги в абсурдный как например в «шапка сайта». Но конечно если уж совсем зазудит программисту то можно изменить права модуля и позволить ему сделать нечто невообразимое и неудобное, но это уже на совести разработчика модуля.

DC.CMS типы, лайоуты, шаблоны

DC.CMS редактируем код шаблона через CodePress

5. И можем самое главное, как раз с чего бы и появился Уроборос в статье – это «система создающая сама себя». То есть в действительности позднее расскажу про внутреннее устройство системы будет видно, что к примеру адрес /admin/page/action.edit.page.18 это ничем не отличающийся адрес от /news/russia/action.show.id.20. Просто у первого адреса тип страницы – административный, а значит, модули вызываются административные, а в основное содержание вставлен так же модуль администрирования страниц со своим действием и другими параметрами.

DC.CMS иерархия страниц на сайте

Тут внезапно образовалась «фишка»! Если нам к примеру не нравится как модуль Page предоставляет нам доступ к настройкам, созданию и редактированию страниц сайта, мы можем просто написать новый модуль например PageTree, вставить в контент страницы /admin/page и удалить старый модуль! Вуа-ля! У нас совершенно новая система администрирования страниц в виде раскрывающегося дерева, а не набора документов.
Или верхнее меню администрирования «МОДУЛИ», это тот же раздел на сайте «/admin/modules/» где его подразделы, к примеру «/admin/modules/users» становятся обычными пунктами в меню, стоит нам только в самой же системе администирования добавить наш новый документ в эту ветку.
Змей — хватающий себя за хвост и так бесконечно. Удалили модуль, заменили его на свой. Не нравится дизайн административной области, заходим в шаблоны и меняем его. Это очень удобная возможность для распространения системы под своим брэндом!

to be continues…

0 комментариев

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.