[Статья]

Немного предыстории:
Оффтоп

Недавно у меня стал вопрос выбора движка для нового проекта, в котором немалую роль будет играть социальный фактор (альбомы, соц.группы и т.д.). Было протестировано довольно много движков. Первый кандидат был SocEngine. Да красивый, да большое коммьюнити, но основная проблема – он торррмоз, подходит для проектов с посещаемостью до 1К онлайн одновременно. Есть проекты на нем с большей посещаемостью, но это уже не чистый SocEngine, там от него практически ничего не осталось. Все остальные движки социалок в открытом доступе (включая многие платные) оказались на порядок тормознутее. Поэтому пришлось вернуться к vB. Осталось выбрать какой именно движок выбрать от 3.8 или от 4.0. Я был сам удивлен результатами изысканий, но я действительно изменил свое мнение насчет кода 4-ки (конечно все в сравнении с кодом 3-ки, который я и так неплохо знаю). И как результат - я теперь точно знаю ,что для нового проекта будет использоваться движок 4-й булки.

4-ка довольно сырой продукт. Но это совсем не значит, что нерабочий и не значит что задумки разработчиков были плохие. Просто 4-ка еще не доведена до ума.

И теперь и само сравнение, вернее + и – API 4-й булки по сравнению с 3-й. Для тех, кто в танке – поясняю, это сравнение именно API (и что можно сделать с его помощью), а не сравнение готовых продуктов - форумов 3.8.х 4.0.х. И не столько сравнение, а сколько описание плюсов и описание того, что хотела сделать старая команда разработчиков (а ниже, что получилось или как обстоит ситуация в последней версии).

1. Новое API в vB 4 стало более читабельным и более универсально-расширяемым (полноценный MVC фреймворк ). Но недостаток нового API в том ,что по нему отсутствует какая либо документация. К тому же очень похоже на то, что переписать весь форум под новое API видать просто не хватило времени. Как следствие внутри файлов винегрет из старого и нового API. Что значительно увеличивает в некоторых скриптах расход памяти.
2. В новом API появилась нормальная система кеширования, параллельная стандартной системе датастора. Именно нормальная система с поддержкой TTL, а не урезанный датастор. Одно но – есть класс для работы только с базой, хотя при желании написать класс для поддержки любого другого кеша (ea,xcache,APC,memcached) дело 10-15 минут, и это похоже в планах у разработчиков судя по комментам в коде (если они не напишут, для себя я всегда написать успею). К тому же очень большая вероятность, что в будущем датастор тоже будет использовать новый класс кеша.
3. Новый шаблонизатор (темплейтер) и алгоритм работы с ним – это аналог всех стандартных php темплейтеров. И заменить его на свой при желании, не составляет никаких проблем. Как следствие в шаблонах можно полностью избавиться от eval-а, что очень важно на хайлоад сайтах. Вот в 3-ке полностью избавиться в шаблонах от eval-а не получится без изменения всех файлов (т.к. eval внутри файла скрипта, а не внутри класса шаблонизатора), минимализировать eval можно, но избавиться - нет. Например, с минимальными модификациями можно прикрутить smarty, quicky или любой другой темплейтер. И кстати конструкция vb:raw - зло, так никогда в булке не будет нормального и быстрого шаблонизатора (разрабы сделали ее для совместимости, т.к. не успевали все переписать)
4. Шаблоны разбиты на css-шаблоны и html-шаблоны (это конечно не столько API, а сколько архитектура продукта). HTML шаблоны стали значительно меньше из-за перехода на дивы, т.е. расход памяти при работе скрипта как следствие тоже будет меньше (качество этой верстки я не беру в расчет - я говорю о размере). Как следствие значительно уменьшается объем трафика при работе с форумом (css один раз брозер получил и все, он больше не будет дергаться при открытии страниц)

Как следствие (зная особенности API) в 4-ке можно получить столько же запросов сколько и в 3.8 (а иногда и меньше), плюс возможности изменения функционала в 4-ке на порядок выше и это не система хуков через eval, а готовые классы которые будут уже скомпилированы, т.е. никакого eval в момент выполнения скрипта. Типичный пример модуль поиска через sphinx, на 3-ке реализовано все на порядок хуже.
Для хаков подключающий только global.php 4-ка уже ничем не хуже 3-ки, т.к. по количеству запросов, расходу памяти и т.д. в данном случае (только один global.php) 3.8 и 4.0 идентичны.

Но все же 4-ку в данный момент нельзя использовать (без допиливания) под посещаемые ресурсы. Во первых - больший расход памяти (2 фреймворка одновременно однозначно больше потреблять памяти будут чем один из них). Во вторых – отсутствие в данный момент кеш класса для работы с PHP варкешами (xcache, ea, apc, memcached), как следствие уйма лишних запросов (особенно заметно в CMS-ке, где кеш по полному используется).
Но с другой стороны 4-ку разогнать на порядок проще, чем 3-ку. Т.е. для достижения одинакового результата в 3-ке надо вносить на порядок больше изменений в оригинальные файлы чем в 4-ке.

Также в 4-ке на порядок проще сделать отдельный продукт, по типу блогов или CMS со своей логикой ЧПУ. Хотя писать продукты на новом API довольно проблематично из-за отсутствия документации по нему.

P.S. То что все говорят что в новой булке нечитаемый код, то это только из-за того что новое API просто совсем другое – уже на порядок больше ООП, чем было раньше. В 3.8 все-таки больше процедурный стиль программирования, хотя и присутствуют классы.

