MACRO - стотысячная попытка сделать новый PHP шаблонизатор

[HraKK]

pachanga

Я исхожу из той точки зрения, что MACRO накладывает минимальные требования к изучению

1) На изучение базового функционала Смарти у меня ушло 15 мин. Ты уверен что изза того что мне лень потратить 15 мин я установлю твой шаблонизатор?
2)Как теперь оказывается он еще и только с LIMB3. То есть мне не лень потратить неделю на изучение Лимб( даже если у меня свой фреймворк, а LIMB не справится с моими задачами, но это пока не важно), но лень потратить 15 мин на Смарти?

Бред.Шансов - 0.

 

[Bakti9rov]

pachanga

Мне кажется, ничего нового, кроме лишней пары фигурных скобок.

 

[pachanga]

1) На изучение базового функционала Смарти у меня ушло 15 мин. Ты уверен что изза того что мне лень потратить 15 мин я установлю твой шаблонизатор?

Почитай внимательно, чем отличается MACRO от Smarty еще раз.

2)Как теперь оказывается он еще и только с LIMB3. То есть мне не лень потратить неделю на изучение Лимб( даже если у меня свой фреймворк, а LIMB не справится с моими задачами, но это пока не важно), но лень потратить 15 мин на Смарти?

Не надо передергивать. Для использования MACRO не требуется знать Limb3 вообще. В простейшем случае, MACRO будет ставиться одной командой: $ pear install limb/macro

-~{}~ 14.10.07 12:24:

Автор оригинала: Bakti9rov
pachanga
Мне кажется, ничего нового, кроме лишней пары фигурных скобок.

А что у тебя подпадает под критерий "новизны"?

 

[HraKK]

Почитай внимательно, чем отличается MACRO от Smarty еще раз.

Мне все равно чем он отличается концептуально. Я практик.
Легче синтаксис не стал. И не нужен.
Скорость быстрее не стала.
Так что я получаю взамен?

 

[pachanga]

Автор оригинала: HraKK
Скорость быстрее не стала.

1) На счет скорости можно долго рассуждать - что может быть быстрее PHP кода(C extension не в счет)? Собственные же макросы можно вылизывать до тех пор пока генерируемый код не будет максимально оптимальным. Например, в Smarty аналог {{include}} компилируется в шаблон или же процесс включения происходит в runtime?

Так что я получаю взамен?

2) Дла начала, в Smarty есть {{wrap}}? Если есть, насколько оптимально он компилируется в PHP код?

3) Насколько просто расширять Smarty? Я тут в соседнем треде показал пример {{tree}} макроса, которого пока нет, но я смогу его реализовать за полчаса. Насколько просто это сделать в Smarty?

4) Я тоже практик и именно из практических целей задумывал MACRO. Как я писал выше, меня устраивает PHP шаблоны полностью, однако для читабельности и переиспользования кода в MACRO и существует возможность использования макросов. MACRO изначально не пытается запрятать презентационную логику за собственным полунепонятным синтаксисом - нужен полный контроль, используй PHP.

 

[Bakti9rov]

Насколько просто расширять Smarty?

У Smarty есть функции шаблона, модификаторы, блоковые функции, функции компилятора, префильтры/постфильтры, фильтры вывода, ресурсы, вставки... etc. Пишешь плагины, и готово.

Вот на Smarty вставка всего что выводится модулем "Новости":

{module name="news"}

Пишется 1 плагин smarty_function_module.

 

[pachanga]

У Smarty есть функции шаблона...

Я задал конкретный вопрос, насколько просто будет сделать {{tree}} вот как описано в этом треде http://phpclub.ru/talk/showthread.php?s=&threadid=103342&rand=32

 

[HraKK]

pachanga

1) На счет скорости можно долго рассуждать - что может быть быстрее PHP кода(C extension не в счет)? Собственные же макросы можно вылизывать до тех пор пока генерируемый код не будет максимально оптимальным. Например, в Smarty аналог {{include}} компилируется в шаблон или же процесс включения происходит в runtime?

Я не использую {include} в шаблонах. Это неправильно. Это не относится к задачам шаблонизатора.

2) Дла начала, в Smarty есть {{wrap}}? Если есть, насколько оптимально он компилируется в PHP код?

Незнаю, не юзал и не надо.

3) Насколько просто расширять Smarty? Я тут в соседнем треде показал пример {{tree}} макроса, которого пока нет, но я смогу его реализовать за полчаса. Насколько просто это сделать в Smarty?

Мне не надо расширять Смарти. Мне зауши хватает базового синтаксиса {section} и {if}

4)

Все равно кодер не сделает конструкции {tree} в шаблоне. А мне понятно и так. Смысл?

 

[pachanga]

Я не использую {include} в шаблонах. Это неправильно. Это не относится к задачам шаблонизатора.

А обосновать "неправильно" и "не относится" можешь?

Незнаю, не юзал и не надо.

А я бы рекомендовал просто попробовать - не пожалеешь.

Мне не надо расширять Смарти. Мне зауши хватает базового синтаксиса {section} и {if}

Зачем тебе Smarty тогда вообще, если ты пользуешься только самыми примитивными вещами? Чем тебя тогда просто PHP не устраивает?

Все равно кодер не сделает конструкции {tree} в шаблоне. А мне понятно и так. Смысл?

Поясни, что ты имеешь в виду?

 

[HraKK]

pachanga

А обосновать "неправильно" и "не относится" можешь?

Это задача контроллера а не view подключать что-то.

А я бы рекомендовал просто попробовать - не пожалеешь.

попробую

