Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 50
Чем Jade приниципиально отличается от простого php+html?
Отличный ответ. В карму насрали надеюсь?
Чем этот странный синтаксис лучше обычного PHP+HTML? Почему это удобней? Почему бы мне сразу HTML не генерировать?
Чем этот странный синтаксис лучше обычного PHP+HTML? Почему это удобней? Почему бы мне сразу HTML не генерировать?
Чем этот странный синтаксис лучше обычного PHP+HTML? Почему это удобней? Почему бы мне сразу HTML не генерировать?
Любители haml, slim, jade, etc — обычно отвечают: «это быстрее пишется, чище выглядит и невозможно допустить ошибки с незакрытыми тегами».
Лично я пока не покупаюсь на подобные аргументы. В случае споров «CS vs. JS» или «SCSS vs CSS» — я выберу первое, т.к. изменение всем понятного синтаксиса (соответственно изучение нового) влечёт реальные перспективные возможности, то в данном случае («Jade vs Html») — это обмен «шила на мыло», каких-то супер-возможностей добавляется не так уж и много, что бы страдать и избавляться от привычек использования клавиатурных сокращений в любимой IDE, или избавляться от привычек Zen-кодинга.
:style
| body {
| background: yellow;
| }
Этот вариант хуже чем в HAML, потому что нужно ставить на каждую строку |
Как в Jade записывать несколько атрибутов data-? Например, data-name=«name», data-value=«value»
Ну это описана работа через фильтры. Ничего не мешает написать
Атрибуты — ключ-значение через запятую в круглых скобках, автор выше указал пример.
style(type='text/css'). и после точки ниже всё содержимое блока для тега будет интерпретироваться как plain-text.Атрибуты — ключ-значение через запятую в круглых скобках, автор выше указал пример.
Кстати, почему-то не по глазам ссылка в посте на jade-lang.com/demo/
Из явных плюсов Jade вижу неплохое сокращение кода в шаблонах за счет его своеобразного синтаксиса взятого с haml, а из явных минусов то, что верстальщику придется учить не только особенность вывода переменных и фильтров, но и этот своеобразный синтаксис с нуля. Не всегда это оправдано. А вообще штука интересная, надо попробовать задействовать в каком-нибудь простом проекте.
p.s. в composer все таки бы надо добавить
p.s. в composer все таки бы надо добавить
Что-то не вижу я особого удобства ради которого бы продал обычный php + html. Сейчас любая нормальная IDE автоматически сделает большую часть работы по тегам и их атрибутам, да еще и корректность их проверит. php-вставки — это да, немного усложняют жизнь (я про время их написания), но не настолько чтобы прикручивать шаблонизатор. PHP сам по себе — лучший шаблонизатор =)
А вот это вот вообще бессмысленно
А вот это вот вообще бессмысленно
:php
| $value = 10;
| $computed_value += 100;
| print $computed_value;
Тут дело не в удобстве.
Дело в том, что в других языках этот шаблонизатор используется и привычен, кто-то для кого он привычен будет его и в PHP использовать.
Вопрос только зачем люди из других языков приходят в PHP и тащат всякое.
По-моему это зло, поддержка проекта при смене разработчиков сильно усложнится и будет дороже, по сравнению с привычными для PHP инструментами, т.к. людей с большим опытом в jade, я думаю не сильно много.
Дело в том, что в других языках этот шаблонизатор используется и привычен, кто-то для кого он привычен будет его и в PHP использовать.
Вопрос только зачем люди из других языков приходят в PHP и тащат всякое.
По-моему это зло, поддержка проекта при смене разработчиков сильно усложнится и будет дороже, по сравнению с привычными для PHP инструментами, т.к. людей с большим опытом в jade, я думаю не сильно много.
Очень редко PHP-шаблонизатор умеет автоматически экранировать выводимые строки. И еще редко умеет наследование шаблонов. В остальном разница минимально, но, ИМХО, эти два пункта очень важны.
Я сейчас говорю не в пользу JadePHP, а в пользу полноценного шаблонизатора VS обычный PHP
Тут нужно определится что такое «обычный PHP»
Если у нас MVC или хотя бы логика отображения просто отделена — то по сути некоторую часть кода можно обозвать шаблонизатором.
И тут уже будет так как захочет разработчик — рамок нет. А если разработчик грамотный, то получится все может очень даже неплохо.
Если у нас MVC или хотя бы логика отображения просто отделена — то по сути некоторую часть кода можно обозвать шаблонизатором.
И тут уже будет так как захочет разработчик — рамок нет. А если разработчик грамотный, то получится все может очень даже неплохо.
Под «обычным PHP» я понимаю шаблонизатор, в котором внутри HTML мы пишем PHP код. Примеры:
Под полноценным шаблонизатором я понимаю такие шаблонизаторы как
- kohanaframework.org/3.3/guide/kohana/mvc/views
- www.yiiframework.com/doc-2.0/guide-view.html
- ellislab.com/codeigniter/user-guide/general/views.html
Под полноценным шаблонизатором я понимаю такие шаблонизаторы как
- JadePHP
- Smarty
- Twig
Вообщем-то там есть наследование, либо его можно легко допилить.
С экранированием — это вообще вопрос одного метода короткого, по сути.
При этом разница между Smarty, Twig и JadePHP сильно много больше чем между «обычным PHP» и Smarty,Twig.
С экранированием — это вообще вопрос одного метода короткого, по сути.
При этом разница между Smarty, Twig и JadePHP сильно много больше чем между «обычным PHP» и Smarty,Twig.
Не понимаю что вы мне пытаетесь доказать? В Кохане есть наследование шаблонов? В Laravel есть наследование шаблонов? В CodeIgniter есть наследование шаблонов? В YII? Я не говорю что наследование невозможно сделать на plain php шаблонизаторе, я говорю что обычно этого нету.
С экранированием это не вопрос одного короткого метода. Это вопрос надо ли каждый раз явно указывать экранирование или нет. Опять же простейшие plain php шаблонизаторы обычно просят каждый раз вызывать их один которкий метод, что, как мне кажется, очень плохо. Почему — написал чуть ниже.
С экранированием это не вопрос одного короткого метода. Это вопрос надо ли каждый раз явно указывать экранирование или нет. Опять же простейшие plain php шаблонизаторы обычно просят каждый раз вызывать их один которкий метод, что, как мне кажется, очень плохо. Почему — написал чуть ниже.
Наследование шаблонов реализуется довольно просто и есть во многих фреймворках в том или ином виде. При необходимости можно допилить самому.
Экранирование выводимых строк не всегда нужно, а если его нельзя отключить, то идут маты и проклятья в сторону разрабочиков шаблонизатора. И опять же — фреймворки обычно имеют функцию для экранирования (что-то типа _() или __())
Экранирование выводимых строк не всегда нужно, а если его нельзя отключить, то идут маты и проклятья в сторону разрабочиков шаблонизатора. И опять же — фреймворки обычно имеют функцию для экранирования (что-то типа _() или __())
В любом шаблонизаторе есть функция, которая позволяет не экранировать что-то. Я считаю, что каждый раз писать _() очень плохо, потому это а) надоедает и б) можно забыть вполне. В итоге получаем детские XSS уязвимости.
Согласен, иногда хочется более простого способа экранирования. Но это ведь не повод ставить шаблонизатор. Можно обойтись каким-нить специализированным решением.
Я считаю, что писать каждый явно экранирование при выводе переменной это то же самое, что писать везде mysql_real_escape_string() перед передачей аргументов в библиотеку соединения с БД. Я бы назвал такую библиотеку не очень хорошей, если бы мне пришлось с такой работать.
Почти все известные PHP-шаблонизаторы умеют и то и другое.
Jade в этом плане не приносит ничего нового.
Если вы имеете ввиду plain PHP, хтмл вперемешку с кодом по всему проекту, то слово «редко» у вас лишнее.
Jade в этом плане не приносит ничего нового.
Если вы имеете ввиду plain PHP, хтмл вперемешку с кодом по всему проекту, то слово «редко» у вас лишнее.
Jade в этом плане ничем не лучше того же Smarty или Twig, конечно вы правы. Я имею ввиду именно plain PHP. Не понимаю почему «редко» тут лишнее. Можно написать plain php шаблонизатор, который поддерживает автоматическое экранирование, это точно. Насчет наследования шаблонов не уверен что видел, но наверняка что-то есть, вопрос только в удобстве синтаксиса.
>>Очень редко PHP-шаблонизатор умеет автоматически экранировать выводимые строки
Это просто какая-то непонятная немного фраза.
>>Очень редко plain-PHP умеет автоматически экранировать выводимые строки
Ну так логично вроде бы, зачем язык будет делать что-то что нам может быть и не нужно.
>>Очень редко известный PHP-шаблонизатор(который выделен как отдельный проект) умеет автоматически экранировать выводимые строки
Ну так не правда, все умеют, ну или почти все.
Если речь идет вообще о мешанине хтмл и кода — там я думаю отсутствие автоматического экранирования на общем фоне не проблема даже.
Это просто какая-то непонятная немного фраза.
>>Очень редко plain-PHP умеет автоматически экранировать выводимые строки
Ну так логично вроде бы, зачем язык будет делать что-то что нам может быть и не нужно.
>>Очень редко известный PHP-шаблонизатор(который выделен как отдельный проект) умеет автоматически экранировать выводимые строки
Ну так не правда, все умеют, ну или почти все.
Если речь идет вообще о мешанине хтмл и кода — там я думаю отсутствие автоматического экранирования на общем фоне не проблема даже.
Чуть выше написал: под «PHP-шаблонизатор» я подразумевал plain-PHP шаблонизатор. Вы не путайте plain-PHP шаблонизатор и PHP — это немного разные вещи. Plain-PHP шаблонизатор может автоматически экранировать все — достаточно прозрачно для пользователя заменить все объекты на прокси, как это делали в symfony1.
Мешанина HTML и кода это вопрос вкуса. Разница между {{ var }} и <?=$var?> есть не для всех. Не понимаю как вы тут автоматически такой подход отнесли к не достойным рассмотрения, что отсутствие экранирования это вообще неважно там. Очень много PHP фреймворков используют plain-PHP шаблонизатор.
Мешанина HTML и кода это вопрос вкуса. Разница между {{ var }} и <?=$var?> есть не для всех. Не понимаю как вы тут автоматически такой подход отнесли к не достойным рассмотрения, что отсутствие экранирования это вообще неважно там. Очень много PHP фреймворков используют plain-PHP шаблонизатор.
У нас проблема с непониманием терминов друг друга.
>>Мешанина HTML и кода это вопрос вкуса. Разница между {{ var }} и <?=$var?> есть не для всех.
>>Не понимаю как вы тут автоматически такой подход отнесли к не достойным рассмотрения,
Я имею ввиду вариант когда архитектуры нет вообще, т.е. берется plain PHP и просто тупо пишется нечто, когда еще и трудно понять где шаблон где нет шаблона. Ну по-моему недостойный вариант рассмотрения.
>>Plain-PHP шаблонизатор может автоматически экранировать все — достаточно прозрачно
>>для пользователя заменить все объекты на прокси, как это делали в symfony1.
Получается вы вот выше написали редко, теперь пишете немного другое.
Я же имею ввиду, что по сути разницы сейчас между обычными smarty,twig,«plain-php шаблонизаторами» особо нет.
Просто какие-то ставят некие рамки «smarty, twig» а какие-то нет, но базовый функционал — экранирование и т.д. он есть везде, где-то просто его сложнее использовать.
>>Мешанина HTML и кода это вопрос вкуса. Разница между {{ var }} и <?=$var?> есть не для всех.
>>Не понимаю как вы тут автоматически такой подход отнесли к не достойным рассмотрения,
Я имею ввиду вариант когда архитектуры нет вообще, т.е. берется plain PHP и просто тупо пишется нечто, когда еще и трудно понять где шаблон где нет шаблона. Ну по-моему недостойный вариант рассмотрения.
>>Plain-PHP шаблонизатор может автоматически экранировать все — достаточно прозрачно
>>для пользователя заменить все объекты на прокси, как это делали в symfony1.
Получается вы вот выше написали редко, теперь пишете немного другое.
Я же имею ввиду, что по сути разницы сейчас между обычными smarty,twig,«plain-php шаблонизаторами» особо нет.
Просто какие-то ставят некие рамки «smarty, twig» а какие-то нет, но базовый функционал — экранирование и т.д. он есть везде, где-то просто его сложнее использовать.
Я имею ввиду вариант когда архитектуры нет вообще, т.е. берется 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..
И это плохо, потому что программист будет постоянно забывать где надо вызывать эскейп, а где не надо. В этом принципиальная разница — по умолчанию экранируется или по умолчанию не экранируется. Должно экранироваться. Если по умолчанию ничего не экранируется, это не значит, что просто «его сложнее использовать», это значит что он сломан и так не должно быть и стоит подумать о том чтобы перейти на нормальный шаблонизатор, который экранирует.
>>Если по умолчанию ничего не экранируется, это не значит, что просто «его сложнее использовать», это значит что он сломан и так не должно быть и
>>стоит подумать о том чтобы перейти на нормальный шаблонизатор, который экранирует.
Это очень спорно, во-первых экранировать разное нужно по разному, во-вторых не нужно забывать что бывает не только html
>>И это плохо, потому что программист будет постоянно забывать где надо вызывать эскейп, а где не надо.
Программист который постоянно что-то забывает, от чего окружающие страдают, по-моему совсем не программист и ему лучше пойти заняться чем-нибудь другим.
>>стоит подумать о том чтобы перейти на нормальный шаблонизатор, который экранирует.
Это очень спорно, во-первых экранировать разное нужно по разному, во-вторых не нужно забывать что бывает не только html
>>И это плохо, потому что программист будет постоянно забывать где надо вызывать эскейп, а где не надо.
Программист который постоянно что-то забывает, от чего окружающие страдают, по-моему совсем не программист и ему лучше пойти заняться чем-нибудь другим.
Пограммист человек, а человек всегда что-то забывает. Лучше когда о чем-то вообще не нужно думать и вместо этого думать о более полезных вещах. Все давно забыли каково это экранировать данные перед вставкой в запросы к БД и не парятся больше об этом — об этом беспокоится за них библиотека доступа к БД.
В подавляющем большинстве случаев просто надо вывести строку безопасно в HTML и все. Да, где-то не совсем так, где-то надо вырезать не все теги, где-то надо вообще в JS. Но это детали — это все можно всегда явно указать при выводе, если вам надо нестандартно как-то это делать. В большинстве случаев просто надо сделать htmlspecialchars и все.
В подавляющем большинстве случаев просто надо вывести строку безопасно в HTML и все. Да, где-то не совсем так, где-то надо вырезать не все теги, где-то надо вообще в JS. Но это детали — это все можно всегда явно указать при выводе, если вам надо нестандартно как-то это делать. В большинстве случаев просто надо сделать htmlspecialchars и все.
Я лишь говорю о категоричности и максимализме ваших заявлений.
>>это значит что он сломан и так не должно быть
Нет не сломан, он такой какой есть, он так задумывался. Хотите по другому делайте по другому, но не надо всем это внушать.
>>И это плохо, потому что программист будет постоянно забывать
Категоричное постоянно, повторюсь если постоянно забывать — ему надо чем-то другим заняться.
>>В подавляющем большинстве случаев просто надо вывести строку безопасно в HTML и все. Да, где-то не совсем так, где-то надо
>>вырезать не все теги, где-то надо вообще в JS.
Вот-вот, он уверенно постоянно не думает, ведь экранируется же. А раз еще и склонен постоянно забывать что-то — то точно в частном случае накосячит. А это уже даже хуже, чем если бы он везде косячил — заметить труднее. Так что нифига не панацея.
Повторюсь — я не считаю ваш подход с экранированием по умолчанию плохим, делайте как нравится, только не надо говорить категоричное «сломан, не должно быть». Автоматическое экранирование и тд и тп — не серебряная пуля, уж лучше подумать об автоматическом тестировании.
>>это значит что он сломан и так не должно быть
Нет не сломан, он такой какой есть, он так задумывался. Хотите по другому делайте по другому, но не надо всем это внушать.
>>И это плохо, потому что программист будет постоянно забывать
Категоричное постоянно, повторюсь если постоянно забывать — ему надо чем-то другим заняться.
>>В подавляющем большинстве случаев просто надо вывести строку безопасно в HTML и все. Да, где-то не совсем так, где-то надо
>>вырезать не все теги, где-то надо вообще в JS.
Вот-вот, он уверенно постоянно не думает, ведь экранируется же. А раз еще и склонен постоянно забывать что-то — то точно в частном случае накосячит. А это уже даже хуже, чем если бы он везде косячил — заметить труднее. Так что нифига не панацея.
Повторюсь — я не считаю ваш подход с экранированием по умолчанию плохим, делайте как нравится, только не надо говорить категоричное «сломан, не должно быть». Автоматическое экранирование и тд и тп — не серебряная пуля, уж лучше подумать об автоматическом тестировании.
К сожалению любые аргументы в пользу автоматического экранирования, как и большинство аргументов в пользу чего-нибудь в спорах в программировании крайне субъективны. Поэтому когда разные люди имеют разные мнения на одну и ту же проблему это нормально. Я не считаю, например, что приверженность к plain php шаблонам это признак непрофессионализма. Однако это не мешает мне быть уверенным, что plain php шаблоны в том виде в котором они присутствуют в большинстве фреймворков сломаны и что так делать неправильно. У меня есть определенные аргументы в пользу моего мнения. У вас есть аргументы в пользу вашего, они тоже субъективны, как и мои. Поэтому мы не можем друг другу ничего доказать. Но не вижу проблемы в том, что я заявляю это так категорично — для меня это действительно так, для меня это действительно важно, это можно сказать серебрянная пуля против сайтов, в которых XSS на каждой странице.
>> Это очень спорно, во-первых экранировать разное нужно по разному
Ну 99% экранирования это таки htmlspecialchars. Ну и никто не мешает в шаблонизаторе использовать какой угодно фильтр.
Ну 99% экранирования это таки htmlspecialchars. Ну и никто не мешает в шаблонизаторе использовать какой угодно фильтр.
Пару лет назад попробовал воспользоваться JadePHP, но отсутствие буквально всех возможностей, заявленных для JS-версии, и некоторые нюансы реализации, а также отсутствие развития проекта, заставили меня забыть про него. В итоге написал свою реализацию, для KohanaFramework-а. Синтаксис взял за основу тот же, что и в jade, но изменил несколько ключевых моментов:
1. все операнды начинаются с @, чтобы не путать с именами тегов (when, case, default, if, elseif и пр.)
2. добавил конструкцию @attr attributename value (позволяющую задать или дополнить аттрибут тега или @mixin-а не в скобках (куда явно много не поместится, сохранив читаемый вид), а как внутренний элемент. Пример:
Мой HTML-код изобилует огромным количеством аттрибутов. Многие из них опциональны, многие из них являются результатом конкатенации или получаются тренарным оператором. Стандартный синтаксис jade не позволил мне это сделать удобно и выразительно.
3. Добавил mixin-ы с именованным параметрами. Очень удобно когда описываешь какой-нибудь @mixin для кнопки, умеющий принимать с десяток параметров, сохранив читаемый вид кода.
Пример того как у меня это всё выглядит
С первого взгляда может показаться разноцветным нечто, но когда используешь его каждый день, становится очень удобно. Едва ли я перейду на какой-нибудь не indent-шаблонизатор. Я уже привык к такой лаконичности. Из минусов могу отметить, что не придумал элегантного способами размещать теги вплотную (к примеру <li></li><li></li>), и вообще шаблонизатор заточен для работы с HTML или XML, и совершенно не годится для других задач.
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, и совершенно не годится для других задач.
А мне нравится
Так и Markdown можно шаблонизатором назвать…
Насколько я правильно понял в разделе «Простой пример» после body, начиная с header должен быть еще один отступ, ведь header находится в body (судя по html коду ниже), или я что-то неправильно понял?
Подскажите, пожалуйста, из описания не понял, если нет закрывающихся тегов, то как написать строку типа
Мой классный заголовок с тегом
Мой классный заголовок с тегом
Если вы придерживаетесь идее «чистого кода» в разработке, то, как это ни странно, но лучше использовать нативный php-шаблонизатор, т.к. его в совершенстве поддерживает Code Inspection хороших IDE, вроде PhpStorm. Единственный минус — в начале каждого шаблона нужно указывать типы переменных. Для экранирования можно сделать короткую функцию e():
Все удобные инструменты IDE, такие как автодополнение, анализ ошибок и рефакторинг, будут распространяться на такие шаблоны.
<?php
/** @var Post[] $posts */
?>
<h1>Posts list</h1>
<?php foreach ($posts as $post):?>
<h2><?=e($post->title)?></h2>
<?=e($post->text)?>
<?php endforeach ?>
Все удобные инструменты IDE, такие как автодополнение, анализ ошибок и рефакторинг, будут распространяться на такие шаблоны.
Честно говоря Jade есть смысл сравнивать только с такими шаблонизаторами как HAML. Нативный PHP с такими как Smarty и Twig. Я за последние несколько лет настолько отвык от второго (вроде приведённого вами кода), что подобный код мне кажется просто набором цветных символов. Огрооомная куча лишней писанины. Это в целом проблема XML-подобных синтаксисов, так тут ещё и <?-php теги. Человек вкусивший удобства лаконичности Ruby или Python поймёт что я имею ввиду :) Дело в том что в 99.5% случаев при написании HTML мы нуждаемся в возможности указать имя тега, его класс, его id, какие-то прочие аттрибуты, и его внутренности. indent-шаблонизаторы позволяют это сделать весьма лаконично и удобно. Огромные массивные и запутанные template/*.php.html превращаются в одноэкранные наборы jade-@mixin-ов. Рекомендую попробовать.
Возможно моя нелюбовь ещё продиктована тем, что до Jade я использовал, в основном, XSLT… После него несложно возненавидеть всё XML-подобное :)
//- Post[] $posts
h1 Posts list
each $post in $posts
h2=$ost->title
=$post->textВозможно моя нелюбовь ещё продиктована тем, что до Jade я использовал, в основном, XSLT… После него несложно возненавидеть всё XML-подобное :)
Из статьи понял, что не стоит перелазить со Smarty на Jade.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в JadePHP