Комментарии участников:
Простой шаблонизатор на PHP без использования регулярных выражений и str_replaceзато с целым классом и малость пугающим синтаксисом :) Верстальщика он точно напугает!
плюс идеологические ошибки в коде :) (на наличие других не проверял)
$text = str_replace(array('[*','*]'),array('<?','?>'),$text);а ведь обещали что "без использования str_replace" ...
eval('?>'.$text.'<?');ой не люблю я наличия eval в коде… ой не люблю ...
зачем в коде постоянно переопределяется error_reporting? Вообще смутно понимаю.
Верстальщика он точно напугает!
Не напугают. По хорошему верстальщица максимум должна изменять верстку и не всталять всякие переменные в шаблон. По крайней мере наши верстальщицы сказали БОЛЬШОЕ СПАСИБО, когда мы слезли с XSLT, работать с ним разы сложнее.
а ведь обещали что "без использования str_replace"
Дык, ведь используется только один раз, позже уже никаких str_replace и preg_replace не используется
ой не люблю я наличия eval в коде… ой не люблю ...
Что поделаешь? Волков боятся в лес не ходить
зачем в коде постоянно переопределяется error_reporting? Вообще смутно понимаю.
Если в шаблоне присутствует неинициализированная переменная, интерпретатор выдает нотис, чтобы этого избежать и переопределяем вывод ошибок, потом возвращаем все на место.
Да и кстати, какие идеологические ошибки присутствуют коде?
Не напугают. По хорошему верстальщица максимум должна изменять верстку и не всталять всякие переменные в шаблон.
но ведь вставляют же :) и с XSLT вот сам пишешь работают (работали). Кстати, верстальщик со знанием XSLT вполне решает все проблемы :)
ведь используется только один раз
я видел, но все-равно. Просто я-то ожидал, что его вообще не будет :)
Что поделаешь? Волков боятся в лес не ходить
что делаешь? Без него обходиться. Это вполне реально, кстати, и работает. Правда не в твоем, видимо, случае.
Если в шаблоне присутствует неинициализированная переменная, интерпретатор выдает нотис, чтобы этого избежать и переопределяем вывод ошибок, потом возвращаем все на место.
не на место, а на E_ALL (кажется, не помню уже) :) Ты же не запоминаешь предыдущее состояние.
То что помещено выше в цитате и есть, кстати, идеологическая ошибка. И для "борьбы" с нею городится огород. eval() я тоже к такого рода ошибкам отношу.
Еще, к примеру, у тебя там до работы с кешем делаются некоторые действия, которые видимо будут лишними, если страницу доставать из кеша.
1) Такого верстальщика нужно искать, и его работа будет стоить дороже обычного.
2) ...
3) Если правильно организовать защиту, то здесь нечего боятся. Присутствует же в PHP зачем-то такая функция eval()? Конечно, можно и без него обойтись, текст сохранить в файле и выполнить его через include.
4) Не за чем запоминать, правильно программировать с E_ALL, поэтому на него и возвращаемся.
До работы с кэшем сравниваются время последнего обращения к файлам: оригинала и кэша. Если у оригинала время больше, то евалим его, если нет, то показываем кэш. Ничего там лишнего нет.
2) ...
3) Если правильно организовать защиту, то здесь нечего боятся. Присутствует же в PHP зачем-то такая функция eval()? Конечно, можно и без него обойтись, текст сохранить в файле и выполнить его через include.
4) Не за чем запоминать, правильно программировать с E_ALL, поэтому на него и возвращаемся.
До работы с кэшем сравниваются время последнего обращения к файлам: оригинала и кэша. Если у оригинала время больше, то евалим его, если нет, то показываем кэш. Ничего там лишнего нет.
1) Такого верстальщика нужно искать, и его работа будет стоить дороже обычного.
обычный тоже с головой нужен. И тоже стоит денег. Или думаешь твои уникальные (в отличие от стандартизированного XSLT) конструкции все поголовно знают? Или у вас программер этим занимается? :)
3) Если правильно организовать защиту, то здесь нечего боятся. Присутствует же в PHP зачем-то такая функция eval()? Конечно, можно и без него обойтись, текст сохранить в файле и выполнить его через include.
include в данном случае будет тем же eval(). "Правильно организовать защиту" как раз и означает не использовать потенциально опасные вещи. Или, точнее, свести их использование к необходимому минимому. В системе тоже существует root и suid, но это же не значит, что все юзера должны сидеть под рутом, а программы — иметь бит суидности. Другой вопрос, что в твоей конструкции без eval не обойтись, по-видимому. Почему я и назвал ее неудачной.
4) Не за чем запоминать, правильно программировать с E_ALL, поэтому на него и возвращаемся.
даже если предположить, что нужен E_ALL (в чем я лично сильно сомневаюсь), то правильно-то как раз запоминать настройки и возвращать их назад. А уровень задавать в другом месте. У тебя же шаблонизатор — лишь часть чего-то большего, а не конечная система.
обычный тоже с головой нужен. И тоже стоит денег. Или думаешь твои уникальные (в отличие от стандартизированного XSLT) конструкции все поголовно знают?
Это не уникальные конструкции, а чистый PHP.
Или у вас программер этим занимается? :)
Делаем по-разному: если программер создает новый сервис какой-то, то он создает некий прототип шаблона, который в последствии доводится верстальщицой, или, если верстальщица верстает некую страницу с функциональными сервисами, то позже программист вставляет в нее нужные конструкции и опять отдает все верстальщице. В любом случае, кроме программиста никто не знает, какие данные нужно вставлять в шаблон и как их там использовать.
К (3). Ок, согласен.
У тебя же шаблонизатор — лишь часть чего-то большего, а не конечная система.
Совершенно верно, об этом же и в заметке написано было.
Это не уникальные конструкции, а чистый PHP.
вот именно. А верстальщик со знанием PHP — точно такие же доп. траты, что и человек со знанием XSLT. С чего мы и начинали.
Совершенно верно, об этом же и в заметке написано было.
я знаю. Но ты фактически "портишь" настройки вышестоящей системы, устанавливая свой error_reporting (как считаешь нужным) вместо того, чтобы вернуть предыдущий. Если кто-то считает необходимым E_ALL, то это должно выставляться выше, а не в шаблонизаторе.