--- title: Теоретические основы CMS date: 2006-12-13T15:22 tags: [css, php, tech, игры] --- [CMS matrix](http://www.cmsmatrix.org/matrix/cms-matrix) и отечественный [CMSlist](http://cmslist.ru/) предлагают огромные списки доступных opensource систем управления сайтами. Многие из них имеют множество недостатков, такие как - Монстроидальность и неверное useability. 80% функций для неискушённого пользователя наврядли будут использоваться. А из оставшихся 20% сразу он поймёт как работает 1%. - Устаревший код и архитектура со времён PHP4, необходимость версионной поддержки - Медленная скорость загрузки из-за подгрузки неиспользуемых объектов и модулей - Чёткая полоса возможностей системы, ограничивающая как что должно работать, либо наоборот - её отсутсвие служит и дорогой и препятствием, особенно для новичков Всё это заставляет программистов писать свою систему с нуля. Я постараюсь тут описать некоторые теоретические основы для этих начинаний и как итог - к чему они все приходят. ### Framework Всё начинается с платформы, т.е. расширение языка функциями и объектами, использование которых значительно облегчит дальнейшую систему. На данный момент основные законодатели мод на PHP: > Форма следует за функцией > Луи Салливан, американский архитектор, "отец модернизма" - [CakePHP](http://www.cakephp.org/) - [Symphony](http://www.symfony-project.com/) - [CodeIgniter](http://www.codeigniter.com/) - [Zend platform](http://www.zend.com/en/products/platform/) На других менее популярных языках фреймворки соответсвенно Python - [Plone](http://plone.org/), Java - [Spring](http://www.springframework.org/), [Struts](http://struts.apache.org/1.x/) --- Выбор из существующей платформы как и выбор CMS - палка с двумя концами. Написав свою вы будете уверены что всё работает как вы задумали и не надо будет изучать API существующей. В то же время своя платформа как правило отметает поддержку третьими разработчиками (потому что документацию как правило никто не успевает написать). Платформа по разному может запускать инициализацию объектов, по-разному хранить данные и файлы и как правило отвечают за - Разделение логики исполняемого кода по MVC - Кэширование ([объектов](http://www.danga.com/memcached/) и темплейтов) - ЧПУ (Умные URL) - Кодировку текста (UTF8) и тип данных (MIME) - Упрощённый/абстрагированный доступ к БД (PEAR DB2, ADO DB) - Адрессацию и запуск более высоких уровней приложения - Автогенерацию форм, таблиц БД, страниц управления (Scaffolding) - Классы генерации деревьев, особых форматов данных (XML, json) ### Эволюция и скорость Если сравнивать уровень развития архитектуры CMS с живыми организмами, то можно заметить что эволюция заставляет животных приспосабливаться изменяя их форму тела и социальное поведение. Системы CMS тоже могут либо быть примитивными и очень быстрыми, громадными вымирающими всеядными динозаврами, узконишевыми скатами не имеющими конкурентов либо балансирующими всем в меру. Однако надо сразу понимать что обязательно найдётся движок чем-то лучше и если вы делаете один выбор (скажем использовать _только файловую систему_), то приобретаете и проигрываете одновременно в скорости запуска или в лёгкости разработки. ### Управление содержанием После выбора платформы, разработчики и архитекты по разному решают проблему управления содержанием. Есть два основных пути: - **Наглядное управление**. Меню, статьи и всё редактируется в том же дизайне что и весь сайт. Элементы управления при этом видны привелигированным пользователям. Плюс такой реализации в лёгкости понимания - клиент видит статью, нажимает иконку и тут же редактирует содержимое. - **Админпанель**. Параллельно с публичной частью создаётся панель управления, разделяемая на модули. Модульность наглядно демонстрирует расширяемость, центральная система авторизации гарантирует меньшую степень риска в доступе к закрытым данным и более лёгкую работу программисту. Иерархичная структура меню создаётся либо в уникальном табличном экземпляре, либо (что реже) в отдельных таблицах.  В старых (и быстрых) CMS, меню можно встретить в виде массивов прописанных сразу в php-файлах, в таком случае можно ожидать что языки и переводы сделаны так же. ### Модули и фундаментальные вопросы архитектуры Фактическое содержание той или иной страницы как правило зависит от _модуля_ - отдельного класса/файла который реализует бизнес-логику, хранит свои данные. Оценить сложность движка а заодно и опустить архитектора можно задав фундаментальные вопросы: - Может ли клиент на одной странице создать две работающих контактных формы (или две статьи)? Обычно ответ - нет, поскольку со страницей связан как правило только один модуль (скажем "текст", "опрос", "контакт", "ЧаВо"). Если нельзя, то как бы пришлось это решать в обходном варианте. - Могут ли данные существовать независимо от существования страницы? Какие? - Может ли содержание существовать (и изменяться) сразу на нескольких страницах? - Могут ли разные пользователи одновременно менять содержание без потерь? Есть ли версионность и синхронизация изменений? - Можно ли объекты встраивать (inline/embed) в содержание страницы с помощью WYSIWYG редактора? А динамически ссылаться между собой с автообновлением или автоудалением? - Как хранятся данные страниц в зависимости от их модуля - в одной общей таблице или каждый раз в разной таблице? Последний вариант плохо масштабируется если надо нарисовать меню. - Где хранить, как показывать и обновлять ресурсы модулей (js, img, css) и ресурсы добавленные пользователями? Что важней при доступе к файлам - модульность или типизация файлов? - Какие модули зависят от языка, а у каких содержание для всех языков одинаково? - Как по умолчанию создаются права к объектам - "всё разрешено" или "всё запрещено"? Отвечать на первый вопрос по-моему можно двумя путями: - Выбираемые под каждую страницу шаблоны и smarty-функциями (вызываемые напрямую из темплейта) - не самое лучшее решение из-за смешивания представления и трудности дебага - Связкой 1:n между страницей и модулями. Усложняет архитектуру, внося внутреннюю адрессацию под компоненты (widgets) ### Среды разработки и поддержка версий При написании системы всегда нужны несколько сред для правильного процесса разработки: 1. **Dev** - то где вы пишите код и сразу тестируете. Очень неплохо иметь на localhost под LAMP-пакетом типа Easyphp, Apache2triad, WAMP и тп. 2. **Prelive** - среда для всех разработчиков внутри компании и тестеров. Иногда её разделяют для тестеров отдельно, иногда комбинируют как-то с ядром движка из SVN 3. **Production/Live** - собственно финальная стадия с реальными данными. Заставить программистов не работать напрямую с этой средой - тяжко. Тут мы доходим до проблемы синхронизации данных и кода т.е. обновлением движка. Тут есть два пути - продать клиенту кота в мешке, получить деньги и больше с ним не связываться, не обновлять движок вообще но это как правило нереально и со временем может получиться что у вас 100 клиентов, три кардинальных версий cms и одна головная боль с поддержкой старых версий. Получается что должна быть постоянно обновляющаяся часть движка, постоянная публичная часть и система обновлений. Автообновление может быть значительно упрощено если все проекты лежат на вашем хостинге. ### API, документация, защита Не стоит забывать о документации. Вы можете написать идеальную CMS, с множеством функций облегчающих жизнь, но без описаний как что можно использовать, без комментариев к функциям или смысла модулей невозможно новому человеку понять что происходит. Некоторые компании специализируются именно на разработке собственной CMS, перепродавая её использование третьим фирмам и берутся за реализацию только богатых клиентов. Поскольку надеятся на благонадёжность клиентов-разработчиков не приходится, то ядро системы шифруется через Zend Guard или [Ion Cube](http://www.ioncube.com/). Читайте: - [ru_cms](http://community.livejournal.com/ru_cms/) - [недовольный отзыв](http://chelovek.com.ua/2009/04/06/%D1%81%D0%B8%D0%BC%D1%84%D0%BE%D0%BD%D0%B8%D1%8F-%D0%BD%D0%B5-%D0%B7%D0%B0%D0%B7%D0%B2%D1%83%D1%87%D0%B0%D0%BB%D0%B0-symfony-%D0%BD%D0%B5-%D0%BF%D0%BE%D0%BD%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D1%81%D1%8F/) о symphony ## Related - [Phonegap приложение](/ru/blog/tech/phonegap-prilozhenie-s-angularjs/) - [UserScripts](/ru/blog/tech/userscripts-i-userstyles-ili-kak-izmenit-lyuboy-sayt/) - [Google AI challenge - стратегии ботов](/ru/blog/tech/google-ai-challenge-strategii-botov/)