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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

Шаблонные движки, такие как 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 4

Вот что Фабьен Потенциер из платформы Symfony говорит о шаблонизаторах :

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

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

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

А также некоторые функции, которые выделяют его любимый язык шаблонов Веточка :

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

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

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

Answer 5

Короткие открытые теги не устарели, и они также not будут удалены в 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, чтобы сделать их шаблоны на несколько символов короче.