Хорошие статьи по шаблонам в PHP

[Духовность™]

http://www.phpinfo.su/articles/practice/shablony_v_php.html
http://www.phpinfo.su/articles/practice/shablony_v_php_chast_2.html

 

[Фанат]

А почему ты скромничаешь и никак не обозначаешь авторство?

 

[Фанат]

В конце второй части написана полная ерунда.
Это все равно что написать "безопасность составления SQL запросов лежит на программисте. Сам руками не отформатировал - сам и виноват".

Конкретно в этом месте Фабьен говорит абсолютную истину: искейп должен происходить АВТОМАТОМ, для всех передаваемых в шаблонизатор переменных (что реализуется за 5 секунд). Исключение составляют специально помеченные переменные, которые не искейпятся.

$this->e, кстати - это полный кошмар. сократили, называется, вызов длинной функции.
существование универсальных функций-хелперов - необходимость.
класть их в класс совсем не обязательно, просто <?=e($age)?> вполне достаточно.

Но суть совсем не в многословности. А в автоматизации:
Шаблонизатор (native PHP) должен всегда принимать на вход две переменные - массив данных и имя файла с шаблоном, и одну необязательную - список переменных, которые искейпить не надо.
По массиву проходим рекурсивно, и всё искейпим.

Ну и пропущена тема, о которой я говорил недавно - построение общего шаблона страницы.

 

[Духовность™]

искейп должен происходить АВТОМАТОМ, для всех передаваемых в шаблонизатор переменных

у меня поля форм строятся с помощью хэлперов. DOM сам все там экранирует. так что это не вариант - шаблону нужны сырые данные.

"безопасность составления SQL запросов лежит на программисте. Сам руками не отформатировал - сам и виноват".

разве это не так? до появления всех этих оберток так и было - addslaches

 

[Фанат]

addslaches не имеет ни малейшего отношения к инъекциям.

 

[fixxxer]

Шаблонизатор (native PHP) должен всегда принимать на вход две переменные - массив данных и имя файла с шаблоном, и одну необязательную - список переменных, которые искейпить не надо.
По массиву проходим рекурсивно, и всё искейпим.

я делал проще - не эксейпил переменные с префиксом html_

правда это был патч для автоэксейпинга на blitz, но какая разница

 

[Духовность™]

зацените дизайн!

 

[Ragazzo]

зацените дизайн!

божественен

 

[Mols]

у меня поля форм строятся с помощью хэлперов. DOM сам все там экранирует. так что это не вариант - шаблону нужны сырые данные.

Как по мне - подход не правильный.
ИМХО по дефолту всё должно экранироваться.
А где не надо экранирования - надо явно брать сырое значение.
как вариант завернуть аргументы в объекты класса с одним своим методом, типа getOriginalValue()
и с перегруженным __toString() (который будет выполнять экранирование)

 

[Духовность™]

ИМХО по дефолту всё должно экранироваться.

моё имхо - не должно.
пример я DOM генератором я привел.
+ пример банальный - нужно обрезать строку до Н символов. аннотация типа. опять нужно original value
масса случаев
$this-e($var) даёт полное понимание того, как эскейпится эта переменная
и потом, как эскейпить? какие кавычки как?

в шаблоне должны быть сыре данные. не говоря уже о других форматах вывода результата.

как вариант завернуть аргументы в объекты класса с одним своим методом, типа getOriginalValue()

хороший вариант. я вообще за ОО-типизацию примитивных значений.

 

[fixxxer]

я согласен, что в шаблон должны идти сырые данные.
но автоескейпинг все равно нужен. лучше забыть "разескейпить", чем наоборот - в последнем случае это обнаруживается как правило уже вместе с xss-атакой

в том же твиге все с автоескейпингом красиво: {{ var }} компилится в htmlspecialchars($var), {{ var|raw }} - в $var.
как это красиво сделать для native-php, я не знаю.

 

[флоппик]

в том же твиге все с автоескейпингом красиво: {{ var }} компилится в htmlspecialchars($var), {{ var|raw }} - в $var.
как это красиво сделать для native-php, я не знаю.

Эскейпить их при View->set() и не эскейпить при View->raw() ?

 

[Sufir]

Эскейпить их при View->set() и не эскейпить при View->raw() ?

А если объект? Или хотя бы массив, в котором только часть данных надо эскейпить? Или во View только скалярные типы передавать?

 

[С.]

в том же твиге все с автоескейпингом красиво: {{ var }} компилится в htmlspecialchars($var), {{ var|raw }} - в $var. как это красиво сделать для native-php, я не знаю.

Просто только-что возникшая мысль:
$data->var
$data->var()

 

[Вурдалак]

А если объект?

 

[Mols]

ну а в чем проблема то?
В шаблон мы отдаём сырые данные...
На входе заворачиваем их в объект обертку.
Если это массив - то заворачиваем рекурсивно.
В обертке юзаем магическкие методы, чтобы проескейпить свойства объектов при обращении типа.

$var->someValue // ескейпится

если надо сыры данные, то

$var->raw();
$var->raw()->someValue; //не ескейпится

 

[флоппик]

А если объект?

Объект, переданный в шаблон почти всегда — модель. Ее надо будет тоже научить автоэскейпингу.

 

[Фанат]

На входе заворачиваем их в объект обертку.
Если это массив - то заворачиваем рекурсивно.
В обертке юзаем магическкие методы, чтобы проескейпить свойства объектов при обращении типа.

а можно спросить - зачем это всё делать?

 

[флоппик]

На самом деле, так красиво «как в твиге» все равно вряд ли получится.

 

[Фанат]

как это красиво сделать для native-php, я не знаю.

НЕ НАДО это делать. Ни в твиге, ни в native-php.
Это вообще не дело шаблона решать, какие данные не надо искейпить.
Условный "верстальщик" этого знать не может и не должен.
За те не несколько переменных на весь сайт, которые искейпить не надо, пусть отвечает программист, и помечает их, передавая в шаблонизатор.