Почему почти все PHP-фреймворки используют "<? Php echo...?>"

Question

• Короткий тег PHP <?= $var ?> на некоторое время устарела.
• Почти все PHP-фреймворки используют длинную форму <?php echo $var ?> (например, симфония, Yii, Kohana)
• Smarty - известный движок шаблонов PHP, который поддерживает более короткую форму {$var}
• Шаблонные движки (такие как Smarty) проще для веб-дизайнера
  • Редактирование шаблонов шоу {$var} вместо того, чтобы ничего не показывать (из-за <..>)
  • Более короткий синтаксис (меньше печатать, особенно когда <> находятся на одной клавише на некоторой раскладке клавиатуры)
  • Шаблоны предварительно скомпилированы и кэшированы, обеспечивая почти одинаковую производительность

Все эти моменты заставляют меня задуматься, почему все фреймворки используют сверхдлинный синтаксис PHP? Есть ли смысл не использовать шаблонизатор, такой как Smarty (кроме небольших накладных расходов)?

Answer 1

Вот что Fabien Potencier из среды Symfony говорит о шаблонизаторах:

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

Он также описывает функции, которые он ищет на языке шаблонов:

• краткость
• Шаблонно-ориентированный синтаксис
• Повторное использование
• Безопасность
• Режим песочницы

А также некоторые особенности, которые выделяют его любимый язык шаблонов: Twig выделяется:

• Собственное наследование шаблонов (шаблоны компилируются как классы);
• Точное автоматическое автоматическое экранирование (без связанных с этим накладных расходов времени выполнения, поскольку все делается во время компиляции);
• Очень безопасный режим песочницы (внесите в белый список теги, фильтры и методы, которые можно использовать в шаблонах);
• Отличная расширяемость: вы переопределяете все, даже основные функции, связывая собственные теги и фильтры в качестве расширения; но вы также можете манипулировать AST (абстрактным синтаксическим деревом) перед компиляцией. Используя эти возможности, вы даже можете создать свой собственный DSL (предметно-ориентированный язык), ориентированный на ваше приложение.

В комментариях к статье он говорит, что "вероятно, это будет часть Symfony 2. Но сначала мне нужно получить отзывы сообщества".

Прочитайте полную статью, чтобы получить его полный аргумент в пользу шаблонных систем.

Answer 2

Суть PHP в том, что это уже язык шаблонов.

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

Большинство фреймворков достаточно гибкие, поэтому добавление шаблонизатора не займет много работы. Если был создан фреймворк, который заставлял вас использовать Smarty, то он будет менее популярен, потому что сам фреймворк был бы менее гибким.

Что касается "длинного синтаксиса", ни один фреймворк не собирается вешать на устаревший синтаксис проблемы с безопасностью. Это может быть оставлено на усмотрение пользователя платформы, если он хочет использовать его или нет (что сегодня никому не нужно), но построение базовой структуры на основе коротких тегов делает ее менее переносимой.

Answer 3

Я не знаю, что бы я позвонил <?php print $foo; ?> "супер длинный синтаксис."

Дело в том, что короткие ярлыки не всегда включены на серверах, тогда как стандартное значение по умолчанию обычно. Более безопасный путь по этому маршруту.

Answer 4

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

По своему опыту я редко видел, чтобы непрограммист полностью или легко использовал шаблонизатор. Возьмите эти два случая:

Smarty:

<select>
{foreach from=$k item=v}
 <option value="{$v.value|escape:'html'}">{$v.label|escape:'html'}</option>
{/foreach}
</select>

PHP:

<select>
<?php foreach ($k as $v) { ?>
 <option value="<?php echo htmlentities($v['value']); ?>"><?php echo htmlentities($v['label']); ?></option>
<?php } ?>
</select>

Теперь синтаксис Smarty может быть немного чище - но, честно говоря, кто-нибудь, кроме программиста, сможет работать с любым набором кодов комфортно? Шаблонные движки добавляют дополнительный уровень обработки / логики, не предлагая каких-либо существенных преимуществ.

Answer 5

