Продолжаем вводную часть второго cogear. Сегодня речь пойдет по файловой структуре.
Правильная организация внутренних компонентов позволяет сделать расширяемой и легко обновляемой. Когда я слышу удивленное «Как, ты работаешь с Wordpress?», всегда улыбаюсь, потому что большая часть холиваров возникает на пустом месте. Я работаю с теми системами, которые мне интересны, и бытие мое как автора cogear совершенно не препятствует мне делать сайты на других системах. Исследуя их, я нахожу сильные и слабые стороны, и как следствие, видение идеального движка расширяется и трансформируется на разных стадиях.
В процессе разработки cogear² выбор пал на синергию занимательных концепций в веб-программировании:

• Пространство имен классов и автозагрузка. Zend Framework
• Мультисайтовость. Drupal
• Концепция «слоеного пирога». Kohana

О том, как три указанных особенности переплелись друг с другом в новом когире, мы с вами и поговорим.

Пространство имен классов и автозагрузка

Эпоха PHP-функций include и require канула в лету с пришествием автозагрузки. Всем известно, что данные функции тормозят и отягощают любой скрипт. Автозагрузка вошла в мир PHP-кодинга с версией языка 5.1.2 вместе с SPL (Standart PHP Library), о которой мы неоднократно будем беседовать в ближайшем будущем.
В чем ее суть? В момент инициализации объекта из класса по-очереди запускаются зарегистрированные через функцию spl_autoload_register методы, которые получают на входе имя вызываемого класса. Внутри же методов, назначенных на автозагрузку, мы можем самостоятельно выстроить логику подключения файлов, и расходы на внутренние включения будут в разы меньше, чем при открытых инклудах в контексте программы.
В Zend Framework реализована отличная идея совмещения автозагрузки с пространством имен файлов.
Вызывая объект класса, к примеру, Zend_Config_Yaml скрипт заменяет нижнее подчеркивание на разделитель директории, дописывает на конце расширение исполняемого файла .php и ищет от корня папки с фреймворком файл Zend/Config/Yaml.php. Причем внутри файла сам класс носит точно такое же название — Zend_Config_Yaml.
Стоит заметить, что потенциально здесь есть возможность использования пространства имен, доступные начиная с версии PHP 5.3, но для совместимости с большей частью машин, работающих на PHP 5.2, мы выбрали схему Zend Framework, дополнив и расширив ее. См. концепцию «слоеного пирога».

Мультисайтовость

Цели и задачи были поставлены следующие:

• Хранение ядра, общего набора шестеренок отдельно от конфигурации конкретного сайта.
• Создание сколько угодно большого количества сайтов на одной установке движка.
• Простота обновления сущности движка, без ущерба для привязанных к ней сайтов.

Наиболее удачное решение подобных задач продемонстрировано в Drupal, который и при написании первой версии cogear вдохновлял своей продуманностью, но огорчал высоким уровнем вхождения в круги разработчиков.
Обратите внимание, что все папки заданы в index.php константами, что рождает бесконечное число вариаций на тему, где могут быть расположены

• Ядро
• Библиотека Zend Framework
• Папка с шестеренками для всех сайтов
• Папка для сайта по-умолчанию
• Папка для текущего сайта

Чем удобно данное решение? Представьте, вы решили создать массовый блогохостинг. Ядро выносится за пределы установки, ровным счетом как и Zend Framework. Также вы можете вынести в специальное место папку с шестеренками для всех сайтов (базовый комплект), а в папку под конкретный сайт переместить папку с шестеренками. Можно реализовать любой удобный вариант, даже тот, который живет в первой версии cogear.
Для наглядности нарисовал иллюстрацию:

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

Концепция «слоеного пирога»

Здесь, где встречаются Zend Framework, Drupal и Kohana, и начинается самое интересное.
Включаем воображение, трансляция пошла.
Вызываем класс MyFirst_Gear, который символично ведет нас к первой создаваемой шестеренке. Автозагрузчик преобразует его в путь MyFirst/Gear.php и начинает поиск шестеренки. Тут-то и начинается самое интересное.
Сначала он идет в папку с шестеренками текущего сайта, потом с общими шестеренками, а потом в ядро.
Еще разок, шестеренки сайта → все шестеренки → ядро.
Загружен будет первый найденный класс.
Таким образом вы можете переопределять компоненты движка на любом уровне.
Хотите расширить базовое представление о шестеренке User? Не вопрос, можете создать точно такой же класс шестеренки в папке своего сайта, а еще лучше — отнаследоваться от нее и подменить переменную движка $cogear->user собственным улучшенным классом во время инициализации шестеренки. О таких удобных ходах расскажу в следующих статьях.

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

Тема следующего урока звучит так: «Шестеренка — наше все» или «Все есть шестеренка».

Хорошего дня!