Сборка Zend Framework

[@BarsMonster]

Цифры в студию, насколько это ускоряет работу? :-)
С eAccelerator-ом в обоих случаях конечно.

[@va1en0k]

dklab.ru/chicken/nablas/50.html тут есть. Котерову я склонен верить :)

Я и сам чутка потестировал, но это для себя — даже не документировал. У меня числа чуть похуже, но это скорее из-за того что у меня там все-таки разное еще и происходит, а не только классы грузятся. Ну и запускаю я это хрен знает где на очень странно настроенной машине с кучей фигни. Как это все попадет на нормальный сервер — буду уже хвастаться или плакаться :)

По памяти: ab выдавал где-то 0.8 с Хотплагом, чуть меньше 0.1 без. Хотя может и вру. Давайте лучше Котеровским числам верить

[@va1en0k]

| 0.8 с Хотплагом, чуть меньше 0.1 без

наоборот, разумеется %)

[@homm]

Когда-то давно делал для подобного топика:

[@va1en0k]

Похоже, такой топик уже есть? Неприятно :)

[@homm]

Был. Я тогда не знал о тукенайзере в пхп, и require вырезал весьма криво, а переделывать не захотел. Кроме того, изучения Zend Framework после этого забросил, так и не написав на нем ни одного проекта. Скриптина лежит здесь, можешь использовать любую понравившуюся часть :)

[@va1en0k]

Спасибо
Я сначала думал вырезать через Zend_Codegenerator, но после исправления в нем второй ошибки решил перейти к дедовским методам )

[@mironoff]

что такое «тукенайзере в пхп»?

[@va1en0k]

token_get_all()

[@fog]

А почему с ZF не срослось? Перешел на другой фреймворк, или на другой язык?

[@homm]

Сначала на другой фреймворк (Kohana) и уже долгое время есть желание перейти на другой язык (Python+Django).

[@fog]

А чем Kohana больше понравился?

[@homm]

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

[@Fesor]

Kohana и мне нравилась, но сейчас как-то больше нравится YII…

[@Shumkov]

Простите а как вы получили такие результаты? У нас прирост производительности получился очень незначительный.

[@Rembish]

Что-то Ваше решение напоминает наколенкособранное — «похачил», «пофиксил». Не пробовали, коль уж занялись слиянием более аккуратно пропарсить структуру «без хаков» и «фиксов»?

[@va1en0k]

Я предлагаю так и сделать, просто может кто очень хочет этим заняться, или уже сделал, или есть готовое решение?
Еще там есть несколько фич, которые очень сложно сделать. Например, как избавиться от хака Zend_Loader? Унаследовать его? А как попросить _Autoloader использовать именно наш класс? И так далее.
В этом всём надо разбираться, а возможно, что ZF такие штуки пока не поддерживает. Чем больше я его использую, тем он оказывается недоделаннее — вот только что зааппрувил баг к ним в трекер :)

Поэтому я и сделал на хаках. Да, быстро и грязно. Но хватит один раз собрать HotPlug.php и всё, можно больше не париться, так что эти хаки неопасны и их можно в любой момент убрать, не опасаясь, что программа сломается.

[@Rembish]

Ну, товарищ, не пытайтесь найти всегда чьи-либо готовые решения, иногда приходится писать самому и руками. Если Вы рассказываете про решение, то постарайтесь сделать его универсальнее. Пока я вижу только может, а вдруг, а что если, может унаследовать и так далее. Иначе, Ваша статья рассказывает лишь о том, что я молодец — решил поставленную передо мной задачу. Хабр же, на мой взгляд, предполагает несколько другой масштаб предоставления информации — я нашёл решение, готов поделиться. Ваше решение грязное, увы и ах.

[@va1en0k]

Окей, теперь вы можете вполне обоснованно нажать на стрелочку вниз :)

[@egorinsk]

Еще одна причина не использовать ZF, слишком громоздкий, корявый и универсальный фреймворк, а судя по объему, авторы первоначально принесли свои идеи с явовских монстров.

[@chetzof]

Троллить надо с умом, учись сопляк у старших.

[@egorinsk]

Сам ты тролль, раз тебе всюду тролли видятся. ZF и правда громоздкий (не лень было отдельно делать обертки даже для функций типа include/is_readable и т д), и излишне универсальный (т к все компоненты могут использоваься отдельно или быть заменены на другие).

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

[@kykapa4a]

Занимаюсь этой же задачей в настоящий момент. Решение подобное предложенному вами исключил по причине отсутствия универсальности: надо создавать файл со списками классов, а это как-то криво. Добился того, что собирается только Zend Framework со всеми зависимостями и покомпонентно (иначе полная сборка существенно увеличивает расход памяти, а использоваться могут не все классы). Именно такой вариант считаю правильной сборкой в один файл, т.к. даже при обновлении надо будет всего лишь перезапустить скрипт с таким же набором опций. Готового ничего не находил (поэтому и решил взяться за задачу). Скоро причешу код, добавлю скрипту управление через консоль и выложу здесь в статье. Надеюсь кому-то будет полезно.

