“- Какой самый живучий паразит? Бактерия? Вирус? Кишечный глист? Идея. Она живуча и крайне заразна.” Х.ф. Начало
Все вы знакомы с этим парнем. Неважно как его зовут и сколько ему лет. Он web разработчик. На протяжении многих лет трудился на благо интернета и делал хорошие, нужные сайты. А еще наш герой коллекционер. Кто-то собирает марки, кто-то – монеты, а он – «велосипеды». Да, да – именно «велосипеды». Каждый раз, когда перед ним появлялась новая задача, парнишка воодушевленно ее решал и готовое решение складывал в отдельную папочку. Так за время работы – накопилась огромная коллекция разнообразных двух, трех, а иногда и десяти колесных «транспортных» средств. И он не давал им ржаветь. Для каждого нового сайта использовал то или иное собственное решение, бережно копируя его из общей папки в папку проекта. А если вдруг находил, какую неисправность (ну с кем не бывает) – исправлял и тут же переносил изменения на все сайты… И он был почти счастлив. Почему почти? Да потому, что со временем сайтов стало настолько много, что невозможно было уследить на каком из них какая версия «велосипеда» сохранена. В конце концов он совсем запутался и уже готов был сдаться, как вдруг появилась идея. Именно о ней и пойдет речь в этой статье.
Представьте себе сервер, на котором хранятся все Ваши библиотеки. И вы с любого сайта можете в любой момент к этому серверу подключиться и скачать нужный компонент. Представьте себе, что на этом сервере лежат не только Ваши библиотеки, а еще и библиотеки Ваших друзей. Все сгруппировано по разделам. Вы можете собрать собственную библиотеку из любых сторонних компонент и использовать на своем проекте. Вам нравится PDO за то, что он позволяет одними и теми же функциями работать с разными базами данных? А теперь представьте себе, что такая же свобода у вас есть во всем! Компоненты библиотеки связаны интерфейсами и Вы можете простым переключением в конфиге, ничего не меняя в коде сохранять ваши thumbnail не в локальной папке, а на S3 или переключаться между системами кеширования…
Все это мечты. Но их можно реализовать. Попробуем?
Начнем с малого – удаленный ftp сервер на котором расположена библиотека. В эту библиотеку покладем компоненты – php классы. Для того, чтобы не путаться и иметь возможность апдейтить изменения каждому компоненту присваиваем версию и алиас. По алиасу – будем доставать находить компоненту в библиотеке, а по версии – принимать решение нужно ли апдейтить локальную копию компоненты.
Все это записываем в index.php и выкладываем в корень библиотеки:
return array(
// DB
'db/CPDO' => array(
'version' => '1.0',
'path' => 'db/CPDO.php'
),
// IMG
'img/CThumb' => array(
'version' => '1.0',
'path' => 'img/CThumb.php'
),
'img/CLocalThumb' => array(
'version' => '1.0',
'path' => 'img/CLocalThumb.php'
),
'img/CS3Thumb' => array(
'version' => '1.0',
'path' => 'img/CS3Thumb.php'
),
);
Теперь, подключившись к этому ftp мы можем скачать index.php и узнать какие компоненты в этой библиотеке находятся.
(Для примера некоторая часть моей библиотеки: github.com/wolflingorg/wlibrary)
Как настроить компоненты? У каждого сайта есть конфигурационный файл. Предположим что он называется main.php и содержит в себе:
return array(
'name' => 'Название нашего сайта',
'baseHost' => 'domain.com',
'runtimeDir' => dirname($_SERVER['SCRIPT_FILENAME']) . '/runtime/',
'components' => array(
'db' => array(
'alias' => 'db/CPDO',
'params' => array(
'mysql:host=localhost;dbname=mydb',
'root',
''
)
),
),
'libraries' => array('ftp://user:password@library.domain.com'),
//'libraries' => array(dirname($_SERVER['SCRIPT_FILENAME']) . '/library/'),
);
Обычный хеш массив (похожий на таковые в разных фреймфорках), в котором содержаться данные о сайте, ссылка на библиотеку (libraries) и компоненты, которые мы собираемся использовать (components). Для каждой компоненты опишем алиас – для поиска по библиотеке и параметры, которые нужно передать в конструктор в момент инициализации компоненты.
Как использовать компоненты? Вот тут начинается самое интересное. Нам нужен единый механизм, который свяжет в себе абсолютно все компоненты системы. Поможет найти компонент в библиотеке, скачает его в локальную папку (чтобы каждый раз не лезть на ftp) и работать с компонентой.
Тут тоже ничего сложного нет. Ваш покорный слуга взял на себя смелость и реализовал этот механизм ( github.com/wolflingorg/w ). Разумеется, он нуждается в доработке. Но для примера сойдет.
Подключаем его к нашему сайту и инициализируем application:
// массив с конфинами
$config = dirname(__FILE__) . '/config/main.php';
// подключаем W
$W = dirname(dirname(__FILE__)) . '/w/W.php';
require_once $W;
// инициализируем приложение
W::createApplication($config);
Теперь, к любой компоненте можно обращзаться так: W::app()->название_компоненты
Кроме того, научим «W» работать с локальными библиотеками и организуем некоторые исключения – если в 2 библиотеках встречается один и тот же алиас – то в библиотеке останется тот, который был добавлен первым.
Ну и конечно начнем использовать компоненты:
$STH = W::app()->db->query('SELECT name FROM my_friend');
$STH -> setFetchMode(PDO::FETCH_ASSOC);
while ($row = $STH -> fetch()) {
echo $row['name'] . '<hr>';
}
Все это только пример. Некая демонстрация того, что реально можно сделать. И наш герой заразился идеей создать подобный сайт. Подумать только, это сможет заменить ему любой фреймворк. Ускорить разработку в разы и собрать наконец все свои «велосипеды» в одну кучу.
Если Вы узнали в этом герое себя – буду признателен за помощь в развитии идеи.
А если нет – то конструктивная критика тоже приветствуется.
Автор: wolfling
