Генетически модифицированный XML
С одной стороны, XML - это общепризнанный стандарт представления данных... а с другой - девушка, которая будет засовывать документы в CMS, в этом XML совсем не разбирается. Если же вы сумеете найти золотую середину, то она все равно окажется фикцией. Самое время кукарекать.
Системный анализ говорит, что в дилемме "правильный выбор - неправильный выбор" лучшим будет третий вариант - оптимальный.
Так вот, проблема решается достаточно просто - мы введем новый уровень абстрагирования.
Пусть в CMS документы хранятся в некоем формате "альфа"... тогда документ
в удобном для пользователя формате импортируется в CMS, а при необходимости
экспортируется либо в формате XML, либо в формате, заказанном пользователем.
Соответственно, контент может принимать ощутимые формы XML, но где-то там, извне.
Осталось определиться, в каком формате эти документы будут существовать внутри
CMS (между прочим, хранить в БД можно в одном формате, а обрабатывать внутри
CMS - в другом).
Чтобы определиться, совершенно необязательно принимать позу роденовского "Мыслителя"
или тактику дуэта Маркс-Энгельс. Критерий весьма нехитрый - удобство работы
с этим форматом.
Да, проще работать с XML*, подключив
универсальный, но медленный и ресурсоемкий парсер, либо самому писать оптимизированный
парсер (под "ожидаемый" набор). Поскольку ни того, ни другого нормальным
людям не хочется, мы пойдем альтернативным к XML путем.
Берем базовую идею XML, но в собственной обработке. Наш формат "альфа"
базируется на двух моментах. Во-первых, с теговой структурой удобно работать
- есть куча библиотек, примеров, технологий обработки, а во-вторых, набор необходимых
тегов определяем сами. Хорошо бы при этом предусмотреть возможность расширения
набора тегов - мало ли в будущем понадобится?
Этим мы убиваем трех зайцев: конвертация в/из XML достаточно прозрачна, рабочий
парсер быстрый и простой, а логическая разметка сохраняется с нужной детализацией.
Поскольку конечный результат работы CMS - это HTML, то желательно ориентироваться
на что-то подобное, но не обязательно.
Впрочем, какой бы формат мы сейчас не выбрали - наше решение
все равно будет неправильным**. Вспомните про плавающие
точки.
Поэтому плавно переходим к рассмотрению формата хранения информации, которое
чаще всего сводится к вопросу "В чем лучше хранить контент - в СУБД (какого
типа?) или в файлах?". Однозначного ответа (даже в рамках одного проекта)
как вы уже поняли, нет. Самого ответа, впрочем, тоже нет. Зато есть субъективно-экспертные
оценки, которые мы ниже и рассмотрим.
---
* - в состав php входят парсеры XML
** - поэтому он и называется "альфа"
(a) Контент: Vadim Artamonov, 1999 - 2019 Anno Domini