Комментарии 19
изобретаете очередной 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 сделаны публичными?
Что еще за бред?
>> Вместо 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 при передаче массива — лишний код и лишние вызовы.
Тут немного не понял основной мысли. Имеется ввиду передача данных в шаблон и их последующая выгрузка в переменные?
По поводу вложенности шаблонов… В оригинале не было возможность вкладывать шаблон в шаблон. Здесь же в методе show последний параметр и отвечает вернуть ли вам содержимое обработанного темплейта или отправить его непосредственно в броузер. С такой возможность вполне можно делать вложенные view.
С ошибками да — пока косяк. Ведь многое осталось и с оригинала. В дальнейшем поправлю.
>>Зачем передавать еще один массив в функцию show? Почему вместо этого не сделать метод assign? Зато вызывается __set при передаче массива — лишний код и лишние вызовы.
Тут немного не понял основной мысли. Имеется ввиду передача данных в шаблон и их последующая выгрузка в переменные?
>> Тут немного не понял основной мысли. Имеется ввиду передача данных в шаблон и их последующая выгрузка в переменные?
Да. Есть __set — этот метод модифицирует внутреннее состояние класса, а метод show по логике не должен модифицировать внутреннее состояние класса, так как его назначение на основании предопределенного внутреннего состояния выдать какой-то результат. Вы же создали путаницу, добавив в метод show изменение внутреннего состояния класса. Это не смертельно, но это очень нелогично и вносит путаницу. Лучше создать метод assign, который будет заносить данные из массива.
Да. Есть __set — этот метод модифицирует внутреннее состояние класса, а метод show по логике не должен модифицировать внутреннее состояние класса, так как его назначение на основании предопределенного внутреннего состояния выдать какой-то результат. Вы же создали путаницу, добавив в метод show изменение внутреннего состояния класса. Это не смертельно, но это очень нелогично и вносит путаницу. Лучше создать метод assign, который будет заносить данные из массива.
Забыл про extract написать… Да, такой способ импорта переменных очень опасен и неправильный. Но я пока не определился с методом передачи переменных во view.
Так как include выполняется в контексте класса, то внутри шаблона будет доступен $this. Следовательно реализуйте __get и используйте $this->{имя переменной} в шаблонах. Использование просто переменных очень плохо, так как в случае неопределения какой-либо переменной, она будет взята из глобальной области видимости. Я даже не говорю про notice, если эта переменная вообще нигде неопределена
> function __set($varname, $value) {
> $this->$varname = $value;
> return true;
> }
Это что-то. Вы явно зашли не в ту сторону.
Я, кстати. сам не люблю эту особенность PHP — возможность добавлять недекларированные поля, и всегда пишу в __set() и __get() что-нибудь вроде function { throw new Exception(); }. Чем строже подходить к отлову ошибок, тем меньше их окажется в итоге.
> $this->$varname = $value;
> return true;
> }
Это что-то. Вы явно зашли не в ту сторону.
Я, кстати. сам не люблю эту особенность PHP — возможность добавлять недекларированные поля, и всегда пишу в __set() и __get() что-нибудь вроде function { throw new Exception(); }. Чем строже подходить к отлову ошибок, тем меньше их окажется в итоге.
бросьте эту затею и лучше разберите какой-то фреймворк/cms/платформу по кирпичикам, тогда поймете, что как должно работать.
+ на фрилансе обычно заказчик себя страхует тем, что хочет делать продукт на широко известном OpenSource движке, который в будущем сможет поддержать любой программист с достаточным к-вом знаний
+ на фрилансе обычно заказчик себя страхует тем, что хочет делать продукт на широко известном OpenSource движке, который в будущем сможет поддержать любой программист с достаточным к-вом знаний
А у нас что, сейчас на хостингах ограничение в 10 МБ на сайт? Почему нельзя взять необходимые классы из любого, удобного вам фреймворка, и использовать только их. Пусть будет тяжелее чем самописное, но зато надежнее и проверено не одним программистом.
По мелочам:
site_path — это что? Где определено? Или варнинг выдаёт?
есть такая функция ещё с PHP4.3 ob_get_clean()
$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().
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
И снова MVC