nSite

Мы ответственно относимся к вопросам стабильности работы системы после её установки на сайт клиента. К сожалению, ни Drupal, ни Joomla этого не могут обеспечить. Обратной стороной их популярности является то, что в их основных модулях постоянно находят уязвимости, и если не обновлять регулярно систему, то через полгода сайт превратится в проходной двор, куда сможет зайти любой желающий.

Ни в коем случае не отрицая положительных качеств Drupal и Joomla мы видим их применение только на сайтах, которыми постоянно занимается хороший php-программист. А просто установка системы на сайт, без дальнейшей постоянной поддержки, это на наш взгляд – безответственное действие.

К тому же притчей во языцех стало качество дополнительных модулей для этих бесплатных CMS. Обычно их делают начинающие программисты и так, как захочет их левая нога. В результате, посмотрев на хранилище модулей для этих систем, можно удивиться их разнообразию. Но когда начнёшь копать глубже окажется, что большинство этих модулей прокомментированы примерно следующим образом: “Отличный модуль, давно такой искал. Только вот что-то у меня он не работает совсем”.

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

Общий принцип работы системы был задокументирован ранее. Теперь поговорим немного о шаблонизаторе.

В моём представлении каждая страница сайта состоит из виджетов, связанных между собой некоторым оформлением (дизайном). Вот примеры виджетов:

1. главное меню
2. меню с подпунктами
3. баннер
4. форма авторизации
5. корзина
6. область основного контента страницы
7. и т.д.

Почему я выделил слова область основного контента страницы полужирным шрифтом?
Дело в том, что этот момент ещё не очень хорошо продуман. Скорее всего заголовок H1 и путь к этой странице будут выделены в отдельные виджеты. А вот с листалкой уже не так очевидно, да ещё может возникнуть потребность выводить на одной странице несколько элементов контента (например, парочку фотогалерей и один текст).

Какие же роли играют Шаблонизатор и Виджет?

• В Шаблонизаторе определяется в каком месте будет выводиться тот или иной Виджет.
• Виджет определяет как именно он будет выводиться и будет ли вообще он при заданных условиях отображать себя.

Такая схема позволяет разрабатывать виджеты совершенно отдельно от реального приложения и добиться их простого повторного использования. Однако она же и накладывает некоторые ограничения. Например: view-скрипт виджета должен идти с ним в одном комплекте, и для каждого момента в нём должны быть прописаны свои css-классы.

После рассмотрения общей схемы функционирования CMS, приступаем к её реализации. Однако для этого необходимо сделать один предварительный шаг.

Этап 0. Конфигурация системы.

В нынешней версии CMS конфигурация системы задавалась в php-массивах. С точки зрения быстродействия – это оптимальный вариант реализации конфигурации системы, но редактировать такую конфигурацию не очень удобно. Кроме того в новой версии системы файлы конфигурации будут разнесены по каталогам соответствующих модулей, что ещё больше затруднит их редактирование, если они останутся в виде php-файлов.

Выход я вижу в использовании Zend_Config_Ini. Этот модуль позволит хранить конфигурацию системы в ini-файлах. Однако, для повышения быстродействии скриптов, не будем вызывать этот модуль при каждом старте системы. Сделаем скрипт, который будет компилировать все ini-файлы в один php-файл конфигурации, аналогичный файлу конфигурации в нынешней версии CMS.

Для реализации такой схемы конфигурации потребуется два модуля

1. Компилятор ini-файлов в php-файл.
2. Редактор ini-файлов (что-то вроде реестра в Windows) – такой редактор потребуется для некоторых модулей сайта, настройки которых нужно будет менять в процессе функционирования сайта.

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

Сосредоточимся на компиляторе ini-файлов в php-файл. Вот задачи этого модуля:

1. Обойти все подкаталоги application, в котором хранятся все модули системы, и составить список ini-файлов в соответствии с их размещением в каталогах. Названия каталогов будут использоваться для доступа к этим переменным.
2. Подготовить текстовую переменную, которая затем будет записана в файл /application/config.php. В этом файле будет класс Cfg, предоставляющий доступ только чтения ко всем переменным конфигурации. Класс будет реализован по паттерну Singleton.
3. Считать каждый ini-файл в Zend_Config_Ini и распарсить его в php-файл.

Таким образом наши данные будут храниться в подготовленном php-классе, который будет быстро считываться во время выполнения основных скриптов.

Новая инициатива от Google. Теперь на серверах Google будут размещаться все популярные javascript-библиотеки. Больше не придётся думать о кэшинге, gzip-е, хостинге, трффике и тд. Сейчас объявлено о размещении Prototype, Script.aculo.us, jQuery, Dojo и MooTools.

Можно подключить нужный скрипт напрямую, например:

HTML:

1. <script src=»http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js»></script>

или можно использовать гугловскую библиотеку для подгружения нужных скриптов. Например:

HTML:

1. <script src=»http://www.google.com/jsapi» type=»text/javascript»></script>
2. <script type=»text/javascript»>
3. google.load(«jquery», «1.2.3″);
4. google.load(«prototype», «1.6″);
5. google.load(«scriptaculous», «1.8.1″);
6. google.load(«mootools», «1.11″);
7. google.load(«dojo», «1.1.1″);
8. </script>

Можно задавать нужную версию как параметр, а так же запрашивать несжатую версию библиотеки:

HTML:

1. <script src=»http://www.google.com/jsapi» type=»text/javascript»></script>
2. <script type=»text/javascript»>
3. google.load(«jquery», «1.2.3″, {uncompressed:true});
4. </script>

1. На входе скрипт имеет URL и $_REQUEST
2. Аутентификатор
3. Роутер
4. Авторизатор
5. МОДУЛЬ СТРАНИЦЫ
6. Шаблонизатор
7. Виджеты

Аутентификатор
Определяет пользователя, открывающего страницу.

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

Авторизатор
Проверяет достаточно ли прав у пользователя для отображения этой страницы.

МОДУЛЬ СТРАНИЦЫ
Модуль, определяемый Роутером, для получения основного контента страницы.

Шаблонизатор
Заполняет предложенный шаблон контентом, который сгенерировал Модуль страницы. Определяет состав виджетов на странице и вызывает модули Виджетов, получая от них информацию, необходимую для вывода на странице. После получения информации от Виджетов, отображает сгенерированную страницу.

Виджеты
Активные иконки, меню сайта, баннер, топ новостей, опрос и т.п. – всё это виджеты, которые существуют по своим законам и программируются отдельно.