MyCMS

студия ad, 11.11.2011 Пятница, 19:07

     С момента начала моего изучения php я захотел написать свою систему управления контентом. Ну вы понимаете, совсем свою, пусть даже и со всякими банальнейшими плюшками и прибамбасами «как у всех». Но времени на разработку своей системы катастрофически не хватало. Я был занят исключительно созданием и продвижением своей коллекции обоев и ещё пары проектов, в прочем не очень удачно. В один прекрасный день, уж не знаю, может муха меня неправильная укусила, сонник подсказал чего лишнего или мешком пыльным огрело, но я понял что дальнейшее продвижение сайта, представляющего собой башню из костылей, смысла не имеет. К тому времени код движка, на котором работают пока все мои сайты, разросся на несколько файлов и классов и являл собой дикий хаос используемых и уже отживших функций, заброшенных кусков кода и запросов вникуда.

     Я не стал выдумывать сложное уникальное название будущей cms, как бы сделали многие. Вмеcто этого я назвал её единственно-логичным для меня способом — «Моя cms», что при трансформации на язык кода и сети (английский язык) превратилось в краткое mycms. Логотип, который вы видите в шапке поста, придумался сам собой. На нем переплетаются буквы M и Y. Очень вероятно что систем с таким названием море, но меня это не интересует.

     И вот я оказался перед чистым документом в notepad++ которому суждено было стать индексным файлом моей новой системы. Мне предстаяло продумать архитектуру и решить каким образом будут (и будут ли?) взаимодействовать модули системы. Получилось примерно вот что следующее...

     Корневым элементом системы является каталог статических страниц. Каждая страница хранится в базе и имеет несколкьо контентных полей, таких как title, description, keywords, само поле контента страницы и специальное поле для исполняемого php кода. Php код в самом контенте страницы не исполняется, зато там работает парсер условий, ок котором я уже писал и ещё скажу. Php поле же нужно для создания страниц на которых должно выводится нечто динамические, к примеру капча. Страницы представлены в виде древа, имеют родителей и потомков и могут образовывать сложные структуры. Для реализации этой идеи мне и потребовался класс для работы с nested sets. Уже реализованное управление структурой страниц в модуле администрационной панели выглядит так:

     Если присмотреться к скриншоту, видно что страницы можно вырезать и копировать. Это не до конца верно, так как если пометить страницу как вырезаемую, то вместе с помеченной страницей будут вырезаны все вложенные страницы, как буд то мы берем скальный массив за верхушку его самого высокого пика и переставляем в другое место. Так же слева от каждой страницы, точнее её алиаса (фрагмента адреса в url) стоит иконка с синей электрической вилкой. Эта иконка отображает текущий статус страницы — каждая страница может быть видима или нет. Это аналог галочки «Материал недоступен для просмотра» в блогах ucoz. Но если в блогах у данной галочки назначение очевидно, то в каталоге страниц есть ещё один нюанс. Невидимыми необходимо сделать служебные страницы, к примеру страницы ошибок. Таким образом движок системы сможет выводить их контент, но зайти на страницы по прямому адресу будет невозможно. Пример тому — страницы 404 ошибки. Далее, каждая страница в настройках имеет два очень важных выпадающих списка, вот как они выглядят в настройках редактирования страницы /admin:

     Поле «Шаблон» указывает, какой глобальный шаблон будет использовать данная страница. Глобальные шаблоны это как главный шаблон в конструкторе шаблонов ucoz с тем отличием, что их может быть неограниченно много. Это делает возможным легко менять дизайны различных участков сайта. В шаблоне самой страницы и в глобальном шаблоне как и в ucoz доступны условные коды — их идея показалась мне интересной и удобной. Вы можете задавать свои дополнительные условные коды используя php поле страницы. В общем всё удобно. На страницу со списком шаблонов можно посмотреть на скриншоте ниже:

     Второй выпадающий список гораздо важнее и фактически является несущим во всей архитектуре. Это список доступных инстансов. Инстанс в моей системе это экземпляр модуля. Чтобы было понятнее, приведу пример. В ucoz есть модуль блога. Если вы хотите создать блог — вы его используете, а вот два блога создать уже нельзя и приходится использовать другие модули. Так вот в моей системе модуль — абстрактный образ, задающий общие свойства будущего инстанса (модуля в вашем понимании). Хотим блог — создаем инстанс модуля «блог» и называем инстанс к примеру «Мой личный блог». А когда хотим создать ещё один блог — создаем ещё один инстанс. Получается блогов мы можем сделать на сайте сколько душе угодно. Но самое интересное то, что инстанс начинает работать только после того, как размещается, «припарковывается» на одной из статических страниц. За это и отвечает выпадающий список о котором я говорю. Если страница сделана парковочной, то есть в её настройках выбран один из созданных вами инстансов, то после того как движок сайта при анализе адреса запрошенной страницы дойдет до текущего алиаса, весь остаток адреса будет отдан на обработку в инстанс. Такая обработка позволяет нам создавать интересные вещи. Например: админпанель сайта на любой странице, будь то /admin или /this/is/panel/orly, одна и та же админ панель по двум, трем, четырем разным адресам или даже две разные админпанели с разными паролями и дизайном для одного и того же сайта. Это возможно потому, что администрационная панель — тоже модуль и следовательно может иметь много инстансов, а каждый инстанс в свою очередь использует свои личные таблицы в базе данных. Таким образом инстансы существуют раздельно, как близнецы, рожденные одинаковыми но живущие разными жизнями. Шаблоны каждого инстанса можно редактировать, вот к примеру страница рекдактирвоания инстанса администрационной панели:

     Курьезно, то, что админпанель — инстанс, дает нам редактировать админпанель из админпанели что приводит к интересным последствиям, например есть страница, которая редактирует сама себя.

     Модули для системы пишутся отдельно и подключаются к системе в любых количествах. Это позволит разработчикам легко встраивать в свой сайт собственные разработки, например модули статистики, блогов, форумов, каталогов файлов и так далее. Некоторые модули я напишу сам. Тот же oboi.ws будет построен на модуле фотографий.

     Мою систему ни в коем случае нельзя сравнивать с ucoz, так как цели передо мной стояли совершенно другие. Ucoz разработан с феноменальной защитой от идиотов, моя система напротив позволяет убить сайт тысячей изощренных способов буквально на каждом шагу. И это нормально, так как систему я писал для себя. Попробую провести аналогию. Представьте что у вас есть доска и вам нужно отпилить от неё кусок. И есть два варианта сделать это: плотник по имени ucoz и плотник по имени mycms. Ucoz отпилит кусок доски за вас, но только так, как умеет сам, допустим 10 сантиметров с левого или правого краю, и всё. Mycms же даст вам в руки пилу и предложит пилить так как вам хочется, а вы уже в зависимости от уровня проффессионализма либо отпилите себе руки либо отрежете себе именно такой кусок доски какой вы хотели.


Жми на пятую!
21, 2, 3309
№2
Что сказать, отлично!
№1
Отлично. Система выглядит очень хорошо, как в плане дизайна, так и функциональности. Написать понятный мануал - и можно будет распространять :)
    © Блог StudioAD.ru 2024 год нашей эры. Не все права защищены... Копирование любой информации и материалов с обратной ссылкой приветствуется! Хостинг от uCoz.

    Если вам пришлись по душе материалы моего блога - подпишитесь на RSS дабы получать обновления незамедлительно! Я рад что вы читаете и комментируете мои экзерсисы, приятного времяпрепровождения.