Возвращаясь к тому, что еще не было написано - знаете ли вы, в чем триадная метафизика CMS?

    Давайте поговорим о философии CMS и CMS-строительства. CMS как объект бытия - это штука, демонстрирующая дуализм правильного подхода к сайтостроению. Фокусная концепция CMS - это единство и борьба противоположностей, собирающих сайт в единое целое. Дизайн и контент - вот два непримиримых союзника и два верных противника, две вещи, которые переплетаются самым неожиданным образом. И, если внешний секси CMS - это конфетка посетителю, то обратная сторона CMS - разделить дизайн и контент, динамику и статику, front read и back office. Но так, чтобы они были вместе - тень и тень тени.
    Тем не менее, дизайн и контент надо разделять. Суп - отдельно, мух - отдельно. Дизайн - как мода, постоянно меняется, а вот контент относится к вечным ценностям (ну, или считается таковым). Но посетителю не нужен "только дизайн" или "только контент", поэтому дизайн нужно "свести" с контентом. Возникающий при этом экстаз разработчика - это залог успеха и репрезентативности.
    Кроме того, на стыке дизайна и контента образуются виртуальные элементы, которые трудно причислить к дизайну или контенту - это вполне самостоятельные "синтезированные элементы", которые посетители воспринимают как контент второго вида. Это навигация, ссылки по теме, рубрикация... и прочие штуковины, не имеющие самостоятельного значения.
    Все это не дает воспринимать CMS как вполне однозначную систему, достаточно и легко детерминируемую. Поэтому CMS - это гибкая, недетерминируемая и почти мистическая система, а CMS-строение - это священнодействие.
    Такова основная философия CMS, несколько напоминающая чеширского кота, исполняющего темпоральную фугу.

    Основная проблема, которая почему-то начинает мучить - это вопрос в стиле "Если слон залезет на бегемота - кто кого переборет?". То есть требуется расставить несколько ключевых точек. Многие решают эту проблему, руководствуясь аналитическими выкладками, точным расчетом на логарифмической линейке или интуицией, и совершают тем самым самую большую ошибку, потому что все дальнейшие построения базируются на этих ключевых точках. Между тем, определять ("детерминировать") эти точки совсем не обязательно. Лучше, если эти точки будут плавающими (но не бродящими туда-сюда), но связанными между собой (изменение статуса точки сразу влияет на остальные, явно или неявно). В то время как детерминированная точка будет ограничивать гибкость системы и свободу выбора. Согласитесь - глупо привинчивать стул к полу.
    Что же мы берем в качестве ключевых точек? Те моменты, которые влияют на генезис нашей системы. Это формат^* представления информации (XML, HTML, Simple Tagged, etc.), формат хранения информации (файлы, таблицы SQL-серверов, объекты метаСУБД), формат обработки информации (парсинг, инклюдинг, etc.), формат компоновки информации (динамический, статический, etc.), интерфейс с пользователем,...

    А теперь вернитесь и перечитайте еще раз. Уложите в свою голову, что проектирование CMS использует нечетко определенную логику, и готовых решений тут нет^**.

    И начнем мы с формата представления информации. Важнейший вопрос "to XMl or not to XML" будоражит умы, лишает аппетита и сна. Да или нет? Ответ, как вы уже поняли, совсем не связан с вопросом.

--
* - слово "формат" многогранно, поэтому может (и будет) использоваться в разных смыслах в зависимости от контекста
** - а иначе, с чего на hotscripts.com так много CMS в списке?