Комментарии 95
Не вижу ничего, что могло бы заставить меня использовать его в своих проектах
к сожалению такаяже ситуация. Синтаксис шаблонов у того-же смарти мне кажется намного удобнее.
Аналогично. Поставил плюс за попытку, но серьёзных преимуществ не вижу.
Здесь трудно с вами не согласится, так как проекты и потребности у каждого разные.
Я выбрал данное решение потому что:
1. Я не хотел добавлять громоздкие шаблонизаторы типа Smarty в проект, который состоит всего из нескольких файлов (В Separate вам нужно добавить всего один файл в ваш проект.)
2. Мне нравиться что этот шаблонизатор является обектно-ориентированным и его можно расширять как угодно. Например, переменным, которые часто встречаются, можно автоматически элегантно присвоить значения.
Я выбрал данное решение потому что:
1. Я не хотел добавлять громоздкие шаблонизаторы типа Smarty в проект, который состоит всего из нескольких файлов (В Separate вам нужно добавить всего один файл в ваш проект.)
2. Мне нравиться что этот шаблонизатор является обектно-ориентированным и его можно расширять как угодно. Например, переменным, которые часто встречаются, можно автоматически элегантно присвоить значения.
Почему же все забывают, что PHP сам по себе шаблонизатор, зачем делать шаблонизатор на шаблонизаторе?
Да и опять же концепция разрыва блочных тегов по нескольким шаблонам приводит к сложнообнаруживаемым ошибкам.
Да и опять же концепция разрыва блочных тегов по нескольким шаблонам приводит к сложнообнаруживаемым ошибкам.
Наследование шаблонов — очень полезная вещь.
Да и опять же концепция разрыва блочных тегов по нескольким шаблонам приводит к сложнообнаруживаемым ошибкам.— это да, так делать не стоит.
К сожалению нужно это делать, чтобы разделить работу программиста и дизайнера (верстальщика).
Ну а из плюсов: тот же Smarty все равно компилирует себя в php-код.
Ну а из плюсов: тот же Smarty все равно компилирует себя в php-код.
А меня всегда удивляло: почему в документациях к фреймворкам, часть с описанием функционала шаблонизаторов всегда называется как-нибудь в духе «for designer» или «designer guid». Причем тут дизайнеры?)
Замечательно на этот вопрос отвечает не менее замечательная статья
Перевод: Шаблонизаторы в PHP
Я намеренно указал в скобках «верстальщика», т. к. зачастую дизайнер является и верстальщиком своих художеств.
Перевод: Шаблонизаторы в PHP
Я намеренно указал в скобках «верстальщика», т. к. зачастую дизайнер является и верстальщиком своих художеств.
Потому что профессия верстальщика есть только в бывшем СССР.
Потому что на западе html/css верстальщики и называются дизайнерами.
НЛО прилетело и опубликовало эту надпись здесь
Чем-то на Sigma Templates похоже
Судя по документации, кэширование у вас не установлено. Планируете?
Тот же Smarty, например кэширует (компилирует в native php) и работает в результате довольно шустро.
Тот же Smarty, например кэширует (компилирует в native php) и работает в результате довольно шустро.
Хм… А зачем кавычки? Зачем такой сложный синтаксис? Циклов тоже нет?
Кроме Smarty что еще рассматривали?
Для меня наиболее приятен Twig — может и вам пригодится.
<!-- IF '${MY_VARIABLE}' == 'hello' -->
Кроме Smarty что еще рассматривали?
Для меня наиболее приятен Twig — может и вам пригодится.
Еще один шаблонизатор для шаблонизатора (в прошлом)?
Я сам пишу на php, и использую twig. Его и вам рекомендую.
Я сам пишу на php, и использую twig. Его и вам рекомендую.
Я сам пишу на PHP, и использую теги вида:
Чего и все рекомендую!
Ave holy war!
<?php echo 123;?>
<?php foreach($array as $k => $v):?>
...
<?php endforeach;?>
<?php if(true):?>
...
<?php endif;?>
Чего и все рекомендую!
Ave holy war!
Не, ну для дизайнера это тяжко. Проще так:
И кстати, не надо двоеточием. Так в IDE потом неудобно работать.
{{ 123 }}
{% for k,v in array %}
{% endfor %}
{% if true %}
{% endif %}
И кстати, не надо двоеточием. Так в IDE потом неудобно работать.
А чем же тогда, если не двоеточием?
Если использовать PHP как шаблонизатор и использовать фигурные дужки то выходит нечитабельный лапшекод!
И я считаю что такие: <?php… ?> теги больше похожи на HTML чем такие: {{ 123 }}, так что по поводу того что проще, я с вами не согласен.
Да и зачем дизайнеру лезть в код? Пусть рисует себе на здоровье!
Если использовать PHP как шаблонизатор и использовать фигурные дужки то выходит нечитабельный лапшекод!
И я считаю что такие: <?php… ?> теги больше похожи на HTML чем такие: {{ 123 }}, так что по поводу того что проще, я с вами не согласен.
Да и зачем дизайнеру лезть в код? Пусть рисует себе на здоровье!
Ну, я верстальщика имел в виду.
<< А чем же тогда, если не двоеточием?
<< И я считаю что такие: <?php… ?> теги больше похожи на HTML чем такие: {{ 123 }}, так что по поводу того что проще, я с вами не согласен.
Дело вкуса. Я по многим причинам twig люблю.
<< А чем же тогда, если не двоеточием?
<?php while(1) { ?>
// Мой PHPStorm прекрасно индентит этот блок, а скобочки видит (т.е. можно по ним прыгать).
<?php } ?>
<< И я считаю что такие: <?php… ?> теги больше похожи на HTML чем такие: {{ 123 }}, так что по поводу того что проще, я с вами не согласен.
Дело вкуса. Я по многим причинам twig люблю.
Вы слишком сильно привязаны в вашей IDE, и пытаетесь всем остальным навязать её стиль, точнее недостатки. Может лучше заставить PHPStorm видеть в том числе и
for(): endfor;? Прыгать по скобочкам конечно хорошо, но плохо, когда не видно что именно скобки закрывают, для этого точно придётся прыгать вверх и обратно.Я вообще не встраиваю php-код в html (в основном), т.к. использую шаблонизаторы (smarty и twig).
Ну откуда мне это знать, если приводите код с HTML вставкой, а ведь именно о таком применении шла речь.
Ровно один комментарий по ветке выше.
ИМХО, скобочки в таком варианте жутко не читабельны.
О да, это конечно проще, не смейтесь, дизайнер не блондинка, запомнить 10 команд думаю способен.
Вы это Фабиану скажите (создателю twig и симфони), он вам все объяснит. Вкратце — да, так проще.
А главное, что теперь представление никак не зависит от логики.
А главное, что теперь представление никак не зависит от логики.
И кстати, не надо двоеточием. Так в IDE потом неудобно работать.
Именно двоеточием и нужно. Нетбинс, насколько я помню, прекрасно это жует.
Простое правило — если код целиком находится в php теге — фигурные скобки. Если же вставляются куски html — двоеточие (излишне говорить, что в функциях и классах html не стоит использовать). И код ваш будет чист и прекрасен.
не забываем про короткую запись <?=$foo?>
На некоторых хостингах запрещена такая запись, в целях безопасности.
А тут (http://www.php.net/manual/en/ini.core.php#ini.short-open-tag) пишут что начиная с 5.4.0 всегда можно использовать короткий тег.
Бывает запрещено <?, а <?= должно быть разрешено.
Может я и ошибаюсь, но по моему если запрещено <?, то и <?= автоматом тоже запрещено.
This directive also affected the shorthand <?= before PHP 5.4.0, which is identical to <? echo. Use of this shortcut required short_open_tag to be on. Since PHP 5.4.0, <?= is always available.
К сожалению, запрещено
Чтобы ярче разгорался спор, было бы вполне уместно вспомнить про то, что любители шаблонизаторов просто не осилили xslt.
Почему PHP программисты не используют HAML или Slim?
haml.info/ (есть для PHP, точно знаю)
slim-lang.com/
Столько пляски вокруг фигурных скобок…
haml.info/ (есть для PHP, точно знаю)
slim-lang.com/
Столько пляски вокруг фигурных скобок…
Потому что PHP-программисты вообще это не используют. Используют верстальщики. Нафига им изучать какой-то хамл вместо любимой хтмлешечки?
slim разве не под руби?
Здесь минус еще в том что если все писать на Haml, то потом нельзя просто взять и скопировать сторонний кусок кода. Его тогда тоже придется конвертировать в Haml (если это вообще возможно).
html2haml в консоли или вот сервис html2haml.heroku.com/
Это не совсем шаблонизаторы, это кодогенераторы.
Какой смысл в нём? Вот получил я от верстальщика форму, вставил плейсхолдеры и всё заработало. зачем мне ещё переводить html во псевдоязык?
p.s. Пользовался такими в php и в node, но кроме неудобств ничего путного не заметил. Может что-то пропустил или в руби это даёт какие-то дополнительные возможности?
Какой смысл в нём? Вот получил я от верстальщика форму, вставил плейсхолдеры и всё заработало. зачем мне ещё переводить html во псевдоязык?
p.s. Пользовался такими в php и в node, но кроме неудобств ничего путного не заметил. Может что-то пропустил или в руби это даёт какие-то дополнительные возможности?
Первое что радует, всё очень чисто, намного легче зрительно найти, то что нужно. Второе — ускоряет автоматический поиск. Есть у вас
.lang-switcher.active в css, у вас такой же .lang-switcher.active будет и в slim. Поэтому чтобы найти нужный участок вам нужно всего лишь скопировать, запустить поиск выбрать нужны результат. А в обычном html <div class="lang-switcher active"></div>. А значит такой финт уже не получится.Удобства возникают, когда верстальщик перестает думать на html и старом css, а СРАЗУ верстает на haml (slim) + scss (sass, less), тогда и дублирований меньше в том же sass можно задать константы, миксины и т.п.
Вот я посмотрю люди так и делают habrahabr.ru/post/164823/ я сам тоже ряд проектов начал сразу в haml верстать, в sass как замена css это уже давно, удобство для верстальщика просто огромное.
Вот я посмотрю люди так и делают habrahabr.ru/post/164823/ я сам тоже ряд проектов начал сразу в haml верстать, в sass как замена css это уже давно, удобство для верстальщика просто огромное.
В теории — да. а на практиче много косяков вылазит по мере работы. Так как ни один браузер не умеет работать напрямую с less и haml, поэтому получается солянка. У меня текущий проект такой, пару шалонов на nodejs + jade, часть html генерится джаваскриптом и плагинами, часть магии творит angularjs. Да и IDE лучше себя чувствуют в обычном html
Для less напротив проще, есть js конвертор, работает отлично. Для haml и slim обычный препроцессор, так что дойдет до браузера обычный html.
В остальных случаях до браузера доходит уже обычный собранный из sass -> css и haml -> html файлы, спасибо Sprockets, даже javascript уже неудобно писать, удобнее на coffeescript он тоже проходит «незаметно» через спрокетс и становится обычным js. Потому проблем не вижу.
IDE — RubyMine прекрасно понимает haml, scss, slim, coffeescript…
В остальных случаях до браузера доходит уже обычный собранный из sass -> css и haml -> html файлы, спасибо Sprockets, даже javascript уже неудобно писать, удобнее на coffeescript он тоже проходит «незаметно» через спрокетс и становится обычным js. Потому проблем не вижу.
IDE — RubyMine прекрасно понимает haml, scss, slim, coffeescript…
Вот видите как всё сложно, не говоря уже об отладке, багах в либах и прочих рабочих моментах. Чвуствуешь себя мышью хавающей кактус, а не бойцом иноватором.
Мне как-то без разницы, без проблем пользуюсь тем. что под руками есть. Единственно, что coffeescript осваивать опасаюсь и ещё не пробовал. Здесь же главное отдавать отчёт в том, зачем ты это делаешь, какие плюсы получаешь и какие минусы, оценивать риски.
Беда когда как автор топик, напридумываешь себе проблем про один файли выкатываешь какую-то какашку, потому что боишься связываться с непривычными технологиями. Печально когда 10 лет опыта, а каждый как первый.
Мне как-то без разницы, без проблем пользуюсь тем. что под руками есть. Единственно, что coffeescript осваивать опасаюсь и ещё не пробовал. Здесь же главное отдавать отчёт в том, зачем ты это делаешь, какие плюсы получаешь и какие минусы, оценивать риски.
Беда когда как автор топик, напридумываешь себе проблем про один файли выкатываешь какую-то какашку, потому что боишься связываться с непривычными технологиями. Печально когда 10 лет опыта, а каждый как первый.
Напротив ничего сложного нет, это может быть из PHP мира выглядит сложно, в Rails это ежедневная обыденность.
Про HAML:
— Более трудоемко натягивание готовой верстки на шаблонизатор (конвертация html в haml), особенно правки верстальщика вносить. Необходимо знать ещё один язык. Ну, это без специфики PHP
— Отсутствие референсной стабильной реализации для PHP (штук 5 в свое время попробовал — у всех свои проблемы)
— Нестандартный синтаксис для PHP (если использовать ванильный HAML, есть например pHAML с HAML не совместим, но больше для PHP подходит)
— Сложности с внедрением PHP-кода как прямо в шаблон, так и хелперами (может уже решили, с года назад заценивал)
— Что-то ещё, не помню уже :)
В общем проблем много, а польза не очевидна.
— Более трудоемко натягивание готовой верстки на шаблонизатор (конвертация html в haml), особенно правки верстальщика вносить. Необходимо знать ещё один язык. Ну, это без специфики PHP
— Отсутствие референсной стабильной реализации для PHP (штук 5 в свое время попробовал — у всех свои проблемы)
— Нестандартный синтаксис для PHP (если использовать ванильный HAML, есть например pHAML с HAML не совместим, но больше для PHP подходит)
— Сложности с внедрением PHP-кода как прямо в шаблон, так и хелперами (может уже решили, с года назад заценивал)
— Что-то ещё, не помню уже :)
В общем проблем много, а польза не очевидна.
Пример кода с выводом списка, где кроме шаблона нужно ещё писать кучу циклов в контроллере наглядно демонстрирует что вы за семь лет умудрились написать небольшой кусок говна, единственным достоинством которого является то, что какашка помещается в один файл.
Самое печальное, что за 7 лет вы этого так и не поняли, поэтому я вынужден высказаться так жёстко.
Самое печальное, что за 7 лет вы этого так и не поняли, поэтому я вынужден высказаться так жёстко.
Опять же, это дело вкуса. Например в других шаблонизаторах мне как раз не понравились что часто for-циклы указываються в самом шаблоне с конкретными названиями переменных из PHP кода. Я считаю что этим должен заниматься программист, а не дизайнер. Тоесть у программиста есть 1000 разных способов как передать данные, и про это не должен знать дизайнер. Дизайнер должен знать только
<!-- BEGIN .... --> и <!-- END ... --> 
Очень грубо. Есть множество людей (я отношу себя к таким же), которые считают, что ЛЮБАЯ логика (циклы это логика) в шаблоне — это унылое гавно, ибо предпочитают отделять мух (шаблон) от котлет (логики). Причем отделять полностью.
P.S> ради холивара, кхе-кхе. Код типа:
будет работать в быстрее ЛЮБОГО шаблонизатора, причем без ничего, кроме php
P.S> ради холивара, кхе-кхе. Код типа:
$tmpl = 'some template for out some $var1 variable';
$var1 = 'Vasya Pupkin';
eval('$page="'.$tmpl.'";');
echo $page;
будет работать в быстрее ЛЮБОГО шаблонизатора, причем без ничего, кроме php
не понял, что уникального в форматировании значений. в Smarty есть модификаторы, можно писать кастомные.
Мне кажется, или «Шаблонизатор PHP» звучит уже не серьезно?
Ощущение, будто вы провели последние года 2 в пещере, где и писали свой велосипед, извините за прямоту.
Шаблонизатор от программиста, до сих пор работающего с cp1251?
github.com/zendframework/zf2/blob/master/library/Zend/Filter/StringToUpper.php, например
return strtoupper($value);github.com/zendframework/zf2/blob/master/library/Zend/Filter/StringToUpper.php, например
НЛО прилетело и опубликовало эту надпись здесь
Я пока для себя не наблюдаю веских причин работать с шаблонизатором.
Когда то давно, когда набирался опыта, я работал с шаблонизатором Smarty, радовался, что теперь у меня меньше логики стало попадаться в отображении, но меня просто преследовало желание писать сложные условные ветвления в шаблонах.
Потом пошел работать, почитал литературы, пристрастился к паттерну MVC, и теперь понятия не имею зачем нужен шаблонизатор?
Зачем нужен шаблонизатор?
Когда то давно, когда набирался опыта, я работал с шаблонизатором Smarty, радовался, что теперь у меня меньше логики стало попадаться в отображении, но меня просто преследовало желание писать сложные условные ветвления в шаблонах.
Потом пошел работать, почитал литературы, пристрастился к паттерну MVC, и теперь понятия не имею зачем нужен шаблонизатор?
Зачем нужен шаблонизатор?
НЛО прилетело и опубликовало эту надпись здесь
Грамотное проектирование избавит вас от макаронного кода.
Физически ограничить верстальщика, отобрать возможность инициализировать переменные, дать доступ только к однообразным if, foreach. Контроль кода в конце концов.
Если дать верстальщику семантику шаблонизатора, поставить задачу, которая ну никак не вяжется с пробрасываемыми в шаблонизатор переменными — и вы получите макароны уже через месяц работы: появятся очень причудливые JS-скрипты, которые оперируют с проброшенными данными.
Физически ограничить верстальщика, отобрать возможность инициализировать переменные, дать доступ только к однообразным if, foreach. Контроль кода в конце концов.
Если дать верстальщику семантику шаблонизатора, поставить задачу, которая ну никак не вяжется с пробрасываемыми в шаблонизатор переменными — и вы получите макароны уже через месяц работы: появятся очень причудливые JS-скрипты, которые оперируют с проброшенными данными.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Нужно заметить, что проекты с относительно недавнего делаются на backbone, и тогда при чем тут бэкбон, если мы обсуждаем PHP-шаблонизатор? Спутанность мыслей какая то выходит.
Давайте разберемся: я четко высказался по поводу шаблонизатора: «Не нужен шаблонизатор, если у вас идет четкое разделение в приложении на логику и отображение».
Можно легко следовать простым правилам, даже, используя, функциональное программирование. Что вам мешает вынести ACL в контроллер? Что мешает дробить на мелкие вьюхи и настраивать кэширование блоков в контроллерах?
Давайте разберемся: я четко высказался по поводу шаблонизатора: «Не нужен шаблонизатор, если у вас идет четкое разделение в приложении на логику и отображение».
Можно легко следовать простым правилам, даже, используя, функциональное программирование. Что вам мешает вынести ACL в контроллер? Что мешает дробить на мелкие вьюхи и настраивать кэширование блоков в контроллерах?
НЛО прилетело и опубликовало эту надпись здесь
Думал над вашими словами. И теперь склоняюсь к тому, что вы в чем то правы, что упрощение, «урезание» логики в шаблонах имеет место быть.
Я, как вариант, думаю над возможностью разработки анализатора plain php файлов на предмет избыточного усложнения логики. Это скорей всего для средних проектов на 50-100 отображений, для ускорения процедуры рефакторинга.
Спасибо за дискуссию, за то что донесли свою мысль в достаточно сдержанном тоне.
Я, как вариант, думаю над возможностью разработки анализатора plain php файлов на предмет избыточного усложнения логики. Это скорей всего для средних проектов на 50-100 отображений, для ускорения процедуры рефакторинга.
Спасибо за дискуссию, за то что донесли свою мысль в достаточно сдержанном тоне.
Напомнило www.source-code.biz/MiniTemplator/
при живом то твиге, который через композер за 15 секунд подтягивается…
Простите, но почему дизайнеров держат за интерсных товарищей*, которым нельзя доверять?
1. Если дизайнер затрудняется — то может спросить.
2. Если мы дизайнеру не доверяем, то зачем мы вообще вместе работаем.
3. Если жи всё таки есть принцип доверяй, но проверяй, то вот проще написать валидатор кода дизайнера, что он там не использует чего-то «запрещенного».
Ждём написания нового шаблонизатора а-ля twig, написанного на smarty с использованием brainfuck`а
1. Если дизайнер затрудняется — то может спросить.
2. Если мы дизайнеру не доверяем, то зачем мы вообще вместе работаем.
3. Если жи всё таки есть принцип доверяй, но проверяй, то вот проще написать валидатор кода дизайнера, что он там не использует чего-то «запрещенного».
Ждём написания нового шаблонизатора а-ля twig, написанного на smarty с использованием brainfuck`а
РАсшифровка звездочек -- но сэйф фор ворк
* долбаёбов
Дизайнеры — это которые верстальщик, или который разукрашивает, или который дизайн-архитектуру приложения делает? :)
Просто есть UI/UX дизайнеры, дизайнеры-иллюстраторы, есть системные архитекторы, так сказать дизайнеры архитектуры. Многие считают, что верстальщик тоже дизайнер, но это ведь не так. Дизайнер UI/UX спроектировал, граф. дизайнер или дизайнер-оформитель разукрасил, а верстальщик порезал и создал HTML.
Вообще слово «дизайнер» довольно общее, поэтому уточняйте.
Здравая мысль по поводу валидатора «запрещенного». Было бы кстати увидеть валидатор чистых php view-файлов, без всяких шаблонизаторов.
Просто есть UI/UX дизайнеры, дизайнеры-иллюстраторы, есть системные архитекторы, так сказать дизайнеры архитектуры. Многие считают, что верстальщик тоже дизайнер, но это ведь не так. Дизайнер UI/UX спроектировал, граф. дизайнер или дизайнер-оформитель разукрасил, а верстальщик порезал и создал HTML.
Вообще слово «дизайнер» довольно общее, поэтому уточняйте.
Здравая мысль по поводу валидатора «запрещенного». Было бы кстати увидеть валидатор чистых php view-файлов, без всяких шаблонизаторов.
| Кипит наш разум возмущённый (с)
Поэтому я особо не разделял понятий. Короче те, для кого изначально и задумывались всякие смарти: «template designer».
www.smarty.net/docs/en/what.is.smarty.tpl
Вообще изначальная цель — to separate application logic and content from its presentation уже давно достигнута всякими MVC и следующими за ними концепциями.
Шаблонизаторы ИМХО — прошлый век.
Поэтому я особо не разделял понятий. Короче те, для кого изначально и задумывались всякие смарти: «template designer».
www.smarty.net/docs/en/what.is.smarty.tpl
Вообще изначальная цель — to separate application logic and content from its presentation уже давно достигнута всякими MVC и следующими за ними концепциями.
Шаблонизаторы ИМХО — прошлый век.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Separate – Шаблонизатор для PHP