Организация данных в MaxSite CMS

Предположим у нас есть адрес http://site.com/hello. Вопрос - что именно должен вывести «движок»? Может это страница? Или рубрика? А может быть метка? А вдруг это какой-то отдельный файл hello.php в каталоге шаблона?

Чтобы решить данный вопрос система должна определить что за тип данных требуется вывести. Например мы можем считать, что hello - это страница. Тогда тип данных будет «page». А можем условиться, что это рубрика. В этом случае тип данных будет - «category». Если вы разбирались в WordPress, то знаете, что в нем используется несколько предопределенных типов данных: страницы, записи, рубрики, метки и несколько «служебных» вроде дат.

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

Понятно, что в полноценной CMS данный подход не годится - необходимо сделать так, чтобы можно было переопределять адрес под свои задачи. Скажем http://site.com/hello - это должна быть рубрика. Например в MaxSite CMS вполне комфортно могут существовать с короткой ссылкой (slug) «hello»: страница, рубрика, метка и отдельный файл hello.php.

Таким образом в MaxSite CMS принято явно указывать тип данных. Например:

• http://site.com/page/hello
• http://site.com/category/hello
• http://site.com/tag/hello

Во всех этих адресах явно указан тип данных, что полностью исключает неопределенность.

Если говорить строго, то в MaxSite CMS, если явно не указан тип данных, вначале будет произведен поиск страницы с этим slug; если таковой нет, то ищется рубрика. И только после этого возвращается «page_404», что тоже является типом данных (который просто не известен системе).

Теперь мы подошли к важному моменту, о который частенько спотыкаются привыкшие к WordPress. :) Поскольку WordPress сам анализирует адрес, то разработчику даны лишь несколько предопределенных функций: is_page, is_post, is_category и т.п. То есть вы не знаете почему адрес именно page, а не tag.

В MaxSite CMS все гораздо проще - есть одна функция is_type, где аргументом указывается проверяемый тип:

• is_type('home')
• is_type('page')
• is_type('category')
• is_type('tag')

Но, в отличие от WordPress, в MaxSite CMS используется простое определение типа: по адресу.

Если говорить точнее, то речь идет о т.н. сегментах URL. Я ничего не изробретал, а просто использовал CodeIgniter, который и работает по этой схеме. Если говорить совсем строго, то CodeIgniter работает на основе контролеров (class) и методов (function). После этого можно указать параметры функции. Грубо говоря, когда мы указываем сайт/page/hello, то управление передается дефолтному контролеру maxsite (он по-умолчанию, поэтому его не указываем), потом функции page с параметром hello. Это очень упрощенная схема и если вас интересует больше подробностей, то можно обратиться к руководству пользователя.

Если говорить о технической реализации, то адресация в MaxSite CMS работает по следующему алгоритму. В контролере все запросы сразу адресуются методу _remap. Уже в нем происходит анализ первого параметра (в нашем случае «page»). Если это какой-то предопределенный тип, то управление сразу переходит к вьюверу (шаблону). Если же это неизвестный тип, то происходит переход к методу page_404 и в нем проверяется файл тип.php, который может содержать описание своих типов данных. Если такого файла нет, то ищется такой slug в записях, потом в рубриках и если и они не найдены, то ставится тип «page_404» и управление передается в шаблон.

Можно ли самому придумать свой тип данных? Конечно. Для этого достаточно поместить в каталоге контролера php-файл с этим же именем. Система автоматом подхватит этот файл. Для примера именно так и реализован тип данных «contact». Не поленитесь, посмотрите, там всего одна строчка кода. Аналогично можно создавать свои типы данных.

В случае «contact» будет такой адрес: http://site.com/contact

Естественно в MaxSite CMS есть несколько предопределенных типов, которые прописаны в контролере. Тут я руководствовался только тем фактом, что они так «исторически сложились». При желании вы можете их свободно переписать, правда ценой потери совместимости с некоторыми плагинами.

Теперь, когда мы определились с понятием «тип данных», давайте рассмотрим т.н. сегменты URL. На самом деле это очень просто. Каждый адрес система (точнее CodeIgniter) раскладывает на массив. Например адрес http://site.com/page/about имеет такие сегменты (обратите внимание, что нумерация начинается с единицы):

[1] => 'page'
[2] => 'about'

То есть теперь, для того, чтобы создать «ветвистое» приложение мы можем анализировать сегменты и в зависимости от результата, подключать нужные файлы для вывода. Например мы хотим в шаблоне выводить файл hello.php. Для этого в шаблонном index.php (он главный) указываем условие:

if (mso_segment(1) == 'hello') require(hello.php);

