Facebook XHP. Объектный шаблонизатор

[qrasik]

Если честно, всегда удивляло отношение людей к php шаблонизаторам… Тысячи строк кода php, а часто и на Си, и для чего? Зачем, если можно обойтись десятком строк и будет не хуже?
— Где же выгода, где полезные фичи и удобство использования?
— А удобства у нас на улице. — жизнерадостно отвечают создатели супер-шаблонизаторов.

[maxru]

Ну XHP это в некоторой степени такой же «шаблонизатор», как и native php, только объектно-ориентированный :)

[windoctor]

Я тоже не понимаю, зачем пачками пилят щаблонизаторы, когда PHP сам себе прекрасный шаблонизатор.

[hardex]

Из-за таких как вы и ненавидят PHP

[windoctor]

Серьезное обвинение, вы бы его подкрепили хоть чем-то.

[windoctor]

Да, давайте больше минусов, то то разработчики Zend Framework, Yii, CodeIgniter, Symfony1 не в теме.

[Blumfontein]

Зато разработчики Yii2 и Symfony2 уже в теме. CodeIgniter слишком древний, а по Zend2 я не понял, есть ли там шаблонизатор из коробки.

[maxru]

Zend_View есть, который native php.
Но можно прикрутить и любой другой.

[windoctor]

Про Symfony2 я умолчал т.к там twig из коробки, к остальным надо прикручивать дополнительным экстэншеном т.е из коробки работает native php.

[Blumfontein]

В Yii2 есть официальные расширения для twig и smarty, так что можно сказать из коробки. Вот про Zend2 не знаю. в Laravel blade из коробки.

>> Zend Framework, Yii, CodeIgniter, Symfony1

Все эти фреймворки слишком старые, чтобы делать выводы о шаблонизаторах, тогда, небось, кроме smarty2 и шаблонизаторов-то других не было.

[Fesor]

Были, и их активно использовали. native шаблоны по умолчанию предоставляют только для того, что бы было хоть что-то, а уж разработчик пусть использует что он захочет. Просто большинство ленится, а шаблонизаторы типа Twig нехило могут ускорить процесс разработки, уменьшить дублирование кода в шаблонах ну и т.д.

[Fesor]

А они тут причем? Те же ребята из сенсио лабс навязывают twig только потому что среднестатистическому PHP-шнику проще использовать вариант по умолчанию. И это правильно как по мне. До этого люди просто предоставляли выбор и использовали native-шаблоны потому что их могут использовать все и для этого не нужно изучать очередной шаблонизатор. Это позволяет покрыть требования большинства, да и прикрутить другой шаблонизатор не проблема. Другое дело что мало кто вообще думает о том, что дают шаблонизаторы кроме «никому не нужного синтаксического сахара».

[FanatPHP]

Я бы сказал так.
Для «классического похапе» это действительно прекрасный шаблонизатор. Сделать автоискейпинг на этапе задания переменных шаблона совсем несложно, если в шаблон не передаются объекты.

Если же это современный код, где в шаблон передаются объекты с виртуальными свойствами, то чтобы сделать хороший автоискейпинг, надо наворотить кода не меньше, чем понадобится для небольшого шаблонизатора. При этом автоискейпинг — это стопроцентный маст-хэв, вещь, без которой в принципе нельзя.

Плюс такие вещи, как наследование в нативном пхп делаются не так чтобы просто.

[Blumfontein]

>> $html = 'Привет, Хабр!'; (гребаный парсер теги съел)
>> echo $html;

Так никто в здравом уме не пишет.

>> $html = Привет, Хабр!; (чтоб ты подавился, парсер)

О дааа, прям лучше стало =)

>> $html = new :div(array('id'=>'mydiv',), new :p(array(), 'Привет, Хабр!'));
media-cache-ec0.pinimg.com/236x/69/d8/a0/69d8a00ef81c8100edfb36f4d9071091.jpg

[maxru]

Так никто в здравом уме не пишет.

Это пример, достаточный для того, чтобы был понятен общий смысл.