[@va1en0k]

То есть вы собираете абсолютно все классы ZF в один фаил? Даже всякие там Zend_Console_Getopt?

[@kykapa4a]

Нет. Что-то типа такого: pack.php --disable-zend-amf --disable-zend-console. В итоге имеем собранный фреймворк только с нужными библиотеками.

[@va1en0k]

… Но со всеми адаптерами к БД, например? :) Или вы перечисляете все фаилы которые не нужны?

[@kykapa4a]

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

[@va1en0k]

Я бы не сказал. Там, скажем, хелперов к виду больше, чем фаилов в некоторых библиотеках :)
Нет, мне ваше решение совсем не нравится. Чем плох фаил со списком классов? Возможно, метод его создания кривоват, но сама практика не так плоха. Тем более, похожим образом работает Zend_Loader_PluginLoader

[@kykapa4a]

По поводу хэлперов вида: более 80% используются так или иначе на большом проекте (обеспечивается за счёт Zend_Form).

В принципе непонятно зачем нужно генерить какой-то файл, если достаточно только структуры директорий и включений (замечу, что автоладер использовать тоже не нужно) — это даёт все необходимые зависимости. В итоге имеем подход для сборки любых больших библиотек (взятых из того же PEAR). Это более серьёзный результат.

[@va1en0k]

Короче, это 2 разных подхода: мой позволяет получить фаил легче и без лишнего, ваш — собрать любую библиотеку полностью без лишних телодвижений. Хватит холивара 8)

[@kykapa4a]

Ну хватит, так хватит… да и поздно уже =)

[@bb5000]

Ждем :)

[@zupernintendo]

Делаю проще:

function __autoload($classname){
$name=str_replace("_", "/", $classname).".php";
file_put_contents(dirname(__FILE__)."/includes.log", "$name\n", FILE_APPEND);
require_once($name);}

А для сборки скрипт типа такого:

if(!defined('T_ML_COMMENT'))
define('T_ML_COMMENT', T_COMMENT);
else
define('T_DOC_COMMENT', T_ML_COMMENT);

function filter_php_source($fname=""){
$content=file_get_contents($fname != ""? $fname: «php://stdin»);
$open=false; $l=0;
foreach(token_get_all($content) as $token){
if(is_string($token))
print $token;
else{
list($id, $text)=$token;
switch($id){
case T_COMMENT:
case T_DOC_COMMENT:
case T_ML_COMMENT:
break;

case T_INCLUDE_ONCE:
case T_REQUIRE:
case T_REQUIRE_ONCE:
break;

case T_OPEN_TAG:
$open=true;
print $text;
break;
case T_CLOSE_TAG:
$open=false;
print $text;
break;
default:
print $text;
break;}}}
if($open) print " ?>";}

$path=".";
isset($_SERVER[«argv»][1]) and $path=$_SERVER[«argv»][1];
is_dir($path) or die(«Path $path — not exists\n»);

$files=file($path."/includes.log");
$files=array_unique($files);
file_put_contents(«errors.log», "");
file_put_contents(«includes.log», implode("", $files));

foreach($files as $fname) if(($fname=trim($fname)) != ""){
$fname="$path/includes/".$fname;
if(!file_exists($fname))
file_put_contents(«errors.log», $fname."\n", FILE_APPEND);
filter_php_source($fname);}

[@va1en0k]

у меня не прокатил __autoload за счет структуры директорий с плагинами

[@Tonik]

Господа, с ZF сталкиваюсь не часто, но приходится… Я точно помню что для ZF был олнайн сервис, где ты указываешь калссы которые тебе нужны, а сервис сам определяет зависимости и выдает тебе архив с минимальным набором классов.
Кто ни будь может подсказать урл? а то я находил, даже делал мини сборку которую сейчас успешно юзаю в проекте… но урл вот забыл и как то нагуглить не могу :)

[@kykapa4a]

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

[@Tonik]

Я понимаю и спрашиваю тут, потому что собрались люди явно в теме и есть шанс получить ответ. прошу прощения за офтопик… :) но если ктото все же знает урл этого сервиса, я буду очень благодарен. Или в личку, если не сложно, дабы не засорять топик.

[@xaxaTyH]

Пожалуйста: epic.codeutopia.net/pack/

[@Tonik]

Спасибо большое — думаю не только мне пригодиться. Кстати использую как раз Kohana упомянутой выше.

[@AmdY]

ам… код без подсветки читать не удобно, но мне кажется здесь отсутствует самое главное — проверка файлов на актуальность. собственно из-за этого и желательно сливать в один файл, т.к. проверка времени последнего обновления и становится бутылочным горлышком.
Решение гораздо проще — отключить проверки кэшера опкода, всё равно это для продакшина где обнавления не частые.