Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 70
Интересно, шорттэги существуют с версии 3.0, а то и ранее. Есть мнение (например от everzet) что это зло, а добро в использовании ненативных шаблонизаторов. Тем более, что сначала short_open_tag=on (вроде) считалось deprecated. Однако с 5.4 конструкция <?= $foo ?> включена всегда. Случались ли у кого конфликты с другими языками на практике?
С xml проблемы, да.
<?php if ($category_tree && count($category_tree)): ?>
<?php foreach($category_tree as $category): ?>
<?= $category->name ?>
<?php endforeach; ?>
<?php else: ?>
No items in tree
<?php endif; ?>
Хоть както полегчало за счет этого
<?= $category->name ?>?Окей окей, у вас собственный VPS, где вы можете включить шорты на начало/конец блоков кода тоже:
<? if ($category_tree && count($category_tree)): ?>
<? foreach($category_tree as $category): ?>
<?= $category->name ?>
<? endforeach; ?>
<? else: ?>
No items in tree
<? endif; ?>
Наконец ваш шаблон читабелен и лаконичен, так?
Ах и да, часто вместо
Сравниваем:
<?= $category->name ?> у вас будет что-то вроде:<? $meta = $category->getMetaInformation(); ?>
<?= $meta['name'] ?>
Сравниваем:
{{ category.metaInformation.name }}
Костя, могло быть <?= $category->getMetaInfotmation()->getName() ?> и в темплейте был бы а) автокомплит и б) возможность переименовать функции во всех местах где она используется.
Да, не очень удобно в случае множества скинов — потребуется заморозить интерфейс модели и/или поддерживать устаревшие методы. Но когда скинов не планируется, то вызовы модели кажутся удобнее. Невзирая на нелаконичные "->get" и скажем "<?=escape($text)?>".
Да, не очень удобно в случае множества скинов — потребуется заморозить интерфейс модели и/или поддерживать устаревшие методы. Но когда скинов не планируется, то вызовы модели кажутся удобнее. Невзирая на нелаконичные "->get" и скажем "<?=escape($text)?>".
Давай предположим, что эта метаинформация — контейнер переменного размера, в который сущности системы могут помещать что угодно и когда угодно, помимо типичной информации типа «name». В этом случае, использование объекта для представления меты излишне, хэш для этого подходит куда лучше ;-)
Да, пример достаточно редкий, но не «невозможный».
Да, пример достаточно редкий, но не «невозможный».
То есть наличие чистого публичного API домена для вас — говнокод, а опубличивание пропертей домена с целью упрощения шаблонов — вариант «без говнокода». ОК!
Мои примеры абсолютно одинаковые. Twig автоматически заресолвит:
В:
Или в:
В зависимости от того, что из себя представляет
{{ category.metaInformation.name }}
В:
$meta = $category->getMetaInformation();
echo $meta['name'];
Или в:
echo $category->getMetaInformation()->getName();
В зависимости от того, что из себя представляет
$category. Это и называется отделением логики от представления.Т.е. вы специально вяжете ActiveRecord на все объекты, которые хотите выводить в шаблоне, чтобы упростить ваши шаблоны?
Давайте теперь представим, что
Давайте теперь представим, что
$category собирается в памяти, никуда не персистится и имеет структуру, которую я в начале привел. Что будете делать? Привяжете туда ActiveRecord или просто добавите публичные проперти, чтобы упростить шаблон?
А существует ли «самый лучший синтаксис»? Шаблонизаторы — такая же штука в этом плане, как и языки программирования. Назовите лучший :)
В пхп вообще очень многое тырят с других языков. Например Twig это почти точь в точь шаблонизатор из Django
Начиная с php 5.4 директива short_open_tag исчезает, а поддержка шот-тегов теперь включена всегда. Поэтому глупо не использовать их, если в качестве языка для кодирования шаблонов используется сам php.
Вы не объясните от чего вы так все «зло» воспринимаете?
Вы не объясните от чего вы так все «зло» воспринимаете?
Шорттеги — добро, шаблонизация через php-интерпретатор — зло.
Шорттеги — ок, шаблонизатор на нативном PHP — вдвойне ОК
Я за вариант — «Не использую, потому что не известно будет ли это поддерживаться сервером, а так бы использовал с удовольствием.»
Не использую, потому что это может вызвать зло несовместимости — но стану использовать, когда PHP 5.4.0 завоюет мир (и умы хостеров), так что конструкция «<?=» сможет употребляться невозбранно.
Хотелось бы конструкцию <?php=$var ?> — решило бы проблему излишнего синтаксиса и совместимости с xml
Проявление чувства юмора при составлении опроса сводит на нет адекватность результатов голосования, но подчеркивает наличие чувства юмора у большинства Хабровчан.
Использую Twig:
{{foo}}
Включаю сокращенную запись (short_open_tag) и радуюсь жизни =)
XML:
ЗЛО:
<?=$variable?>
<?foreach($arr as $v) {?>
<?print_r($v)?>
<?}?>
XML:
<?='<?xml version="1.0" encoding="UTF-8"?>'?>
ЗЛО:
<?php echo $foo ?>
<? if(true): ?>
<? endif; ?>
Обычно те, кто используют «длинный» синтаксис по причине «совместимости с xml», при прямом вопросе, в каком именно случае эта совместимость реально требуется в их проектах, не могут ничего вразумительного ответить.
Это актуально для популярных опенсорс-систем типа phpbb и т.д. (впрочем, в phpbb свой шаблонизатор). Там важна совместимость, чтобы все ставилось сразу же из коробки. Таких систем — довольно мало, и трудно поверить, что большая часть программистов, фанатично использующих длинный синтаксис, на самом деле разработчики таких систем. Большинство людей пишет конкретные проекта для конкретных целей, и совместимость с шаред-хостингами (которую к тому де можно легко подправить настройками php_flag в .htaccess на большинстве хостингов) не играет значительной роли.
Но даже <?=$а?> — огромное зло, потому что на самом деле в 99.9% мест, где так написано, в действительности должно было быть написано <?=htmlspecialchars($а)?>. Увы, данная архитектурная проблема тянется с самой зари php, с ней уже ничего не сделать. В мире существуют миллионы сайтов с xss благодаря ней, и число растет. Шаблонизаторы только и спасение.
А почему не экранировать данные шаблона непосредственно перед отправкой в представление?
Даже если у нас написана своя низкоуровневая быстрая f() функция, которая фильтрует что угодно — вызывать ее каждый раз как-то лень и некрасиво, разве нет?
Даже если у нас написана своя низкоуровневая быстрая f() функция, которая фильтрует что угодно — вызывать ее каждый раз как-то лень и некрасиво, разве нет?
Мне кажется, что PHP не тот язык, в котором стоило бы заниматься подобной оптимизацией. Во всяком случае в большинстве ситуаций. Напоминает экономию спичек на фоне пожара. Гораздо важнее иметь легко-понимаемый лаконичный код и структуру, которую не потребуется через пол года переписывать. Ведь такого рода действия в контроллере противоестественны. 99% проектов на PHP не имеют никаких сложностей с производительностью, более того, чаще всего оная упирается в запросы к БД или кривую логику.
А использование шаблонизаторов позволяет в разы упростить восприятие, написание вёрстки. А в случае, таких шаблонизаторов как XSLT, верстальщик ещё и лишается возможности выстрелить себе в ногу.
А использование шаблонизаторов позволяет в разы упростить восприятие, написание вёрстки. А в случае, таких шаблонизаторов как XSLT, верстальщик ещё и лишается возможности выстрелить себе в ногу.
Таки я не говорил ничего против шаблонизаторов. Я предложил людям с развитым головным мозгом обсудить идею экранирования данных непосредственно перед отправкой в шаблон, чтобы не беспокоиться об этом в представлении и не мусорить его.
людям с развитым головным мозгомВоспринимать как оскорбление?
обсудить идею экранирования данных непосредственно перед отправкой в шаблонНу а я о чём писал? На мой взгляд, это противоречит MVC, т.к. представление должно решать в каком виде необходимы данные, а не контроллер.
Воспринимать как оскорбление?
Нет.
Контроллеру решать какие и в каком виде данные передаются в представление. Чем противоречит? Уже и приведение типа к целочисленному GET параметра в контроллере не сделать? :)
Нет.
На мой взгляд, это противоречит MVC, т.к. представление должно решать в каком виде необходимы данные, а не контроллер.
Контроллеру решать какие и в каком виде данные передаются в представление. Чем противоречит? Уже и приведение типа к целочисленному GET параметра в контроллере не сделать? :)
Уже и приведение типа к целочисленному GET параметра в контроллере не сделатьПричём тут это? Контроллер принял задачу, определил\обработал входные параметры, замучал модель и отправил итоговые данные в представление. А уж в каком виде их применит представление — дело 10-ое. Разве не так? На мой взгляд, в вашем случаем замусоривается контроллер.
Кажется мы не об одном и том же говорим. Я имею в виду нормально спроектированную систему. Мы можем переопределить класс View и переопределить метод Assign(или render, в заисимости от того как предаются данные) и автоматически принимать во вьюхе безопасные данные. Там же можно и решить проблему с получением оригинальных данных, когда нужно.
Не нужно в контроллере эту злосчастную низкоуровневую f() вызывать :D Это и правдо глупо.
Не нужно в контроллере эту злосчастную низкоуровневую f() вызывать :D Это и правдо глупо.
Это и правдо глупоЯ использую XSLT, и никаких f() не вызываю, однако этим занимается сам шаблонизатор. Не вижу в этом никаких проблем, + всё очень гибко. Если мне в одном месте понадобится экранированные данные, а в другом нет — мне достаточно указать disable-output-escaping. Нет необходимости на уровне контроллера решать — какие данные мне передать в двух видах, какие экранировать, а какие нет. Особенно если учесть, что view-часть можно сильно измениться, без необходимости изменения логики получения итоговых данных.
Одну и ту же строку я могу использовать и как аттрибут, и как html, и как css, и как что угодно. Нет необходимости для этого лезть в controller и что-либо там менять. На мой взгляд, он, контроллер, об этом вообще ничего знать не должен. Он даже не обязан знать для чего эти данные добыл, что будет на выходе? HTML? XSLT? JSON? закодированное_письмо_для_внеземных_цивилизаций?
Дополню. Ситуация мне напоминает magic quotes.
А почему не экранировать данные шаблона непосредственно перед отправкой в представление?
Экранирование придется вызывать на месте, оно везде разное: для html нужно просто заменять &,<,>, для аттрибутов еще и экранировать кавычки, а при выводе в JS строки еще и удалять переводы строк, делать url_encode при выводе в урл и т.п.
Экранирование не надо «вызывать». Оно само должно вызываться, и сопротивляться своему выключению (даже однократному). Поэтому я и говорю, что экранирование во вью — дело шаблонизатора, а экранирование sql — дело библиотеки работы с бд. Само понятие «экранирование» — ущербно по своей природе: есть сырые данные, есть результат, а есть «серный ящик», который из первого делает второе по указанной вами инструкции (шаблонизатор, например). Нет в этой картине мира нигде никакого «экранирования».
Что бы не делать <?=htmlspecialchars($a)?> нужно фильтровать и экранировать символы перед записью в db.
Удалять через str_replace лишние слэши перед выдачей *HEADWALL*
Там выше писали про Magic Quotes, и я вспомнил случай на работе, когда пришлось дописывать пару фич к старинному приложению, в котором пользовательский ввод экранировался через Magic Quotes, что приводило при многократном сохранении данных к длинным рядам обратных слэшей в базе данных, которые я потом вырезал при экспорте :)
Даже и не знаю. За все время работы ни разу не встречал хостинга, где невозможно было бы использовать «короткие теги» — как минимум, эта опция была доступна в htaccess'е.
В случае, если нужно включить в документ XML тоже есть решение. Это, конечно, костыль, но не слишком некрасивый:
В случае, если нужно включить в документ XML тоже есть решение. Это, конечно, костыль, но не слишком некрасивый:
<<??>?xml version="1.0" encoding="UTF-8"?<??>>
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
<? if: ?>Используете ли вы <?=шорттэги?> в темплейтах<? endif ?>