Я же специально написал Покажи пример твоей красивой систематизации кода для указанных мной ограничений.
Сначала приведите мне конкретную простейшую задачу, а я подумаю... Класс ещё нужно грамотно написать. Чтобы потом его люди использовали и не чесали затылки - откуда ошибки? Где ваши хваленые библиотеки классов, с которыми можно было работать без проблем? А копаться в чужом коде - дело неблагодарное.
cms-lite ты как баба, ей богу, ляляля, тапаля... покажи код. Тут были примеры движков на одних функциях, и нечё я приятно удивился, а вот ты только базарить можешь
Короче, все что я вам хочу сказать, товарищи программисты, по данной теме, так это следующее: -PHP прост и эффективен как велосипед -ООП в веб-разработке - это как третье колесо для велосипеда, в нем есть какая-то польза, но, в общем то, можно вполне эффективно ездить и на двух -Системы активных шаблонов - это как велосипед предназначенный для того, чтобы крутить педали другого велосипеда, если кто-то считает такую систему эффективной - это его право -PHP - лучший шаблонизатор, тот кто это понимает - поймет.
Ненене Чтобы верстальщик в какой-нить tpl_search_show_in_result_rows_where_nothing.php какой-нить shell встроил?
Во-первых, боятся этого глупо. Во-вторых, подключать верстку к проекту должен все же программист. Поэтому если ты не проверил - твои проблемы.
Далеко не факт. Пример из жизни: сайт www.autoprognoz.ru. Этот сайт разрабатывался крайне медленно, т.к. над ним с перерывами работали разные люди. Сайт сделан на CMS DJEM. Когда я там делал часть интерфейса, у меня были соответвующие права, и я в принципе не мог ничего в програмной части испортить намерено или ненамерено, т.к. у меня небыло доступа к програмному коду. Похожая система есть и в Битрикс. Еще была история с другим сайтом, не помню уже адреса. Там была обычная самописная cms-ка, и один мудак встроил невидимый фрейм. При чем код фрема был в файле с расширением .gif и вставлялся функцией include. Сайт принадлежал небольшой фирме. Если есть шаблонизатор, можно хранить шаблоны в отдельной директории и только к ним давать доступ кому надо.
Эта проблема выходит за рамки безопасности кода. С таким же успехом кто-нибудь и из программеров или админов навредить может.
[vs] - на мой взгляд (читай ИМХО) - вопрос ограничения скорее административный, чем программный... так как программное ограничение, это так же функциональное ограничение.... хотя скорее всего по середине ... то-есть: ограничиваем доступ к папкам(физически) и разделам(программно) сайта, но внутри раздел/папки все программные ограничения накладываю и функциональные тоже ... что очень неприятно влияет на скорость разработки и возможности реализации .... можно просто логировать изменения и давать в глаз за внедрение яиц ... у меня шаблонизатор занимается лишь небольшими корректировками + выбором самого шаблона и кешированием по необходимости ....
Шаблонизатор стоит использовать хотя-бы в целях защиты от этих угроз, если над проектом будет работать несколько человек. Верстальщик, к тому же, не сможет слить код, например.
А если автор шаблонизатора, ну так, "случайно", оставит какую-нибудь "дырку"? Что тогда будешь делать?.... Просто, должны быть ответственные за внутреннюю и внешнюю безопасность люди. Только и всего.
Иногда, да может быть, лишнее, но принцип минимальных привелегий - это основа информационной безопасности.
Эх... PHP: <?php /* (c)2010 Vasilii B. Shpilchin Нативный шаблонизатор */ final class view { // Буфер переменных private $vars = array(); // Шаблон (путь, файл) private $template = null; // Установка шаблона function __construct($path) { $this -> template = $path; } // Установка переменной function set($var, $val) { $this -> vars[$var] = $val; } // Получение результата из скрипта function get_from_script($path) { ob_start(); include($path); return ob_get_clean(); } // Вывод результата работы function flush() { extract($this -> vars); include($this -> template); } } Похоже, остальное лишнее, если кеширование некритично...
Это чтобы получить результат выполнения какого-нибудь скрипта. Вот так например: PHP: <?php $view -> set('header', $view -> get_from_script('./main/header.block.php')); header.block.php в свою очередь делает что-то вроде PHP: <?php if () { $view = new view('a.tpl'); ... } else { $view = new view('b.tpl'); ... } $view -> flush();
А кто мешает сделать вот так? PHP: <?php $partial = new view('./main/header.block.php'); $view -> set('header', $partial->flush()); А еще веселее, это сделать прокси метод PHP: <?php final class view { public function flush() { ob_start(); extract($this->vars); include($this->template); $content = ob_get_clean(); ob_end_clean(); return $content; } public function __toString() { return $this->flush(); } } Тогда все твои субшаблоны отрендерятся сами в момент рендера главного шаблона. PHP: <?php $view -> set('header', new view('./main/header.block.php')); echo $view; //или $content = '<h1>Немного магии</h1><br>' . $view; echo $content; Это положительно скажется на производительности. Если вдруг твой шаблон/субшаблон на какой-нибудь эпической глубине вложенности не должен будет рендерится. То пока ты не отправишь на вывод главный шаблон у тебя не будет никаких инклудов.