Таким образом по адресу http://site.com/hello и будет переход наш файл. Обратите внимание, что мы не делали отдельный тип данных в контролере - нам с лихвой хватило одной строчки условия в шаблоне. Это показывает, что в MaxSite CMS очень просто работать с любыми типами данных.

Поскольку мы заговорили о шаблоне, то сразу скажу, что в MaxSite CMS существует только одно правило для любого шаблона: должен быть файл index.php. Что с ним делать решает программист.

Понятно, что выводить «Hello, world!» слишком примитивно, поэтому я предложил дополнительные (но не обязательные!) правила. Если вы давнишний читатель моего блога, то наверняка вспомните мои изыскания по «идеальному» шаблону для WordPress (например в Rioni). В нем я использовал аналогичную схему, правда ограничения WordPress гораздо жестче.

Итак, в шаблонном index.php лучше всего размещать «диспетчер» подключаемых файлов. В этом файле указываются условия и подключаются соответствующие файлы типа (сегментов) и т.д. Заглянув в шаблонный index.php вы увидите несколько строчек:

if ( is_type('тип') ) require('файл.php')

или

if ( mso_segment(1) == 'сегмент' ) require('файл.php');

Тут еще один маленький момент. В MaxSite CMS получение и вывод данных переложено на сторону шаблона. Это принципиально отличается от WordPress, который анализирует URL, определяет параметры запроса, получает данные из базы и только после этого передает управление в шаблон.

В MaxSite CMS по-другому: происходит анализ URL, определяется тип данных и сразу управление передается в шаблонный index.php. Сами же данные получаются и выводятся на уровне шаблона. Такой подход позволяет: во-первых добиться максимальной гибкости, во-вторых значительно упрощает «ядро» системы и в-третьих уменьшает ресурсоемкость - подключаются только те функции, которые действительно необходимы.

Если вы умеете делать шаблоны для WordPress, то у вас не будет особых сложностей и с созданием шаблона для MaxSite CMS. Просто вам нужно «отключиться» от ограничений WordPress с его надуманными is_home, is_page и предопределенных файлов в шаблоне: page.php, single.php, home.php и так далее. В MaxSite CMS просто нет таких ограничений.

Скорее всего вам будет интересно, как же тогда происходит получение и вывод данных. Здесь необходимо понять строение шаблона.

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

Любой шаблон представляет собой HTML и соcтоит из «постоянной» и «изменяемой» частей. Например в «каркасе» (таблица, div'ы) - какие-то свои элементы оформления и т.п. Переменная, изменяемая часть - это тексты, например для главной - это одно, для рубрик - другое и т.д. В любом шаблоне можно выделить эту самую переменную часть.

Дальше просто. Мы делим шаблон на несколько файлов, которые подключаются примерно так:

require('main-start.php');

получение и вывод данных

require('main-end.php');

Вот это и есть схема любого файла типа/сегмента. Предположим, что это файл home.php (главная страница). Подключили мы его в index.php:

if ( is_type('home') ) require('home.php');

В home.php мы подключаем main-start.php, потом выводим переменную часть (получаем данные, формируем вывод страниц), потом main-end.php.

Файлы main-start.php и main-end.php могут разбиваться тоже на свои файлы, но главное, что в них и содержится HTML-каркас шаблона. Еще, я, например, предпочитаю выделять в отдельные файлы header.php, footer.php, а также sidebar.php.

Если есть желание, то вы можете обратиться к лекциям в Центре помощи, где я подробно рассказываю о создании шаблона. Также посмотрите входящий в комплект шаблон «Clouds».

Вот небольшая схема по данному примеру:

Как видите, мы довольно легко отделили html-структуру от более сложного вывода данных типа. По большому счету, если вы делаете шаблон, то его и следует делать именно так. Всё из-за того, что в шаблонах MaxSite CMS можно свободно использовать файлы другого шаблона. Таким образом вы можете в своем шаблоне использовать файлы типов шаблона «Default». Чтобы увидеть это на практике, обратитесь к шаблону «Clouds» - он сделан специально с «учебным» уклоном. :)

В завершении, подведу краткие итоги.

• В MaxSite CMS используются типы данных.
• Типы данных определяются на основе URL.
• Автоматически формируется массив сегментов.
• Можно использовать свои типы данных или свои сегменты.
• После контролера, управление передается в шаблон.
• В шаблоне должен быть index.php. В этом файле подключаются файлы типов.
• Шаблон разделяется на main-start.php и main-end.php.
• В шаблонах можно использовать файлы типов из другого шаблона.
• Получение и вывод данных осуществляются в шаблоне в файле типа.