Pull to refresh

Comments 95

Не вижу ничего, что могло бы заставить меня использовать его в своих проектах
к сожалению такаяже ситуация. Синтаксис шаблонов у того-же смарти мне кажется намного удобнее.
Скорее всего это привычка. И всё-таки, да, у smarty действительно удобный синтаксис. Следующим в моём рейтинге идёт twig.
а еще template inheritance в обоих (twig/smarty)
Аналогично. Поставил плюс за попытку, но серьёзных преимуществ не вижу.
Здесь трудно с вами не согласится, так как проекты и потребности у каждого разные.
Я выбрал данное решение потому что:
1. Я не хотел добавлять громоздкие шаблонизаторы типа Smarty в проект, который состоит всего из нескольких файлов (В Separate вам нужно добавить всего один файл в ваш проект.)
2. Мне нравиться что этот шаблонизатор является обектно-ориентированным и его можно расширять как угодно. Например, переменным, которые часто встречаются, можно автоматически элегантно присвоить значения.
UFO landed and left these words here
Почему же все забывают, что PHP сам по себе шаблонизатор, зачем делать шаблонизатор на шаблонизаторе?

Да и опять же концепция разрыва блочных тегов по нескольким шаблонам приводит к сложнообнаруживаемым ошибкам.
Наследование шаблонов — очень полезная вещь.

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

Ну а из плюсов: тот же Smarty все равно компилирует себя в php-код.
А меня всегда удивляло: почему в документациях к фреймворкам, часть с описанием функционала шаблонизаторов всегда называется как-нибудь в духе «for designer» или «designer guid». Причем тут дизайнеры?)
Замечательно на этот вопрос отвечает не менее замечательная статья
Перевод: Шаблонизаторы в PHP

Я намеренно указал в скобках «верстальщика», т. к. зачастую дизайнер является и верстальщиком своих художеств.
Потому что профессия верстальщика есть только в бывшем СССР.
Потому что на западе html/css верстальщики и называются дизайнерами.
А вот и нет. Они умеют дизайнить.
Почему они там так называются — это другой вопрос:)
На самом деле вопрос в том, почему это наши дизайнеры не умеют верстать, а верстальщик считается ниже дизайнера. И дизайнер, и программист должны уметь верстать.
Я вообще все считаю, что все должны уметь программировать — хотя бы немножко:)
UFO landed and left these words here
Судя по документации, кэширование у вас не установлено. Планируете?
Тот же Smarty, например кэширует (компилирует в native php) и работает в результате довольно шустро.
В старых версиях движка уже было встроено кеширование, но так как я изначально писал движок только для себя, оно не имело «товарный вид». Поэтому я эту возможность полностью убрал из актуальной версии. Конечно в будущем я планирую добавить такую возможность, но тогда она будет сделана основательно.
Хм… А зачем кавычки? Зачем такой сложный синтаксис? Циклов тоже нет?
<!-- IF '${MY_VARIABLE}' == 'hello' -->

Кроме Smarty что еще рассматривали?

Для меня наиболее приятен Twig — может и вам пригодится.
> Хм… А зачем кавычки?

Можно и без кавычек если сравниваются числа.

> Кроме Smarty что еще рассматривали?

Кроме Smarty рассматривал еще каких 5-10 шаблонизаторов. Но должен сказать что в 2004 году многих популярных еще не было.
За почти 10 лет много что изменилось.
Еще один шаблонизатор для шаблонизатора (в прошлом)?

Я сам пишу на php, и использую twig. Его и вам рекомендую.
Я сам пишу на PHP, и использую теги вида:
<?php echo 123;?>

<?php foreach($array as $k => $v):?>
...
<?php endforeach;?>

<?php if(true):?>
...
<?php endif;?>
и т.д.
Чего и все рекомендую!

Ave holy war!
Не, ну для дизайнера это тяжко. Проще так:

{{ 123 }} {% for k,v in array %} {% endfor %} {% if true %} {% endif %}

