29 мая 2014 в 02:58

Введение в JadePHP из песочницы

PHP*
По предложению автора интересностей и полезностей для веб-разработчика #17, предлагаю свой перевод статьи Introduction to JadePHP.

Существуют десятки шаблонизаторов. Среди наиболее известных можно выделить Smarty, Twig (используется в следующей версии Drupal), Blade (используется по умолчанию в Laravel) и, конечно же, vanilla PHP. Если не говорить конкретно о PHP, то для eRuby / ERB и Haml для Ruby / Ruby on Rails и Javascript есть ряд популярных вариантов, как например Mustache, Handlebars, Hogan и EJS. У одних различия в синтаксисе незначительные, у других они более выраженные.

Шаблонизатор Jade, который значительно отличяется от других, обычно ассоциируется с JavaScript приложениями, например он поддерживается в Express для Node.js. В этой статье, я поговорю о Jade или, более конкретно, о Jade сделанной для PHP — JadePHP.

Haml и Jade


Было бы неправильно говорить о Jade, не упомянув Haml, который был вдохновляющей идеей для Jade. И в самом деле, существуют несколько библиотек для поддержки Haml в PHP. Jade придерживается той же философии что и HAML, то есть создание «красивых» шаблонов и то что авторы называют шаблонизацией «хайку». Что бы это не значило, у Haml и Jade есть некоторые одинаковые качества, которые фундаментально отличают их от большинства других шаблонизаторов.

В чем разница?


Большинство шаблонизаторов предполагают написание конечной разметки с «внедрением» в нее placeholder'ов а и основной логики. У Jade же есть не только placeholder'ы и логика, но и способ для сокращенного написания XML подобных элементов. В общем, это означает HTML, хотя вы можете использовать это для RSS и собственно XML.

В сущности, если вы хотите, то вы можете использовать Jade как сокращения для HTML без его «традиционных» шаблонизаторских возможностей.

Как использовать репозиторий


К сожалению, в настоящий момент код недоступен через Composer, хотя его не трудно запаковать, если у кого-то найдется час другой. Но вы можете его запустить, клонировав репозиторий и включив autoload.php.dist (Github репозиторий включает UniversalClassLoader из Symphony).

Ниже, адаптированый пример из README проекта. Предполагается, что репозиторий был помещен в директорию jade.

use Everzet\Jade\Dumper\PHPDumper,
        Everzet\Jade\Visitor\AutotagsVisitor,
        Everzet\Jade\Filter\JavaScriptFilter,
        Everzet\Jade\Filter\CDATAFilter,
        Everzet\Jade\Filter\PHPFilter,
        Everzet\Jade\Filter\CSSFilter,
        Everzet\Jade\Parser,
        Everzet\Jade\Lexer\Lexer,
        Everzet\Jade\Jade;

$dumper = new PHPDumper();
$dumper->registerVisitor('tag', new AutotagsVisitor());
$dumper->registerFilter('javascript', new JavaScriptFilter());
$dumper->registerFilter('cdata', new CDATAFilter());
$dumper->registerFilter('php', new PHPFilter());
$dumper->registerFilter('style', new CSSFilter());

// Initialize parser & Jade
$parser = new Parser(new Lexer());
$jade   = new Jade($parser, $dumper);

$template = __DIR__ . '/template.jade';

// Parse a template (both string & file containers)
echo $jade->render($template);

Этот код скомпилирует файл tempalte.jade и покажет его содержимое.

То где это можно применить, зависит от вашего рабочего процесса, например, используете ли вы framework и т.д. К примеру, можно было бы использовать сервис вроде Watchman, Guard или Resource Watcher, чтобы следить за файловой системой и изменениями в ваших Jade шаблонах, и компилировать их в определенное время в процессе разработки.

Простой пример