$html = Привет, Хабр!;

Это не будет работать.

media-cache-ec0.pinimg.com/236x/69/d8/a0/69d8a00ef81c8100edfb36f4d9071091.jpg

Так писать можно, но не нужно.

[Blumfontein]

>> Это пример, достаточный для того, чтобы был понятен общий смысл.

В шаблонах-то мы и так без кавычек пишем. Получается единственная фича — автоэскейпинг. Как-то на киллер-фичу не тянет.

>> P.S. Чтобы парсер не давился, есть менюшка Source

Нет, все из-за кармы

[maxru]

В шаблонах-то мы и так без кавычек пишем. Получается единственная фича — автоэскейпинг. Как-то на киллер-фичу не тянет.

Автоматическая генерация на 100% валидного XML и возможность манипулирования DOM-структурой тоже не тянут?
Или расширить базовые классы и использовать что-то навроде:

<ui:input ... />

или

<ui:upload ... />

вместо копирования html-кода или подключения шаблонов в цикле / repeater-ов?

Ну и, естественно, docs.hhvm.com/manual/en/hack.unsupported.php

Нет, все из-за кармы

Я интереса ради ваши комментарии в профиле уже почитал. Сдержаннее надо быть.

[qrasik]

Автоматическая генерация на 100% валидного XML и возможность манипулирования DOM-структурой тоже не тянут?

Нет, не тянет.
XML в вебе вещь скорее рекламная, а вот там где он реально нужен все вами перечисленное не очень то и нужно.
Так что вынужден согласится с Blumfontein

P.S. Вы уж или раскрывайте тему полнее или не воспринимайте критику «в штыки».

[maxru]

HTML — тоже XML, я обобщил.

P.S. Я и не воспринимаю в штыки, я дискутирую.
P.P.S. Напишите, что именно нужно раскрыть полнее? Этот пост планировался скорее как краткий экскурс с целью выяснить, есть ли заинтересованность в предметной области в принципе.

[burdakovd]

А как вам проверка синтаксиса разметки на этапе парсинга PHP-файла? По факту при запуске линтера.

В отличие от обычного html уже случайно закрывающий тег не забудешь.

[Fesor]

Незакрытые теги мне подсвечивает IDE. Если честно крайне сомнительная фича. Возможно кому-то такая штука пригодится.

[maxru]

P.S. Чтобы парсер не давился, есть менюшка Source

[Aetet]

JSX и XHP, Что-то в них обоих есть общее.

[maxru]

Скорее между JSX и Hack.

Не понял только, как собранный из JSX JS может выполняться в браузере быстрее себя самого (это я из презентации почерпнул)?

[sets]

Значит и оставить не закрытые, с неправильной вложенностью html-element'ы не сможете (short tags поддерживаются).

Я правильно понимаю, если заказчик натворит какой-нибудь адок в визивиге, то вместо ада на выводе он получит неработающий сайт? :)

[maxru]

Нет, он в любом случае получит:
— экранированный вывод, если использовались стандартные классы
— не экранированный адок, если вы специально создатите сущность, которая не будет экранировать child'ов
Т.е. любой контент воспринимается как текст.

Чтобы получить не работающий сайт нужно создать stream_wrapper и инклюдить контент из базы как файл шаблона. И я не знаю, что хуже — не работающий front-end или исполнение кода из БД :)

[sets]

Извините, я может чего не понял, но вывод вида
$html = <div id="mydiv"><p>Привет, <b>Хабр!</p></div>;
пройдет ок, да?

[maxru]

Нет, в таком виде не пройдёт.

Но «адок» из базы будем выводить так:

$html = <div id="mydiv"><p>{$data['content']}</p></div>; // $data['content'] = 'Привет, <b>Хабр!'

Т.е. данные, подставленные в шаблонизатор, в любом случае будут восприниматься как простой текст и экранироваться.
В итоге будет выведено:

<div id="mydiv"><p>Привет, & lt;b& gt;Хабр!</p></div>

[sets]

Спасибо, теперь понял.