И кстати, не надо двоеточием. Так в IDE потом неудобно работать.
А чем же тогда, если не двоеточием?
Если использовать PHP как шаблонизатор и использовать фигурные дужки то выходит нечитабельный лапшекод!
И я считаю что такие: <?php… ?> теги больше похожи на HTML чем такие: {{ 123 }}, так что по поводу того что проще, я с вами не согласен.
Да и зачем дизайнеру лезть в код? Пусть рисует себе на здоровье!
Ну, я верстальщика имел в виду.

<< А чем же тогда, если не двоеточием?
<?php while(1) { ?>
// Мой PHPStorm прекрасно индентит этот блок, а скобочки видит (т.е. можно по ним прыгать). 
<?php } ?>


<< И я считаю что такие: <?php… ?> теги больше похожи на HTML чем такие: {{ 123 }}, так что по поводу того что проще, я с вами не согласен.
Дело вкуса. Я по многим причинам twig люблю.
Вы слишком сильно привязаны в вашей IDE, и пытаетесь всем остальным навязать её стиль, точнее недостатки. Может лучше заставить PHPStorm видеть в том числе и for(): endfor;? Прыгать по скобочкам конечно хорошо, но плохо, когда не видно что именно скобки закрывают, для этого точно придётся прыгать вверх и обратно.
Я вообще не встраиваю php-код в html (в основном), т.к. использую шаблонизаторы (smarty и twig).
Ну откуда мне это знать, если приводите код с HTML вставкой, а ведь именно о таком применении шла речь.
ИМХО, скобочки в таком варианте жутко не читабельны.
А мне наоборот сложно найти, где заканчивается блок, если используются не фигурные скобки. А при установке курсора на одну скобку большинство редакторов и IDE подсветит вторую.
О да, это конечно проще, не смейтесь, дизайнер не блондинка, запомнить 10 команд думаю способен.
Вы это Фабиану скажите (создателю twig и симфони), он вам все объяснит. Вкратце — да, так проще.
А главное, что теперь представление никак не зависит от логики.
И кстати, не надо двоеточием. Так в IDE потом неудобно работать.

Именно двоеточием и нужно. Нетбинс, насколько я помню, прекрасно это жует.
Простое правило — если код целиком находится в php теге — фигурные скобки. Если же вставляются куски html — двоеточие (излишне говорить, что в функциях и классах html не стоит использовать). И код ваш будет чист и прекрасен.
<< излишне говорить, что в функциях и классах html не стоит использовать
Ну так я и не использую.

Что-то я не понимаю, на хабре лобби против twig?
Просто старой гвардии из отряда «PHP как шаблонизатор» тут больше. Я сам таким был, пока не попробовал коксtwig, теперь понимаю как сильно ошибался :)

Есть еще такие которые, попробовали шаблонизаторы и поняли, что nativ php лучше =)
не забываем про короткую запись <?=$foo?>
На некоторых хостингах запрещена такая запись, в целях безопасности.
А тут (http://www.php.net/manual/en/ini.core.php#ini.short-open-tag) пишут что начиная с 5.4.0 всегда можно использовать короткий тег.
Срочно шлите эту ссылку в сапорт всех хостинг провайдеров где такая запись запрещена =)
Нет смысла её слать. Как только они начнут массово использовать 5.4 (ну этак через парочку лет эдак), проблемы просто не будет, т.к. отключить через ini такой синтаксис будет нельзя. Просто разработчики сделали правильное решение — отвязали этот синтаксический сахар от short_open_tag.
Может я и ошибаюсь, но по моему если запрещено <?, то и <?= автоматом тоже запрещено.
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/