Зачем тебе Smarty тогда вообще, если ты пользуешься только самыми примитивными вещами? Чем тебя тогда просто PHP не устраивает?

Что бы защитить свой код от PHP injection в шаблоны.

Поясни, что ты имеешь в виду?

Кодеру над предоставить код Дерева как ты указал в том топике хотябы . С 0 он не напишет. А разницы что в смарти что тут не будет - HTML код то наружу

 

[pachanga]

Это задача контроллера а не view подключать что-то.

Если уж ты стал такими категориями говорить, о composite view слышал? Мне вот просто интересно, например, у тебя есть колонка с новостями, которая повторяется на многих шаблонах, как же это у тебя решает ее выводить контроллер?

Что бы защитить свой код от PHP injection в шаблоны.

У тебя реально была такая проблема на практике - PHP injection в шаблоне?

Кодеру над предоставить код Дерева как ты указал в том топике хотябы . С 0 он не напишет. А разницы что в смарти что тут не будет - HTML код то наружу

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

 

[HraKK]

как же это у тебя решает ее выводить контроллер

Спокойно в шаблоне вызываем контролер новостей который вернет туда колонку новостей.

У тебя реально была такая проблема на практике - PHP injection в шаблоне?

Нет. Но это цмс - а если любой модератор сможет выпонять PHP код, это не приемлимо для меня.

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

Приду покажу.

 

[pachanga]

Автор оригинала: HraKK
Спокойно в шаблоне вызываем контролер новостей который вернет туда колонку новостей.

Т.е а вот об этом view должен знать, забавно.

Нет. Но это цмс - а если любой модератор сможет выпонять PHP код, это не приемлимо для меня.

Не хочешь ли ты сказать, что в твоей cms можно изменять шаблоны и вставлять Smarty код прямо из админки? И что ты хочешь сказать, что при этом любой модератор не сможет выполнять php код? А как же тег {php} в Smarty?

 

[Dagdamor]

HraKK

Я не использую {include} в шаблонах. Это неправильно. Это не относится к задачам шаблонизатора.

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

 

[dark-demon]

> Спокойно в шаблоне вызываем контролер новостей который вернет туда колонку новостей.

это порочная практика. view не должно вызывать controller. ни в явном, ни в косвенном виде.

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

 

[atv]

Ну вот так можно сделать:

 <?php if(isset($data['chapter']) { ?>
 {{include file="chapter.phtml"}}
 <?php } ?>

Неа, если сравнивать то будет где-то вот так:

 <?php if($data['some_var'] instanceof chapter) { ?>
 {{include file="chapter.phtml"}}
 <?php } ?>

Когда я смотрю на XSLT мега конструкции меня, честно говоря, мутит.

Это делается один раз, а потом нужное слегка переопределяется. Ты же используешь мега конструкции ООП, потому как выгодно.

Зачем, если PHP это делает сам замечательно?

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

это порочная практика. view не должно вызывать controller. ни в явном, ни в косвенном виде.

Вот, вот... Началось... Вечные споры, характерные модели MVC.

Вот в Event Driven подходе таких мыслей даже не возникает, и архитектура приложения получается более гибкой и понятной, и уровни приложения вырисовываются более чёткие.

 

[korchasa]

Честно говоря не оень понятно зачем сравнивать XSLT и MACRO.
- порог входа слишком разный
- macro позволяет использовать native php, т.е. в общем случае не накладывает НИКАКИХ ограничений.

ИМХО, MACRO это syntactic sugar для native php в шаблонах.

-~{}~ 14.10.07 19:00:

<?php if($data['some_var'] instanceof chapter) { ?>
{{include file="chapter.phtml"}}
<?php } ?>

Зачем? Зачем представлению знать о каком то наследовании, которое относится к слою модели?

И вообще, в PHP, как в шаблонизаторе, отсутствуют какие либо возможности использовать абстракции, а только применение абстракций позволяет повторно использовать код,в том числе и шаблонный.

а include, функции и методы не абстракции?

Вот в Event Driven подходе таких мыслей даже не возникает, и архитектура приложения получается более гибкой и понятной, и уровни приложения вырисовываются более чёткие.

Event Driven это конечно хорошо, но лучшая PHP-реализация с которой приходилось сталкиваться - Prado, оставила после себя очень неприятный осадок over engineering'а и грязных хаков, для реализации функциональности, которую не предусмотрели ее создатели.

 

[pachanga]

ИМХО, MACRO это syntactic sugar для native php в шаблонах.

Воот, самое лаконичное и удачное определение, на самом деле

 

[dark-demon]

> порог входа слишком разный

ой, не надо. в xslt нет ничего сложного. конечно, для php-программиста не знакомого с xslt, макро и иные надстройки над пхп будут значительно проще. причём, обычно такой программист будет скорее вставлять в шаблон пхп-код, чем писать отдельные макросы.


> macro позволяет использовать native php, т.е. в общем случае не накладывает НИКАКИХ ограничений.

это скорее минус шаблонному движку, чем плюс. впрочем, к xslt тоже можно php прикрутить.
простой пример: у вас есть проект на php с шаблонами на php. вы поднимаете ещё один проект на, допустим, питоне, который должен интегрироваться в первый ( один дизайн, одинаковая структура страницы ). точно, извольте переписать все шаблоны под новый язык. а потом ещё контролировать, чтобы при модификации шаблона вторая его версия работала аналогично. гораздо эффективнее в этой ситуации иметь одинаковые шаблоны для всего и портировать только шаблонизатор ( если, конечно, он не является автономным ).

 

[pachanga]

dark-demon

И давно ты пользуешься xslt?