MaxSite CMS. Типы страниц/данных
08-01-2008Reading time ~ 5 min.PHP 36142
Продолжим наши изыскания. ;)
На сей раз речь пойдет о типах выводимых страниц. Если взять за аналогию 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:
- Входящий адрес передается нашему базовому классу-контролеру.
- Происходит подключение основных функций CMS.
- Автоматически выполняется нужная функция контролера, которая по-сути и определяется типом страницы.
- Каждый тип страницы имеет свой вьювер (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». Соответственно вывод записей с указанными метками не представляет особых проблем.
Итоги
Если с типами страниц/данных особых проблем нет, то что касается структуры БД, вопросов пока много. Скажем типы записей и рубрики по сути будут иметь одну структуру таблиц. Поэтому здесь нужно еще решать как поступить.
Так же я думаю, что нужен какой-то «нулевой цикл», где делается рабочая версия с базовыми возможностями, а после неё уже определяется что верно, а что нужно переделывать.
Не забудьте прикрепление поста сделать ;)
Интересно будет на вашу кмс взглянуть, а когда будет первый бета-релиз? И будет ли ваша кмс опенсорс?
Вы про attachment?
Что то мне это уже сильно напоминает ЮМИ ))))
Наверное имелись в виду файлы, подгужаемые к старницам, которые предлагаются для скачивания посетителям...
Я насчет блогрола хочу уточнить - надо сразу делать чтобы можно было разные группы ссылок выводить в разных местах. В вордперессе это трудно без всяких хаков и чтения кодекса. Я имею в виду рубрики блогрола - чтобы можно было все расставить в разных местах. Может мое замечание и неуместно на столь ранн5ем этапе программирования, но а вдруг это надо сразу закладывать в фундамент! :cool:
Пока ничего более умного, кроме как поучаствовать в рекламе RSS, предложить не могу:
" Так, с мозгами или без - подпишись на ...":smile:
Я имел ввиду, чтобы пост отображался все все время первым.
C рубриками блогрола нужно будет подумать. Замечание ценное :)
С прикреплением теперь понял. Планирую, что в самом шаблоне можно будет выводить произвольную информацию. Данные для вывода будут получаться уже в само файле шаблона, поэтому можно будет варьировать ими как угодно.
Макс, а по поводу закрепленных топиков, то тут я имею проблему с вордперсом - надо постараться избежать этого в твоей разработке. Например, есть необходимось выводить какую-то информацию в разделах (рубриках) - через стандартные дескришны рубрик это удается плохо реализовать, даже выбив от Юрия из Харькова написание плагина для поддержки html-гетов в них :)... Ввобщем, надо что бы юзер мог создать для описаний (прикрепленных топиков, которые можно закрепить где угодно и на какой-угодно странице) свой тип страниц, которые бы потом можно было выводить по айдишнику в нужном месте/ воть/надеюсь не заплутал...
Дополню свой предыдущий комент разьяснением. Например, я вот никак не сделаю нормальным сайт http://environment.org.ua/ - там у меня есть рубрики по регионам, по темам, и по обьектам природно-заповедного фонда/ И вот когда человек нажимает, скажем, на раздел Природно-заповедный фонд, перед постами данной рубрики должно быть описание с картой там,фотками. И було бы удобно, если бы эти описания можно было создавать не спомощью шаблонов для каждой категории, а также, как и обычные странцы - в админке, только чтобы можно было обозначить сразу на месте, что это не страница, а описание к такой-то категории. Все!
И еще момент, который не позволяет стать класной цмсокй вордпресу с точки зрения юзабельности - создание динамических меню, в т.ч. вложенных, раскрывающихся и т.д. Надо бы еще и настройки всякие иметь - сортировка, исключения, произвольные менюшки...
Да, я понял. В принципе про типы записей об этом же. Это вроде как вторая рубрика получается.
Тут еще такой нюанс: в WordPress'е данные формируются где-то внутри и просто передаются в шаблон для вывода. У меня же будет так, чтобы данные формировались в самом шаблоне. Это как раз для таких случаев, когда вебмастеру нужно получить не стандартный вывод, скажем последних записей, а например просто кукую-то одну страницу, или список рубрик, или типов, или меток и т.д. То есть абсолютно чего угодно. Даже если в CMS не будет предусмотрено для этого отдельной функции, то можно будет выполнить свой SQL-запрос и внести полученные данные в цикл вывода. Так что все будет работать без лишних ухищрений.
Боюсь, что вас несколько кренит в блоги.
Как проверку на универсальность той или иной функции, попробуйте примерить её уместность в четырёх типичных сценариях: CMS, форум, blog и wiki. Если окажется уместной и полезной - вы на правильном пути к универсальности, если уместна только в одном случае - вы начинаете специализировать. Применительно к приведённой мною цитате, в случае CMS или Wiki, авторство может быть совершенно никому не интересно, т.к. материал зачастую подаётся от лица реурса, а не конкретного человека.
Mixa, а счастье есть: http://www.laptoptips.ca/projects/category-description-editor/
Блин, вот так всегда, sonika, мучил всех на форуме, куча вариантов, как сделать через ж..., а теперь оно появилось, нате! Спасибо!
Ну в принципе, ничего плохого в этом нет. :) Я исхожу из того, что базовый функционал должен быть именно блоговским. То есть как минимум быть не хуже WordPress. А за счет более гибкой внутрнней архитектуры, можно будет осуществлять вывод и как обычный сайт, и как вики и может быть даже как форум. Тут главное, чтобы не было проблем с подключением дополнений.
У меня сейчас рабочая версия, которая не обращаясь к БД уже выполняет первоначальные функции по определению типа страниц и позволяет подключать любые другие. Постараюсь выложить схему работы CMS, чтобы наглядно объяснить свою мысль. :)
Вы еще пишите CMS? Тогда мы идем к вам!