Столько пляски вокруг фигурных скобок…
Потому что PHP-программисты вообще это не используют. Используют верстальщики. Нафига им изучать какой-то хамл вместо любимой хтмлешечки?
После slim (а раньше haml) обычный html вызывает отвращение, как верстальщик говорю.
Здесь минус еще в том что если все писать на Haml, то потом нельзя просто взять и скопировать сторонний кусок кода. Его тогда тоже придется конвертировать в Haml (если это вообще возможно).
А потом можно haml2slim конвертировать (https://github.com/fredwu/haml2slim), тоже в консоли. Натравить на папку views, а дальше все само.
Это не совсем шаблонизаторы, это кодогенераторы.
Какой смысл в нём? Вот получил я от верстальщика форму, вставил плейсхолдеры и всё заработало. зачем мне ещё переводить html во псевдоязык?
p.s. Пользовался такими в php и в node, но кроме неудобств ничего путного не заметил. Может что-то пропустил или в руби это даёт какие-то дополнительные возможности?
Первое что радует, всё очень чисто, намного легче зрительно найти, то что нужно. Второе — ускоряет автоматический поиск. Есть у вас .lang-switcher.active в css, у вас такой же .lang-switcher.active будет и в slim. Поэтому чтобы найти нужный участок вам нужно всего лишь скопировать, запустить поиск выбрать нужны результат. А в обычном html <div class="lang-switcher active"></div>. А значит такой финт уже не получится.
Я так понимаю, у вас такая проблема возникает как раз от использования slim, у меня IDE без проблем находит в html-е использование классов css с помощью функции Find usages
Удобства возникают, когда верстальщик перестает думать на html и старом css, а СРАЗУ верстает на haml (slim) + scss (sass, less), тогда и дублирований меньше в том же sass можно задать константы, миксины и т.п.

Вот я посмотрю люди так и делают 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…
Вот видите как всё сложно, не говоря уже об отладке, багах в либах и прочих рабочих моментах. Чвуствуешь себя мышью хавающей кактус, а не бойцом иноватором.

Мне как-то без разницы, без проблем пользуюсь тем. что под руками есть. Единственно, что coffeescript осваивать опасаюсь и ещё не пробовал. Здесь же главное отдавать отчёт в том, зачем ты это делаешь, какие плюсы получаешь и какие минусы, оценивать риски.

Беда когда как автор топик, напридумываешь себе проблем про один файли выкатываешь какую-то какашку, потому что боишься связываться с непривычными технологиями. Печально когда 10 лет опыта, а каждый как первый.
Напротив ничего сложного нет, это может быть из PHP мира выглядит сложно, в Rails это ежедневная обыденность.
Я живу в реальном мире и предпочитаю рещать реальные проблемы. В моём текущем проекте нет ни строчки ни php, ни ruby кода, так что не надо про миры и обыденность, зачем решать героически решать проблемы, которых у меня нет?
Тогда как вам этот жалкий шаблонный движок поможет в этом деле? C node и jade тут уж на mustache или handlebars смотреть, а не сюда, как применим haml и sass в node я без понятия, но если так же просто как в ruby то это очень бы облегчало жить в рельных задачах при верстке и поддержке проектов.
Про HAML:
— Более трудоемко натягивание готовой верстки на шаблонизатор (конвертация html в haml), особенно правки верстальщика вносить. Необходимо знать ещё один язык. Ну, это без специфики PHP
— Отсутствие референсной стабильной реализации для PHP (штук 5 в свое время попробовал — у всех свои проблемы)
— Нестандартный синтаксис для PHP (если использовать ванильный HAML, есть например pHAML с HAML не совместим, но больше для PHP подходит)
— Сложности с внедрением PHP-кода как прямо в шаблон, так и хелперами (может уже решили, с года назад заценивал)
— Что-то ещё, не помню уже :)

В общем проблем много, а польза не очевидна.
Пример кода с выводом списка, где кроме шаблона нужно ещё писать кучу циклов в контроллере наглядно демонстрирует что вы за семь лет умудрились написать небольшой кусок говна, единственным достоинством которого является то, что какашка помещается в один файл.
Самое печальное, что за 7 лет вы этого так и не поняли, поэтому я вынужден высказаться так жёстко.
Опять же, это дело вкуса. Например в других шаблонизаторах мне как раз не понравились что часто for-циклы указываються в самом шаблоне с конкретными названиями переменных из PHP кода. Я считаю что этим должен заниматься программист, а не дизайнер. Тоесть у программиста есть 1000 разных способов как передать данные, и про это не должен знать дизайнер. Дизайнер должен знать только <!-- BEGIN .... --> и <!-- END ... -->
Даже на основании вашей разметки в зависимости от значения переменной элементарно реализуется либо вставка значения, либо итерация со вставкой.

А дизайнер должен рисовать картинки, а если кто-то лезет в шаблоны, то ему уже без разницы два или три тега нужно освоить.