Рассмотрим простой пример, который отобразит полную HTML страницу с двумя переменными, пока без логики.
!!! 5
html(lang="en-us")

  meta(charset="utf-8")
  meta(http-equiv="X-UA-Compatible", content="IE=Edge;chrome=1")

  title(dir="ltr")= pageTitle

  meta(name="viewport", content="width=device-width, initial-scale=1.0")

  link(rel="stylesheet", media="screen", href="/css/styles.css")

  body
  header
  h1 My Jade Application
  div#content
  div.inner
      =$bodyContent

  script(data-main="js/main.js", src="js/libs/require.js")

Важно: нужно использовать два пробела для отступа. На данный момент это единственный метод понятный Jade PHP. Иначе возникнут ошибки или это будет некорректная разметка.

Сразу становится очевидным, Jade довольно отличается от привычного HTML. Во-первых, у него нет угловых скобок < > и закрывающих тэгов. А также нет фигурных скобок, двойных фигурных скобок или других общепринятых способов для обозначения переменных в шаблонах. (Тем не менее вы можете использовать синтаксис с двойными фигурными скобками. Но это не является частью Jade).

Jade выглядит как очень сжатый метод для генерирации разметки. Посмотрим на итоговый HTML:
<!DOCTYPE html>
<html lang="en-us">
    <meta charset="utf-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=Edge;chrome=1" />
    <title dir="ltr"><?php echo pageTitle ?></title>
    <meta name="viewport" content="width=device-width" initial-scale="1.0" />
    <link rel="stylesheet" media="screen" href="/css/styles.css" />
    <body>
        <header>
            <h1>My Jade Application</h1>
        </header>
        <div id="content">
            <div class="inner">
                <?php echo $bodyContent ?>
            </div>
        </div>
        <script data-main="js/main.js" src="js/libs/require.js"></script>
    </body>
</html>


Пройдемся по всем ключевым строкам в шаблоне Jade, для того чтобы понять, как работают HTML сокращения.

!!! 5 — сокращение для HTML5 doctype. Это единственное место, где вы увидите тройной восклицательный знак в синтаксисе. Вы также можете использоывать !!! xml, чтобы получить <?xml version="1.0" encoding="utf-8" ?>. Для transitional, вы можете использовать !!! transitional чтобы получить <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">. По умолчанию !!! default даст <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Примечание: в последней версии Jade, приправленной JavaScript, объявление !!! 5 было изменено на doctype html. Возможно, JadePHP последует этому примеру, хотя наверное врядли, судя по отсутсвию активности на Github.

HTML тэг указывается по одному его имени, без необходимости его закрытия. Например:
body
  header

… если бы вы остановились на этом, привело бы к следующему результату:
<body>
  <header></header>
</body>

Заметьте, как структура документа представлена с отступами.

Вы можете поместить содержимое тэга после его имени с пробелами:

h1 My Jade Application

… становится
<h1>My Jade Application</h1>

Если вы хотите разбить большие блоки с содержанием на строки, используйте символ вертикальной черты |:
p 
  | Curabitur blandit tempus porttitor. Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. 
  | Aenean eu leo quam. 
  | Pellentesque ornare sem lacinia quam venenatis vestibulum.

Это скомпилируется в:
<p>Curabitur blandit tempus porttitor. Vivamus sagittis lacus vel augue laoreet rutrum faucibus dolor auctor. Aenean eu leo quam. Pellentesque ornare sem lacinia quam venenatis vestibulum.</p>

Вы можете использовать формат схожий с CSS селекторами для добавления id и class атрибутов в HTML элементы:
div#content
  div.inner

… приводит к:
  <div id="content">
    <div class="inner">

Другие атрибуты как src, href, lang, media, и т.д. могут быть указаны, используя круглые скобки:
html(lang="en-us") === <html lang="en-us">
link(rel="stylesheet", media="screen", href="/css/styles.css") === <link rel="stylesheet" media="screen" href="/css/styles.css" />

Знак равно используется для подстановки переменных. Как видно выше, когда вы компилируете Jade шаблон, он конвертирует:
= $pageTitle

в следующее:
<?php echo $pageTitle ?>


Добавляем немного логики


