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

Как уже писал: допустим ZF в папке /php/Zend/. Теперь туда нужно положить файлы из ZF:

1. Exception.php
2. Loader.php
3. Папку Loader

Всё, больше ни каких файлов и папочек пока не надо. В папке Zend, кроме перечсленных файлов больше ни чего нет. Теперь можно подключать автозагрузчик. Тут самое главное это set_include_path($_SERVER['DOCUMENT_ROOT'] . '/php/'); Т.к. Loader будет пытаться подключить скрипты из дирректории Zend/ а мы договорились что она у нас спрятана в php/.

Допусти нам понадобился класс для работы с кэшем:

Ложим в папку php/Zend/ следующие штуки из ZF:

1. Cache.php
2. Cache/

Всё, терерь можно писать код:

$cache = Zend_Cache::factory('Core', 'File', 
	array(
	   'lifetime' => 60,							// Время жизни кэша
	   'automatic_serialization' => true			// Автоматическая сериализация
	),
	array(
		'cache_dir' => $_SERVER['DOCUMENT_ROOT'] . '/files/cache/'
	)
);

// Если не удалось загрузить из кэша
if(!$CONTENT = $cache->load('content') ) {

	// .. например обращение к БД

	// Запись результата в кэш
	$cache->save($CONTENT, 'content');
}

print $CONTENT;

Да не за что, когда скука наваливается это даже интересно.

P.S.: Я тоже долго с этим разбирался.

Вот это важно! папка Zend должна быть

Есть такое понятие как микрофреймворк. Может проще тебе с этого начать.

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

Я лично - друпалом занимаюсь. Хотя это CMS/CMF все таки, а не просто php фреймворк.

ты сам все не напишешь. Можешь конечно начинать потихоньку ...

Tim, а ты друпалом продолжаешь заниматься?

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

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

удалено.

не забывают. Просто в задачах чуть более сложных, чем "Hello, world!" в любом случае есть низкоуровневый код (ядро) и высокоуровневый (прикладной уровень). Даже если такое разделение в коде явно не присутствует. Требования к производительности ядра, очевидно, выше. Поэтому там приходится пренебрегать ясностью кода. В прикладном уровне это не так критично, поэтому можно "пренебрегать производительностью". Для меня ясность важна потому, что она позволяет писать код быстрее, совершая меньше ошибок и мне потом легче вносить изменения в этот код. Разве я отошел от цели?

Разница между использованием и неиспользованием ФК в том, что при отказе от ФК нужно изобрести свой. Потому что нельзя писать понятный и оптимизированный код. Надо выбрать что-то одно. Ты, похоже, выбрал оптимизацию. Ну что ж, наверное, тебе не нужен framework :)

удалено.

удалено.

micscr,
Да всё времени не было. Буду обязательно с ним разбираться.

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

на самом деле да, без конкретных примеров все это очень абстрактно и можно очень долго спорить. Кроме того, я не очень понимаю, что такое код без использования ФК. phpbb что ли? О скорости и меньшем количестве ошибок я сужу в первую очередь по этому опыту. Перейдя от первого ко второму я заметил, что допускаю меньше ошибок и работаю быстрее. Но фреймворк - это нечто подобное, он поднимает уровень абстракции

потому что за меня написали часть сайта. Низкоуровневую. И я могу сосредоточиться на реализации функционала

сможет, если захочет. Тем более, что это не начинать разработку сайта с нуля на фреймворке. В случае необходимости можно посмотреть на реализацию существующего функционала. Ну и распространенность фреймворка в общем-то да, имеет значение, по-крайней мере для работодателя. Но ведь с ЯП та же ситуация, если сайт написан на Erlang у последующих программистов будут проблемы с поддержкой. Причем, "выучить ЯП" != "выучить фреймворк"

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

ну слюной пока вроде никто не брызгает и хорошо :) и я не хочу доказать свою правоту во что бы то ни стало. Мне больше хочется узнать для себя что-то новое. Но пока что, мне кажется, что дело в том, что у нас разные приоритеты. И со своей стороны, я тоже не вижу, зачем их менять