P.P.S. На vbsupport-е постоянно холивары и обливание г..ом 4-ю булку, не хочется чтобы и этот топик превратился в еще один холивар.

Yoskaldyr добавил 08.05.2010 в 23:30
Вообще-то интересно мнение других кодеров, кто кодил под 4-ку и разбирался с кодом 4-ки т.к. все вышесказанное, только лишь мое мнение, у кого-то может быть совсем противоположное

Судя по тому что вообще нет комментов, то похоже код 4-ки никто и не смотрел...

Yoskaldyr, почему, пробегался, но писать ещё полноценных больших продуктов под неё не приходилось.

Originally Posted by Yoskaldyr

похоже код 4-ки никто и не смотрел

смотрел

Originally Posted by Yoskaldyr

постоянно холивары и обливание г..ом 4-ю булку, не хочется чтобы и этот топик превратился в еще один холивар.

..........................

Могу высказаться в защиту 4ки, ибо достаточно ее поковырял
Да, код местами кривоват или попросту не дописан, т.к. писалось все из под палки и подгонялось в сроки. В частности, как я уже говорил с Yoskaldyr, мне не понравилось объединение двух движков в один. Я не говорю, что это плохо, а то как это сделано. Многочисленный классы, контроллеры, абстрактные методы (и классы) - ООП рулит, не спорю, просто теперь, чтобы добыть какой нибудь запрос приходится тратить уйму времени, чтобы найти нужный класс, метод, контроллер, тип и т.д. Возможно это из-за отсутствия документации на 4ку, однако, это, опять же, косяк "vBulletin Solutions, Inc.".
В остальных случаях код вполне читаем и понятен, даже удобнее чем в 3ке. И мне в принципе понравился шаблонизатор, по крайней мере он теперь проходит валадицию в прогах и его можно форматить С ccs тоже хорошая фишка. Так что можно сказать, что плюсов больше, нежели минусов

Originally Posted by Yoskaldyr

можно полностью избавиться от eval-а, что очень важно на хайлоад сайтах

с чего вы взяли что eval в булке это зло?

Originally Posted by m0rbid

с чего вы взяли что eval в булке это зло?

читаем внимательно мое сообщение, а именно, я делал акцент именно для хайлоад сайтов. Я не говорил что вообще eval зло, я говорил зло в шаблонах.

Т.е. зачем каждый раз при отображении компилировать одно и то же??? Не зря же делают опкод кешеры (и это уже стандарт дефакто для хостингов - ea, xcache, zend). Как раз для того что бы не парсить каждый раз php код в момент выполнения. Eval же это и есть парсинг кода независимо от опкод кешера.
Для примера, перенос хуков и шаблонов в файлы у меня ускорил генерацию главной страницы в 1.5 раза (полностью отказаться от eval-а в 3-ке нельзя, но уменьшить количество eval кода можно)

Originally Posted by Yoskaldyr

Т.е. зачем каждый раз при отображении компилировать одно и то же??? Не зря же делают опкод кешеры (и это уже стандарт дефакто для хостингов - ea, xcache, zend). Как раз для того что бы не парсить каждый раз php код в момент выполнения.

вам в любом случае придется парсить шаблоны в момент выполнения. Ибо они в бд лежат.
попросту говоря
Посмотрите функцию fetch_template в третей булке.

$tpl = mysql_fetch_array(mysql_query("SELECT..."));
eval("$tpl");

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

Originally Posted by m0rbid

вам в любом случае придется парсить шаблоны в момент выполнения. Ибо они в бд лежат.

у меня нет - все берется из кеша (шаблонов нет так много, чтобы постоянно дергать их из БД)

Originally Posted by m0rbid

Посмотрите функцию fetch_template в третей булке.
$tpl = mysql_fetch_array(mysql_query("SELECT..."));
eval("$tpl");

Почти, так.
Только вот eval идет для того что возвращает функа fetch_template и это совсем не значит что это будет браться из базы.
Вот почему я и говорю что в 3-ке нельзя полностью избавиться от eval-а без переписывания всех скриптов, т.к. eval в них, в 4-ке же можно - используя другой класс.
Рассказывать как я реализовал в 3-ке я не буду, т.к. это решение стоит денег и больших (хотя там все просто, но почему то никто не любит включать мозг при чтении кода и написании). Но в результате время eval-а сведено к минимуму, как с хуками, так и с шаблонами без изменения исходного кода. И это позволило значительно уменьшить время генерации страницы и разгрузило сайт. И выигрыш тем больше, чем навороченнее стиль и чем больше объем шаблонов.
А решение действительно из разряда - "а почему никто больше так не делает???". Хотя может и есть у кого подобное, только вот никто светить не будет однозначно. К тому же это решение просто неэффективно для небольших форумов - нужно только для очень крупных форумов с большой посещалкой.

Мне в четверке понравился класс vB который позволяет сразу глобализировать $vbulletin, класс не сложный но все же удобней стало.
Пример:

PHP Code:

require_once(DIR . '/includes/class_bootstrap_framework.php');
vB_Bootstrap_Framework::init();

//VB4
function my()
{
             return vB::$vbulletin->options['bbtitle'];
}

//VB3
function my()
{
             global $vbulletin;
             return $vbulletin->options['bbtitle'];
} 


и все пожалуй