Вы можете использоывать тире для условной логики. Вот конкретный пример:
header
    h1= $pageTitle
    - if ($loggedIn):
    p.greeting Welcome back!
    - else:
    a(href="/login") Please login
    - endif;

Если скомпилировать этот шаблон, в результате получится следующее:
<header>
    <h1><?php echo $pageTitle ?></h1>
    <?php if ($loggedIn) ?>
    <p class="greeting">Welcome back!</p>
    <?php else ?>
    <a href="/login">Please login</a>
    <?php endif ?>
</header>

Для циклов код очень схожий:
ul
  - foreach ($items as $item):
  li= $item


Фильтры


У JadePHP есть возможность использовать фильтры для обработки блоков текста разными способами. Например:
:php
    | $value = 10;
    | $computed_value += 100;
    | print $computed_value;

…будет преобразован в:
<?php
    $value = 10;
    $computed_value += 100;
    print $computed_value;
?>

Вероятно более полезные фильтры будут для JavaScript и CSS. Например:
:style
| body {
|   background: yellow;
| }

…будет преобразован в:
<style type="text/css">
body {
  background: yellow;
}

Устанавливаются эти фильтры следующим образом (смотри пример с кодом выше для понимания контекста этих объявлений):
$dumper->registerFilter('javascript', new JavaScriptFilter()); 
$dumper->registerFilter('php', new PHPFilter());
$dumper->registerFilter('style', new CSSFilter());

Первый аргумент — это текст, который вы размечаете в своем шаблоне с добавлением двоеточия. Для примера выше вы можете использовать :javascript, :php и :style соответственно.

Если включить Everzet\Jade\Filter\FilterInterface, то вы даже можете определять свои собственные фильтры.

Зачем использовать Jade?


Споры о том какие шаблонизаторы использовать, в конечном счете, довольно бесполезны. Вы можете сделать тесты, для того чтобы определить какие шаблонизаторы являются лучше по производительности в различных условиях, а какие больше подходят в определенных средах, например на клиенте или сервере. Но в конечном итоге, выбор часто зависит от того что для вас комфортнее. У меня нет намерений подливать масла в огонь, так же как и учавствовать в спорах о лучшем языке програмирования.

Метод сокращения Jade не для всех. Одни люди будут утверждать что его легче читать, а другие страстно с этим не согласятся. Но если вы считаете что это достойный метод, то это уже хороший повод его выбрать.

Другая причина, по которой вы можете решить использовать Jade (кстати говоря о количестве шаблонизаторов) — это чередование между технологиями. Если вы часто переключаетесь между, скажем, Node.js и PHP, то существует некоторая логика для поддержания постоянства. Зачем изучать один инструмент, а затем использовать что-то совершенно другое, если он доступен для многих языков?

Резюме


В этой статье я рассмотрел JadePHP, портированный шаблонизатор Jade, изначально ориентированный на JavaScript. Я дал вам несколько наводок на то, как его использовать, и идей о том, зачем он вам может понадобится. Попробуете ли вы его, или он кажется вам необоснованно сжатым? Напишите что вы о нем думаете в комментариях.
@kgbalien
карма
5,0
рейтинг 0,0
Похожие публикации
Самое читаемое Разработка

