И снова MVC

изобретаете очередной codeigniter?

На самом деле ужасно. Не забывайте, что та статья — 2007 года. Для 2007 года там высказываются вполне современные идеи. Но сейчас на дворе уже 2011 год и ТАК писать — право, стыдно. По пунктам:

>> Вместо PDO написал некий класс, названный мной как Active Records

Это напоминает мне «принципиально новую ОС с нескучными обоями». Мало того, что PDO написан и оттестирован десятками разработчиков, так он еще и в разы быстрее, так как это native расширение. Итог: сэкономили на спичках.

>> Переписан немного класс Template, добавлена возможность делать вложенные шаблоны

Убейте меня, не нашел там вложенных шаблонов.

>> extract($this->vars);

Это сразу премия Дарвина в ИТ. Попробуйте ради интереса выполнить что-то типа $this->template->show('main_template', array('_get' => 'OLOLO'));

Template::__set определена, __get — нет. Зачем передавать еще один массив в функцию show? Почему вместо этого не сделать метод assign? Зато вызывается __set при передаче массива — лишний код и лишние вызовы.

Существование переменных и индексов автора вообще не интересует. Пробуем: $this->template->show('main_template', null);

Полная чехарда с ошибками и исключениями. Не найден каталог? Это исключение. Не найден файл? А это уже просто ошибка. Где логика? А в Loader::library, если нет файла — просто false возвращаем…

Везде обычный include. Таким образом $router->delegate()->delegate(); гарантированно вызывает падение.

Передача параметров по ссылке в метод класса!!! И это в 5-м PHP!!!

>> $class = 'Controller_'. $controller;
$controller = new $class();

Отлично! А если файл есть, а класса в нем нет? Где проверки на существование класса?

Зачем в контроллере loader и template сделаны публичными?

function __set($varname, $value) {
$this->$varname = $value;
return true;
}

Что еще за бред?

Спасибо за развернутый комментарий. Никто не говорит, что в будущем Active Records будет тут по-прежнему использоваться. Это временное решение, не претендующее на лавры повсеместного использования. Отчасти, например, если я захочу применить отличную от MySQL БД, то текущее решение окажется неработоспособным.

По поводу вложенности шаблонов… В оригинале не было возможность вкладывать шаблон в шаблон. Здесь же в методе show последний параметр и отвечает вернуть ли вам содержимое обработанного темплейта или отправить его непосредственно в броузер. С такой возможность вполне можно делать вложенные view.

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

>>Зачем передавать еще один массив в функцию show? Почему вместо этого не сделать метод assign? Зато вызывается __set при передаче массива — лишний код и лишние вызовы.
Тут немного не понял основной мысли. Имеется ввиду передача данных в шаблон и их последующая выгрузка в переменные?

Забыл про extract написать… Да, такой способ импорта переменных очень опасен и неправильный. Но я пока не определился с методом передачи переменных во view.

> function __set($varname, $value) {
> $this->$varname = $value;
> return true;
> }

Это что-то. Вы явно зашли не в ту сторону.

Я, кстати. сам не люблю эту особенность PHP — возможность добавлять недекларированные поля, и всегда пишу в __set() и __get() что-нибудь вроде function { throw new Exception(); }. Чем строже подходить к отлову ошибок, тем меньше их окажется в итоге.

бросьте эту затею и лучше разберите какой-то фреймворк/cms/платформу по кирпичикам, тогда поймете, что как должно работать.

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

А у нас что, сейчас на хостингах ограничение в 10 МБ на сайт? Почему нельзя взять необходимые классы из любого, удобного вам фреймворка, и использовать только их. Пусть будет тяжелее чем самописное, но зато надежнее и проверено не одним программистом.

По мелочам:

$path = site_path . 'views' . DIRSEP . $name . '.php';

site_path — это что? Где определено? Или варнинг выдаёт?

                $contents = ob_get_contents();
                ob_end_clean();

есть такая функция ещё с PHP4.3 ob_get_clean()

essentially executes both ob_get_contents() and ob_end_clean().