Короткие открытые теги не устаревают и также не будут удалены в PHP6.

• [PHP-DEV] Бросив E_DEPRECATED для short_open_tag
• [PHP-DEV] Re: Правда ли, что short_open_tag устарела в PHP 6?
• [PHP-DEV] short_open_tag
• Запрос комментариев: улучшены короткие теги для шаблонов

Связанные статьи также содержат много полезной информации по теме.

Цитируя Расмуса Лердорфа (3-я ссылка):

Большинство аргументов, которые я видел, в основном говорят <? это зло, и оно даже не должно существовать, но это не текущий вопрос. Он существует, и мы не удаляем его, поэтому единственным реальным аргументом здесь является фактор WTF, представленный кодом, который может включать или отключать эти теги на лету. Это единственный действительный аргумент, который я видел. Может ли код PHP быть проверен с помощью xmllint и нет <? действительно XML, что, очевидно, не является, совершенно не в этом дело. Мы все знаем, что когда вы используете <? Вы не XML-совместимы. И для подавляющего большинства это нормально. [...]

Я считаю, что люди хотят создавать шаблоны. Несмотря на то, что я ненавижу эту концепцию и всегда очень открыто об этом говорю, люди хотят более простые шаблоныные теги. Они даже дойдут до синтаксического анализа файлов и генерации PHP-кода для каждого отдельного запроса для использования {blah} вместо <?php blah() ?>, Тот факт, что люди готовы принять удар по производительности на синтаксический сахар на порядок, меня сбивает с толку, но просто посмотрите на все системы шаблонов. И да, я знаю, что есть и другие причины для использования шаблонов, такие как ограничение набора функций для ненадежных авторов шаблонов и т. Д., Но вы удивитесь, сколько людей просто захотят печатать меньше, и их теги будут красивее. Заставить этих людей переключиться на <?blah()?> это победа за производительность и здравомыслие в моей книге. Да, это не полная победа, но это все же победа.

---

Лично я стараюсь избегать шаблонизирующих систем, так как нахожу обычный синтаксис PHP намного проще в качестве языка шаблонов, который заново изобретает то, что PHP может делать из коробки. С добавлением ViewHelpers у любого дизайнера не должно быть особых проблем с использованием обычного синтаксиса. На самом деле, я всегда находил аргумент в пользу того, что движок шаблонов (например, Smarty) проще для веб-дизайнера. Многословный синтаксис PHP может показаться эстетически не привлекательным, но любой полу-мозг может его освоить.

Answer 6

Есть несколько причин:

• Они должны быть исключены из будущих версий php из-за проблем безопасности.
• Некоторые хосты отключают их.

Больше:

Являются ли короткие теги PHP приемлемыми для использования?

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

я согласна с тем что

Я не покупаю читабельность в качестве причины вообще. У большинства серьезных разработчиков есть возможность подсветки синтаксиса.

Больше

http://terrychay.com/article/short_open_tag.shtml

Answer 7

В дополнение к другим ответам есть пара вещей, которые делают Smarty (и подобные шаблоны) проблемными.

Во-первых, вам нужно экранировать некоторые символы в вашем шаблоне, если вы собираетесь добавить в него javascript. Если ваш javascript динамически создается PHP, он становится еще хуже; читаемость этого кода резко снижается.

Вторым и наиболее важным является то, что, когда вы работаете в приличной OO-инфраструктуре, Smarty значительно снизит функциональность вашего кода. При использовании PHP в качестве механизма шаблонов вы можете использовать $this в своем шаблоне для вызова методов в контроллере, который анализирует шаблон. Кроме того, вы получаете доступ ко всем методам, которые унаследовал контроллер. С smarty вы теряете всю эту функциональность, потому что $this больше не относится к вашему контроллеру. По сути, вместо того, чтобы получать доступ ко всей вашей структуре из вашего шаблона, у вас есть доступ только к ограниченной функциональности Smarty.

Answer 8

Потому что они не хотят включать такую ​​огромную библиотеку, как Smarty, чтобы сделать их шаблоны на несколько символов короче.