Комментарии (50)

  • –3
    Чем Jade приниципиально отличается от простого php+html?
    • –2
      Отличный ответ. В карму насрали надеюсь?

      Чем этот странный синтаксис лучше обычного PHP+HTML? Почему это удобней? Почему бы мне сразу HTML не генерировать?
      • 0
        Чем этот странный синтаксис лучше обычного PHP+HTML? Почему это удобней? Почему бы мне сразу HTML не генерировать?

        Любители haml, slim, jade, etc — обычно отвечают: «это быстрее пишется, чище выглядит и невозможно допустить ошибки с незакрытыми тегами».

        Лично я пока не покупаюсь на подобные аргументы. В случае споров «CS vs. JS» или «SCSS vs CSS» — я выберу первое, т.к. изменение всем понятного синтаксиса (соответственно изучение нового) влечёт реальные перспективные возможности, то в данном случае («Jade vs Html») — это обмен «шила на мыло», каких-то супер-возможностей добавляется не так уж и много, что бы страдать и избавляться от привычек использования клавиатурных сокращений в любимой IDE, или избавляться от привычек Zen-кодинга.
  • +1
    :style
    | body {
    | background: yellow;
    | }

    Этот вариант хуже чем в HAML, потому что нужно ставить на каждую строку |

    Как в Jade записывать несколько атрибутов data-? Например, data-name=«name», data-value=«value»
    • 0
      Ну это описана работа через фильтры. Ничего не мешает написать style(type='text/css'). и после точки ниже всё содержимое блока для тега будет интерпретироваться как plain-text.
      Атрибуты — ключ-значение через запятую в круглых скобках, автор выше указал пример.
    • 0
      Кстати, почему-то не по глазам ссылка в посте на jade-lang.com/demo/
  • +1
    Из явных плюсов Jade вижу неплохое сокращение кода в шаблонах за счет его своеобразного синтаксиса взятого с haml, а из явных минусов то, что верстальщику придется учить не только особенность вывода переменных и фильтров, но и этот своеобразный синтаксис с нуля. Не всегда это оправдано. А вообще штука интересная, надо попробовать задействовать в каком-нибудь простом проекте.

    p.s. в composer все таки бы надо добавить
  • +4
    Что-то не вижу я особого удобства ради которого бы продал обычный php + html. Сейчас любая нормальная IDE автоматически сделает большую часть работы по тегам и их атрибутам, да еще и корректность их проверит. php-вставки — это да, немного усложняют жизнь (я про время их написания), но не настолько чтобы прикручивать шаблонизатор. PHP сам по себе — лучший шаблонизатор =)

    А вот это вот вообще бессмысленно
    :php
    | $value = 10;
    | $computed_value += 100;
    | print $computed_value;
    • –1
      Тут дело не в удобстве.
      Дело в том, что в других языках этот шаблонизатор используется и привычен, кто-то для кого он привычен будет его и в PHP использовать.
      Вопрос только зачем люди из других языков приходят в PHP и тащат всякое.
      По-моему это зло, поддержка проекта при смене разработчиков сильно усложнится и будет дороже, по сравнению с привычными для PHP инструментами, т.к. людей с большим опытом в jade, я думаю не сильно много.
    • 0
      Очень редко PHP-шаблонизатор умеет автоматически экранировать выводимые строки. И еще редко умеет наследование шаблонов. В остальном разница минимально, но, ИМХО, эти два пункта очень важны.
      • 0
        Я сейчас говорю не в пользу JadePHP, а в пользу полноценного шаблонизатора VS обычный PHP
        • 0
          Тут нужно определится что такое «обычный PHP»
          Если у нас MVC или хотя бы логика отображения просто отделена — то по сути некоторую часть кода можно обозвать шаблонизатором.
          И тут уже будет так как захочет разработчик — рамок нет. А если разработчик грамотный, то получится все может очень даже неплохо.
          • 0
            Под «обычным PHP» я понимаю шаблонизатор, в котором внутри HTML мы пишем PHP код. Примеры:

            Под полноценным шаблонизатором я понимаю такие шаблонизаторы как
            • JadePHP
            • Smarty
            • Twig
            • 0
              Вообщем-то там есть наследование, либо его можно легко допилить.
              С экранированием — это вообще вопрос одного метода короткого, по сути.

              При этом разница между Smarty, Twig и JadePHP сильно много больше чем между «обычным PHP» и Smarty,Twig.
              • 0
                Не понимаю что вы мне пытаетесь доказать? В Кохане есть наследование шаблонов? В Laravel есть наследование шаблонов? В CodeIgniter есть наследование шаблонов? В YII? Я не говорю что наследование невозможно сделать на plain php шаблонизаторе, я говорю что обычно этого нету.

                С экранированием это не вопрос одного короткого метода. Это вопрос надо ли каждый раз явно указывать экранирование или нет. Опять же простейшие plain php шаблонизаторы обычно просят каждый раз вызывать их один которкий метод, что, как мне кажется, очень плохо. Почему — написал чуть ниже.
      • 0
        Наследование шаблонов реализуется довольно просто и есть во многих фреймворках в том или ином виде. При необходимости можно допилить самому.
        Экранирование выводимых строк не всегда нужно, а если его нельзя отключить, то идут маты и проклятья в сторону разрабочиков шаблонизатора. И опять же — фреймворки обычно имеют функцию для экранирования (что-то типа _() или __())
        • 0
          В любом шаблонизаторе есть функция, которая позволяет не экранировать что-то. Я считаю, что каждый раз писать _() очень плохо, потому это а) надоедает и б) можно забыть вполне. В итоге получаем детские XSS уязвимости.
          • 0
            Согласен, иногда хочется более простого способа экранирования. Но это ведь не повод ставить шаблонизатор. Можно обойтись каким-нить специализированным решением.
            • 0
              Для меня это повод поискать шаблонизатор с автоматическим экранированием. Насколько я помню если для вас важно использовать именно PHP в шаблонах, можно поковырять шаблонизатор из symfony1 — он автоматически экранирует. Для меня это не важно, поэтому я юзаю twig.
              • 0
                я использую CakePHP в основном, так что отдельный шаблонизатор особо не нужен.
          • 0
            Я считаю, что писать каждый явно экранирование при выводе переменной это то же самое, что писать везде mysql_real_escape_string() перед передачей аргументов в библиотеку соединения с БД. Я бы назвал такую библиотеку не очень хорошей, если бы мне пришлось с такой работать.
      • 0
        Почти все известные PHP-шаблонизаторы умеют и то и другое.
        Jade в этом плане не приносит ничего нового.

        Если вы имеете ввиду plain PHP, хтмл вперемешку с кодом по всему проекту, то слово «редко» у вас лишнее.
        • 0
          Jade в этом плане ничем не лучше того же Smarty или Twig, конечно вы правы. Я имею ввиду именно plain PHP. Не понимаю почему «редко» тут лишнее. Можно написать plain php шаблонизатор, который поддерживает автоматическое экранирование, это точно. Насчет наследования шаблонов не уверен что видел, но наверняка что-то есть, вопрос только в удобстве синтаксиса.
          • 0
            >>Очень редко PHP-шаблонизатор умеет автоматически экранировать выводимые строки
            Это просто какая-то непонятная немного фраза.

            >>Очень редко plain-PHP умеет автоматически экранировать выводимые строки
            Ну так логично вроде бы, зачем язык будет делать что-то что нам может быть и не нужно.
            >>Очень редко известный PHP-шаблонизатор(который выделен как отдельный проект) умеет автоматически экранировать выводимые строки
            Ну так не правда, все умеют, ну или почти все.

            Если речь идет вообще о мешанине хтмл и кода — там я думаю отсутствие автоматического экранирования на общем фоне не проблема даже.

            • 0
              Чуть выше написал: под «PHP-шаблонизатор» я подразумевал plain-PHP шаблонизатор. Вы не путайте plain-PHP шаблонизатор и PHP — это немного разные вещи. Plain-PHP шаблонизатор может автоматически экранировать все — достаточно прозрачно для пользователя заменить все объекты на прокси, как это делали в symfony1.

              Мешанина HTML и кода это вопрос вкуса. Разница между {{ var }} и <?=$var?> есть не для всех. Не понимаю как вы тут автоматически такой подход отнесли к не достойным рассмотрения, что отсутствие экранирования это вообще неважно там. Очень много PHP фреймворков используют plain-PHP шаблонизатор.
              • 0
                У нас проблема с непониманием терминов друг друга.
                >>Мешанина HTML и кода это вопрос вкуса. Разница между {{ var }} и <?=$var?> есть не для всех.
                >>Не понимаю как вы тут автоматически такой подход отнесли к не достойным рассмотрения,
                Я имею ввиду вариант когда архитектуры нет вообще, т.е. берется plain PHP и просто тупо пишется нечто, когда еще и трудно понять где шаблон где нет шаблона. Ну по-моему недостойный вариант рассмотрения.

                >>Plain-PHP шаблонизатор может автоматически экранировать все — достаточно прозрачно
                >>для пользователя заменить все объекты на прокси, как это делали в symfony1.
                Получается вы вот выше написали редко, теперь пишете немного другое.
                Я же имею ввиду, что по сути разницы сейчас между обычными smarty,twig,«plain-php шаблонизаторами» особо нет.
                Просто какие-то ставят некие рамки «smarty, twig» а какие-то нет, но базовый функционал — экранирование и т.д. он есть везде, где-то просто его сложнее использовать.

                • 0
                  Я имею ввиду вариант когда архитектуры нет вообще, т.е. берется plain PHP и просто тупо пишется нечто, когда еще и трудно понять где шаблон где нет шаблона. Ну по-моему недостойный вариант рассмотрения.

                  Само собой, конечно. Видимо не так поняли друг друга.
                  >>Plain-PHP шаблонизатор может автоматически экранировать все — достаточно прозрачно
                  >>для пользователя заменить все объекты на прокси, как это делали в symfony1.
                  Получается вы вот выше написали редко, теперь пишете немного другое.

                  Да, я написал «редко» и тут не противоречу себе. Plain-PHP шаблонизатор в symfony1 это единственный известный мне шаблонизатор, который автоматически экранирует все что выводится. Т.е. вы пишете, к примеру
                     <p><?php echo $user->name ?></p>
                  

                  и не паритесь, что name это ввел пользователь, какого оно типа, может ли туда проскочить HTML вредоносный. Больше PHP-шаблонизаторов, которые автоматически экранируют все что вы выводите я не видел. Большинство других Plain-PHP шаблонизаторов предлагают писать что-нибудь вроде
                    <p><?php echo HTML::chars($user->name); /* kohana style */ ?></p>
                    <p><?php echo html_escape($user->name); /* codeigniter style */ ?></p>
                    // etc..
                  

                  И это плохо, потому что программист будет постоянно забывать где надо вызывать эскейп, а где не надо. В этом принципиальная разница — по умолчанию экранируется или по умолчанию не экранируется. Должно экранироваться. Если по умолчанию ничего не экранируется, это не значит, что просто «его сложнее использовать», это значит что он сломан и так не должно быть и стоит подумать о том чтобы перейти на нормальный шаблонизатор, который экранирует.
                  • 0
                    >>Если по умолчанию ничего не экранируется, это не значит, что просто «его сложнее использовать», это значит что он сломан и так не должно быть и
                    >>стоит подумать о том чтобы перейти на нормальный шаблонизатор, который экранирует.

                    Это очень спорно, во-первых экранировать разное нужно по разному, во-вторых не нужно забывать что бывает не только html

                    >>И это плохо, потому что программист будет постоянно забывать где надо вызывать эскейп, а где не надо.
                    Программист который постоянно что-то забывает, от чего окружающие страдают, по-моему совсем не программист и ему лучше пойти заняться чем-нибудь другим.
                    • 0
                      Пограммист человек, а человек всегда что-то забывает. Лучше когда о чем-то вообще не нужно думать и вместо этого думать о более полезных вещах. Все давно забыли каково это экранировать данные перед вставкой в запросы к БД и не парятся больше об этом — об этом беспокоится за них библиотека доступа к БД.
                      В подавляющем большинстве случаев просто надо вывести строку безопасно в HTML и все. Да, где-то не совсем так, где-то надо вырезать не все теги, где-то надо вообще в JS. Но это детали — это все можно всегда явно указать при выводе, если вам надо нестандартно как-то это делать. В большинстве случаев просто надо сделать htmlspecialchars и все.
                      • 0
                        Я лишь говорю о категоричности и максимализме ваших заявлений.
                        >>это значит что он сломан и так не должно быть
                        Нет не сломан, он такой какой есть, он так задумывался. Хотите по другому делайте по другому, но не надо всем это внушать.
                        >>И это плохо, потому что программист будет постоянно забывать
                        Категоричное постоянно, повторюсь если постоянно забывать — ему надо чем-то другим заняться.
                        >>В подавляющем большинстве случаев просто надо вывести строку безопасно в HTML и все. Да, где-то не совсем так, где-то надо
                        >>вырезать не все теги, где-то надо вообще в JS.
                        Вот-вот, он уверенно постоянно не думает, ведь экранируется же. А раз еще и склонен постоянно забывать что-то — то точно в частном случае накосячит. А это уже даже хуже, чем если бы он везде косячил — заметить труднее. Так что нифига не панацея.

                        Повторюсь — я не считаю ваш подход с экранированием по умолчанию плохим, делайте как нравится, только не надо говорить категоричное «сломан, не должно быть». Автоматическое экранирование и тд и тп — не серебряная пуля, уж лучше подумать об автоматическом тестировании.
                        • 0
                          К сожалению любые аргументы в пользу автоматического экранирования, как и большинство аргументов в пользу чего-нибудь в спорах в программировании крайне субъективны. Поэтому когда разные люди имеют разные мнения на одну и ту же проблему это нормально. Я не считаю, например, что приверженность к plain php шаблонам это признак непрофессионализма. Однако это не мешает мне быть уверенным, что plain php шаблоны в том виде в котором они присутствуют в большинстве фреймворков сломаны и что так делать неправильно. У меня есть определенные аргументы в пользу моего мнения. У вас есть аргументы в пользу вашего, они тоже субъективны, как и мои. Поэтому мы не можем друг другу ничего доказать. Но не вижу проблемы в том, что я заявляю это так категорично — для меня это действительно так, для меня это действительно важно, это можно сказать серебрянная пуля против сайтов, в которых XSS на каждой странице.
                    • 0
                      >> Это очень спорно, во-первых экранировать разное нужно по разному

                      Ну 99% экранирования это таки htmlspecialchars. Ну и никто не мешает в шаблонизаторе использовать какой угодно фильтр.
                      • 0
                        >> это значит что он сломан и так не должно быть
                        >> перейти на нормальный шаблонизатор,

                        Я имел ввиду что вот эти категоричные заявления спорны.
  • +2
    Пару лет назад попробовал воспользоваться JadePHP, но отсутствие буквально всех возможностей, заявленных для JS-версии, и некоторые нюансы реализации, а также отсутствие развития проекта, заставили меня забыть про него. В итоге написал свою реализацию, для KohanaFramework-а. Синтаксис взял за основу тот же, что и в jade, но изменил несколько ключевых моментов:

    1. все операнды начинаются с @, чтобы не путать с именами тегов (when, case, default, if, elseif и пр.)

    2. добавил конструкцию @attr attributename value (позволяющую задать или дополнить аттрибут тега или @mixin-а не в скобках (куда явно много не поместится, сохранив читаемый вид), а как внутренний элемент. Пример:
    a.link( href=$href )
      @attr target _blank
    

    Мой HTML-код изобилует огромным количеством аттрибутов. Многие из них опциональны, многие из них являются результатом конкатенации или получаются тренарным оператором. Стандартный синтаксис jade не позволил мне это сделать удобно и выразительно.

    3. Добавил mixin-ы с именованным параметрами. Очень удобно когда описываешь какой-нибудь @mixin для кнопки, умеющий принимать с десяток параметров, сохранив читаемый вид кода.

    Пример того как у меня это всё выглядит


    С первого взгляда может показаться разноцветным нечто, но когда используешь его каждый день, становится очень удобно. Едва ли я перейду на какой-нибудь не indent-шаблонизатор. Я уже привык к такой лаконичности. Из минусов могу отметить, что не придумал элегантного способами размещать теги вплотную (к примеру <li></li><li></li>), и вообще шаблонизатор заточен для работы с HTML или XML, и совершенно не годится для других задач.
  • 0
    А мне нравится
    • 0
      И ошибок в закрытии тегов не будет
      • 0
        >>И ошибок в закрытии тегов не будет
        Вы не пользуетесь IDE?
        • –2
          случаи разные бывают
  • +1
    Спасибо за перевод, для общего развития очень даже подойдет.

    Но…
    1) Стоимость проекта с ним растет, потому как верстальщику нужны доп. скилы.
    2) В случае купленного HTML шаблона вряд ли подойдет.
    3) «чередование между технологиями»: Twig -> Swig или Twig.js

    Вывод: любителям HAML и Ruby-подобных вещей придется по вкусу, но явного выхлопа для PHP проекта я не обнаружил.
    Более того, для проектов на node.js заменяю дефолтный Jade на EJS или другую альтернативу, так как верстальщики плохо реагируют на шаблоны Jade.
  • +1
    Так и Markdown можно шаблонизатором назвать…
    • 0
      Вы меня, конечно, извините, но разница — бездна. Jade — весьма и весьма «навороченный» шаблонизатор. И с MarkDown или вики-разметкой у него практически ничего общего :)
      • 0
        Это ирония была. Впрочем, как мне кажется, Jade ближе к дзен-кодингу, чем к шаблонизатору.
  • 0
    Насколько я правильно понял в разделе «Простой пример» после body, начиная с header должен быть еще один отступ, ведь header находится в body (судя по html коду ниже), или я что-то неправильно понял?
  • 0
    Подскажите, пожалуйста, из описания не понял, если нет закрывающихся тегов, то как написать строку типа
    Мой классный заголовок с тегом

    • 0
      Извиняюсь, хабр съел все теги.

      тег1 мой классный тег 2 заголовок тег2-закр с тегом тег1-закр
      • 0
        Не очень вас понял.
        tag1 Мой классный тег
          tag2 заголовок

        =>
        <tag1>Мой классный тег <tag2> заголовок</tag2></tag1>
        • 0
          Вы меня правильно поняли (: Спасибо
  • 0
    Если вы придерживаетесь идее «чистого кода» в разработке, то, как это ни странно, но лучше использовать нативный php-шаблонизатор, т.к. его в совершенстве поддерживает Code Inspection хороших IDE, вроде PhpStorm. Единственный минус — в начале каждого шаблона нужно указывать типы переменных. Для экранирования можно сделать короткую функцию e():

    <?php
    /** @var Post[] $posts */
    ?>
    <h1>Posts list</h1>
    <?php foreach ($posts as $post):?>
        <h2><?=e($post->title)?></h2>
        <?=e($post->text)?>
    <?php endforeach ?>
    

    Все удобные инструменты IDE, такие как автодополнение, анализ ошибок и рефакторинг, будут распространяться на такие шаблоны.
    • 0
      Честно говоря Jade есть смысл сравнивать только с такими шаблонизаторами как HAML. Нативный PHP с такими как Smarty и Twig. Я за последние несколько лет настолько отвык от второго (вроде приведённого вами кода), что подобный код мне кажется просто набором цветных символов. Огрооомная куча лишней писанины. Это в целом проблема XML-подобных синтаксисов, так тут ещё и <?-php теги. Человек вкусивший удобства лаконичности Ruby или Python поймёт что я имею ввиду :) Дело в том что в 99.5% случаев при написании HTML мы нуждаемся в возможности указать имя тега, его класс, его id, какие-то прочие аттрибуты, и его внутренности. indent-шаблонизаторы позволяют это сделать весьма лаконично и удобно. Огромные массивные и запутанные template/*.php.html превращаются в одноэкранные наборы jade-@mixin-ов. Рекомендую попробовать.

      //- Post[] $posts
      h1 Posts list
      each $post in $posts
        h2=$ost->title
        =$post->text


      Возможно моя нелюбовь ещё продиктована тем, что до Jade я использовал, в основном, XSLT… После него несложно возненавидеть всё XML-подобное :)
  • –2
    Из статьи понял, что не стоит перелазить со Smarty на Jade.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.