Очень грубо. Есть множество людей (я отношу себя к таким же), которые считают, что ЛЮБАЯ логика (циклы это логика) в шаблоне — это унылое гавно, ибо предпочитают отделять мух (шаблон) от котлет (логики). Причем отделять полностью.

P.S> ради холивара, кхе-кхе. Код типа:
$tmpl = 'some template for out some $var1 variable';
$var1 = 'Vasya Pupkin';
eval('$page="'.$tmpl.'";');
echo $page;

будет работать в быстрее ЛЮБОГО шаблонизатора, причем без ничего, кроме php
не понял, что уникального в форматировании значений. в Smarty есть модификаторы, можно писать кастомные.
Мне кажется, или «Шаблонизатор PHP» звучит уже не серьезно?
Ощущение, будто вы провели последние года 2 в пещере, где и писали свой велосипед, извините за прямоту.
Это не ощущение,… как я уже написал выше, все что я делал изначально было предназначено только для собственных проектов.
> Шаблонизатор от программиста, до сих пор работающего с cp1251?

Где вы видете strtoupper в коде шаблонизатора?
А, виноват, это был всего лишь example в тексте статьи
UFO landed and left these words here
Я пока для себя не наблюдаю веских причин работать с шаблонизатором.

Когда то давно, когда набирался опыта, я работал с шаблонизатором Smarty, радовался, что теперь у меня меньше логики стало попадаться в отображении, но меня просто преследовало желание писать сложные условные ветвления в шаблонах.

Потом пошел работать, почитал литературы, пристрастился к паттерну MVC, и теперь понятия не имею зачем нужен шаблонизатор?

Зачем нужен шаблонизатор?
UFO landed and left these words here
Грамотное проектирование избавит вас от макаронного кода.

Физически ограничить верстальщика, отобрать возможность инициализировать переменные, дать доступ только к однообразным if, foreach. Контроль кода в конце концов.

Если дать верстальщику семантику шаблонизатора, поставить задачу, которая ну никак не вяжется с пробрасываемыми в шаблонизатор переменными — и вы получите макароны уже через месяц работы: появятся очень причудливые JS-скрипты, которые оперируют с проброшенными данными.
UFO landed and left these words here
UFO landed and left these words here
Нужно заметить, что проекты с относительно недавнего делаются на backbone, и тогда при чем тут бэкбон, если мы обсуждаем PHP-шаблонизатор? Спутанность мыслей какая то выходит.

Давайте разберемся: я четко высказался по поводу шаблонизатора: «Не нужен шаблонизатор, если у вас идет четкое разделение в приложении на логику и отображение».

Можно легко следовать простым правилам, даже, используя, функциональное программирование. Что вам мешает вынести ACL в контроллер? Что мешает дробить на мелкие вьюхи и настраивать кэширование блоков в контроллерах?
UFO landed and left these words here
Думал над вашими словами. И теперь склоняюсь к тому, что вы в чем то правы, что упрощение, «урезание» логики в шаблонах имеет место быть.

Я, как вариант, думаю над возможностью разработки анализатора plain php файлов на предмет избыточного усложнения логики. Это скорей всего для средних проектов на 50-100 отображений, для ускорения процедуры рефакторинга.

Спасибо за дискуссию, за то что донесли свою мысль в достаточно сдержанном тоне.
при живом то твиге, который через композер за 15 секунд подтягивается…
Простите, но почему дизайнеров держат за интерсных товарищей*, которым нельзя доверять?

1. Если дизайнер затрудняется — то может спросить.
2. Если мы дизайнеру не доверяем, то зачем мы вообще вместе работаем.
3. Если жи всё таки есть принцип доверяй, но проверяй, то вот проще написать валидатор кода дизайнера, что он там не использует чего-то «запрещенного».

Ждём написания нового шаблонизатора а-ля twig, написанного на smarty с использованием brainfuck`а

РАсшифровка звездочек -- но сэйф фор ворк
* долбаёбов
Дизайнеры — это которые верстальщик, или который разукрашивает, или который дизайн-архитектуру приложения делает? :)

Просто есть 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 и следующими за ними концепциями.

Шаблонизаторы ИМХО — прошлый век.
Only those users with full accounts are able to leave comments. Log in, please.