Comments 30
Если честно, всегда удивляло отношение людей к php шаблонизаторам… Тысячи строк кода php, а часто и на Си, и для чего? Зачем, если можно обойтись десятком строк и будет не хуже?
— Где же выгода, где полезные фичи и удобство использования?
— А удобства у нас на улице. — жизнерадостно отвечают создатели супер-шаблонизаторов.
— Где же выгода, где полезные фичи и удобство использования?
— А удобства у нас на улице. — жизнерадостно отвечают создатели супер-шаблонизаторов.
Ну XHP это в некоторой степени такой же «шаблонизатор», как и native php, только объектно-ориентированный :)
Я тоже не понимаю, зачем пачками пилят щаблонизаторы, когда PHP сам себе прекрасный шаблонизатор.
Из-за таких как вы и ненавидят PHP
Да, давайте больше минусов, то то разработчики Zend Framework, Yii, CodeIgniter, Symfony1 не в теме.
Зато разработчики Yii2 и Symfony2 уже в теме. CodeIgniter слишком древний, а по Zend2 я не понял, есть ли там шаблонизатор из коробки.
Zend_View есть, который native php.
Но можно прикрутить и любой другой.
Но можно прикрутить и любой другой.
Про Symfony2 я умолчал т.к там twig из коробки, к остальным надо прикручивать дополнительным экстэншеном т.е из коробки работает native php.
В Yii2 есть официальные расширения для twig и smarty, так что можно сказать из коробки. Вот про Zend2 не знаю. в Laravel blade из коробки.
>> Zend Framework, Yii, CodeIgniter, Symfony1
Все эти фреймворки слишком старые, чтобы делать выводы о шаблонизаторах, тогда, небось, кроме smarty2 и шаблонизаторов-то других не было.
>> Zend Framework, Yii, CodeIgniter, Symfony1
Все эти фреймворки слишком старые, чтобы делать выводы о шаблонизаторах, тогда, небось, кроме smarty2 и шаблонизаторов-то других не было.
Были, и их активно использовали. native шаблоны по умолчанию предоставляют только для того, что бы было хоть что-то, а уж разработчик пусть использует что он захочет. Просто большинство ленится, а шаблонизаторы типа Twig нехило могут ускорить процесс разработки, уменьшить дублирование кода в шаблонах ну и т.д.
А они тут причем? Те же ребята из сенсио лабс навязывают twig только потому что среднестатистическому PHP-шнику проще использовать вариант по умолчанию. И это правильно как по мне. До этого люди просто предоставляли выбор и использовали native-шаблоны потому что их могут использовать все и для этого не нужно изучать очередной шаблонизатор. Это позволяет покрыть требования большинства, да и прикрутить другой шаблонизатор не проблема. Другое дело что мало кто вообще думает о том, что дают шаблонизаторы кроме «никому не нужного синтаксического сахара».
Я бы сказал так.
Для «классического похапе» это действительно прекрасный шаблонизатор. Сделать автоискейпинг на этапе задания переменных шаблона совсем несложно, если в шаблон не передаются объекты.
Если же это современный код, где в шаблон передаются объекты с виртуальными свойствами, то чтобы сделать хороший автоискейпинг, надо наворотить кода не меньше, чем понадобится для небольшого шаблонизатора. При этом автоискейпинг — это стопроцентный маст-хэв, вещь, без которой в принципе нельзя.
Плюс такие вещи, как наследование в нативном пхп делаются не так чтобы просто.
Для «классического похапе» это действительно прекрасный шаблонизатор. Сделать автоискейпинг на этапе задания переменных шаблона совсем несложно, если в шаблон не передаются объекты.
Если же это современный код, где в шаблон передаются объекты с виртуальными свойствами, то чтобы сделать хороший автоискейпинг, надо наворотить кода не меньше, чем понадобится для небольшого шаблонизатора. При этом автоискейпинг — это стопроцентный маст-хэв, вещь, без которой в принципе нельзя.
Плюс такие вещи, как наследование в нативном пхп делаются не так чтобы просто.
>> $html = 'Привет, Хабр!'; (гребаный парсер теги съел)
>> echo $html;
Так никто в здравом уме не пишет.
>> $html = Привет, Хабр!; (чтоб ты подавился, парсер)
О дааа, прям лучше стало =)
>> $html = new :div(array('id'=>'mydiv',), new :p(array(), 'Привет, Хабр!'));
media-cache-ec0.pinimg.com/236x/69/d8/a0/69d8a00ef81c8100edfb36f4d9071091.jpg
>> echo $html;
Так никто в здравом уме не пишет.
>> $html = Привет, Хабр!; (чтоб ты подавился, парсер)
О дааа, прям лучше стало =)
>> $html = new :div(array('id'=>'mydiv',), new :p(array(), 'Привет, Хабр!'));
media-cache-ec0.pinimg.com/236x/69/d8/a0/69d8a00ef81c8100edfb36f4d9071091.jpg
Так никто в здравом уме не пишет.
Это пример, достаточный для того, чтобы был понятен общий смысл.
$html = Привет, Хабр!;
Это не будет работать.
media-cache-ec0.pinimg.com/236x/69/d8/a0/69d8a00ef81c8100edfb36f4d9071091.jpg
Так писать можно, но не нужно.
>> Это пример, достаточный для того, чтобы был понятен общий смысл.
В шаблонах-то мы и так без кавычек пишем. Получается единственная фича — автоэскейпинг. Как-то на киллер-фичу не тянет.
>> P.S. Чтобы парсер не давился, есть менюшка Source
Нет, все из-за кармы
В шаблонах-то мы и так без кавычек пишем. Получается единственная фича — автоэскейпинг. Как-то на киллер-фичу не тянет.
>> P.S. Чтобы парсер не давился, есть менюшка Source
Нет, все из-за кармы
В шаблонах-то мы и так без кавычек пишем. Получается единственная фича — автоэскейпинг. Как-то на киллер-фичу не тянет.
Автоматическая генерация на 100% валидного XML и возможность манипулирования DOM-структурой тоже не тянут?
Или расширить базовые классы и использовать что-то навроде:
<ui:input ... />
или
<ui:upload ... />
вместо копирования html-кода или подключения шаблонов в цикле / repeater-ов?
Ну и, естественно, docs.hhvm.com/manual/en/hack.unsupported.php
Нет, все из-за кармы
Я интереса ради ваши комментарии в профиле уже почитал. Сдержаннее надо быть.
Автоматическая генерация на 100% валидного XML и возможность манипулирования DOM-структурой тоже не тянут?
Нет, не тянет.
XML в вебе вещь скорее рекламная, а вот там где он реально нужен все вами перечисленное не очень то и нужно.
Так что вынужден согласится с Blumfontein
P.S. Вы уж или раскрывайте тему полнее или не воспринимайте критику «в штыки».
А как вам проверка синтаксиса разметки на этапе парсинга PHP-файла? По факту при запуске линтера.
В отличие от обычного html уже случайно закрывающий тег не забудешь.
В отличие от обычного html уже случайно закрывающий тег не забудешь.
P.S. Чтобы парсер не давился, есть менюшка Source
JSX и XHP, Что-то в них обоих есть общее.
Значит и оставить не закрытые, с неправильной вложенностью html-element'ы не сможете (short tags поддерживаются).
Я правильно понимаю, если заказчик натворит какой-нибудь адок в визивиге, то вместо ада на выводе он получит неработающий сайт? :)
Нет, он в любом случае получит:
— экранированный вывод, если использовались стандартные классы
— не экранированный адок, если вы специально создатите сущность, которая не будет экранировать child'ов
Т.е. любой контент воспринимается как текст.
Чтобы получить не работающий сайт нужно создать stream_wrapper и инклюдить контент из базы как файл шаблона. И я не знаю, что хуже — не работающий front-end или исполнение кода из БД :)
— экранированный вывод, если использовались стандартные классы
— не экранированный адок, если вы специально создатите сущность, которая не будет экранировать child'ов
Т.е. любой контент воспринимается как текст.
Чтобы получить не работающий сайт нужно создать stream_wrapper и инклюдить контент из базы как файл шаблона. И я не знаю, что хуже — не работающий front-end или исполнение кода из БД :)
Извините, я может чего не понял, но вывод вида
пройдет ок, да?
$html = <div id="mydiv"><p>Привет, <b>Хабр!</p></div>;пройдет ок, да?
Нет, в таком виде не пройдёт.
Но «адок» из базы будем выводить так:
Т.е. данные, подставленные в шаблонизатор, в любом случае будут восприниматься как простой текст и экранироваться.
В итоге будет выведено:
Но «адок» из базы будем выводить так:
$html = <div id="mydiv"><p>{$data['content']}</p></div>; // $data['content'] = 'Привет, <b>Хабр!'
Т.е. данные, подставленные в шаблонизатор, в любом случае будут восприниматься как простой текст и экранироваться.
В итоге будет выведено:
<div id="mydiv"><p>Привет, & lt;b& gt;Хабр!</p></div>
Sign up to leave a comment.
Facebook XHP. Объектный шаблонизатор