CMS. Типы страниц/данных

Продолжим наши изыскания. ;)

На сей раз речь пойдет о типах выводимых страниц. Если взять за аналогию WordPress, то у нас будут следующие типы:

• archive - архив
• author - автор
• category - рубрика
• home - главная
• link - ссылки
• page - запись
• search - поиск
• tag - метка

В данном случае типы мы получили скорее из практического опыта работы. Очевидно, что при выводе рубрики нам понадобится совершенно другой запрос к БД, чем при выводе одиночной записи. А чтобы было понятно, каким образом «движок» будет определять нужный тип, посмотрим, как CodeIgniter принимает входящий URL (адрес).

Стандартно работает это так:

http://сайт/index.php/контролер/функция/параметры/параметры

Контролер - это наш базовый php-класс, который мы определим как дефолтный и путем манипуляций с .htaccess получаем адрес вида:

http://сайт/функция/параметры/параметры

Сейчас я упускаю все технические детали, в них я буду вдаваться уже несколько позже.

В нашем базовом классе я прописывают функции, которые и будут обрабатывать нужные нам типы страниц.

Вот примеры:

• http://сайт/page/23 - выведет страницу с номером 23
• http://сайт/category/7 - выведет рубрику с номером 7
• http://сайт/tag/привет - выведет метку «привет»

Еще что касается ЧПУ, то в CodeIgniter можно использовать роутер, в котором задается нужный шаблон. Причем сам шаблон может быть регулярным выражением. Я признаться, пока еще не разбирался досконально с этим вопросом, но думаю, что этих задекларированных возможностей должно с лихвой хватить для кастомизации практически любых входящих URL. Например, если не указывается функция, то это «page». Так что вопрос с ЧПУ пока закрываем.

Типы выводимых страниц я сделал еще на основании того, что вообще может понадобиться для обычного сайта. По большому счету нам достаточно было бы вообще двух: один для вывода одиночной записи, а другой для списка записей. Но для уточнения как именно выводить список, всё равно пришлось бы передавать дополнительные параметры, так что смысла в уменьшении типов я не вижу.

Таким образом мы получаем примерно такую схему работы CMS:

1. Входящий адрес передается нашему базовому классу-контролеру.
2. Происходит подключение основных функций CMS.
3. Автоматически выполняется нужная функция контролера, которая по-сути и определяется типом страницы.
4. Каждый тип страницы имеет свой вьювер (view) в котором уже и происходит получение нужных нам данных (например текстов) и выполняется вывод данных в браузер, согласно выбранному пользователем шаблона (как в WordPress'е).

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

archive - архив

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

author - автор

В этом типе можно по названию/номеру автора получить все его записи. Наверное есть смысл формировать и блок его данных.

category - рубрика

Тут довольно просто - в этом типе выводится список записей в указанной рубрике. Я думаю, что не составит большого труда расширить синтаксис запроса, чтобы выводить сразу несколько рубрик, например «/рубрика1+рубрика3».

Сами же рубрики - это отдельная таблица БД. В отличие от WordPress мы сразу же добавим поле «menu_order».

home - главная

Главная должна быть отдельным типом, чтобы можно было вывести на ней вообще любую информацию. Только нужно будет предусмотреть какие-то «стандартные» случаи, как это происходит в блогах, или вывод одной статичной страницы.

link - ссылки

Тут просто список ссылок (blogroll). Все ссылки хранятся в одной таблице в БД. В WordPress'е блогрол реализован довольно неплохо, поэтому можно взять за основу его структуру.

page - запись

В отличие от WordPress, где неудачно реализовано деление на записи и постоянные страницы, мы попробуем решить задачу с другого бока. Каждая запись может быть любого типа. Причем тип можно будет придумать свой. Таким образом мы сможем получать выборки для самых разных вариантов. Например можно придумать тип страницы «home» - и это будет означать, что запись всегда отображается на главной странице. А тип «blog» будет означать, что запись будет помещена в ленту новостей. Тип «book» можно использовать для некой электронной книги. Каждая запись может иметь сразу несколько типов. Такое деление позволит создавать записи/тексты для самых разных случаев.

Каждая запись может относиться к рубрике (или рубрикам). По функциональности это тоже самое, что и в WordPress, но с тем отличием, что рубрику можно не указывать. В этом случае она изымается из вывода. В сочитании с типом записи можно получить например отдельные разделы на сайте: скажем не указывая рубрику (то есть страницы не отображаются в сайдбаре или архиве), но зато указав тип «faq» мы получим их отображение в виде отдельного раздела «FAQ». В общем тут есть над чем подумать и как использовать.

Отдельного упоминания заслуживает возможность расширения записей. Здесь я считаю можно взять за основу таблицу «postmeta». То есть каждая запись может иметь любые дополнительные параметры (метаполя). Нужно добавить еще и menu_order (для указания своего порядка) и slug (короткая ссылка) для тех полей, которые могут передаваться в URL, например метки. В идеале можно было бы добавить еще и тип поля, чтобы можно было сразу выполнять форматирование вывода (например «link» для ссылок), но тут нужно еще подумать.

search - поиск

Этот тип ничем не отличается от WordPress. Только я думаю, что нужно делать его более приличным, например подсвечивать поисковые слова.

tag - метка

В отличие от WordPress, где сейчас используется таксономия, я считаю, что метки можно безболезненно добавить в виде метаполей. Теоретически таксономия интересней, но как мы видим из практики она используется только в случае рубрик и меток. Больше никто ничего так и не придумал. К тому же с WordPress возникла незадача, когда исчезла возможность указания меток на русском языке (на старых версия WordPress все работало как раз через метаполя). То есть я не вижу смысла связывать рубрики и метки воедино. Таким образом наши метки - это «postmeta». Соответственно вывод записей с указанными метками не представляет особых проблем.

Итоги

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

Так же я думаю, что нужен какой-то «нулевой цикл», где делается рабочая версия с базовыми возможностями, а после неё уже определяется что верно, а что нужно переделывать.