<? if: ?>Используете ли вы <?=шорттэги?> в темплейтах<? endif ?>

     

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

    <? if: ?>Используете ли вы <?=шорттэги?> в темплейтах<? endif ?>

    • 34.7%Использую. Писать <?php echo $foo ?> противоестественно505
    • 3%Использую, но перестану, потому что это зло44
    • 29.5%Не использую, потому что это зло430
    • 32.6%PHP - зло475
    Поделиться публикацией

    Комментарии 70

      +1
      Интересно, шорттэги существуют с версии 3.0, а то и ранее. Есть мнение (например от everzet) что это зло, а добро в использовании ненативных шаблонизаторов. Тем более, что сначала short_open_tag=on (вроде) считалось deprecated. Однако с 5.4 конструкция <?= $foo ?> включена всегда. Случались ли у кого конфликты с другими языками на практике?
        +2
        С xml проблемы, да.
          +2
          Адъ то какой.
          А не пробовали работать с XML нормально, при помощи соответствующих модулей, а не заниматься рукоделием и клеить строки?
            +1
            Ок, но можно же сказать: используйте шаблонизаторы и не занимайтесь рукоделием :)

            Бывает надо просто и быстро сгенерировать xml размером в несколько сотен метров, а то и несколько гигабайт в условии ограниченных ресурсов.
              –1
              но можно же сказать: используйте шаблонизаторы и не занимайтесь рукоделием

              Полностью согласен. <irony>Кто не юзает шаблонизвтор — тот какашка.</irony>

              Только не забывайте, что PHP — тоже шаблонизатор.

              А теперь поподробнее про многогигабайтный XML, пожалуйста.
            0
            Используйте XmlWriter.
              +1
              Бывает надо просто и быстро сгенерировать xml размером в несколько сотен метров, а то и несколько гигабайт в условии ограниченных ресурсов.
                0
                XmlWriter с этим отлично справляется.
            +4
            <?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; ?>
            

            Наконец ваш шаблон читабелен и лаконичен, так?
              0
              Ах и да, часто вместо <?= $category->name ?> у вас будет что-то вроде:

              <? $meta = $category->getMetaInformation(); ?>
              <?= $meta['name'] ?>
              


              Сравниваем:

              {{ category.metaInformation.name }}
              
                +1
                Костя, могло быть <?= $category->getMetaInfotmation()->getName() ?> и в темплейте был бы а) автокомплит и б) возможность переименовать функции во всех местах где она используется.

                Да, не очень удобно в случае множества скинов — потребуется заморозить интерфейс модели и/или поддерживать устаревшие методы. Но когда скинов не планируется, то вызовы модели кажутся удобнее. Невзирая на нелаконичные "->get" и скажем "<?=escape($text)?>".
                  0
                  Давай предположим, что эта метаинформация — контейнер переменного размера, в который сущности системы могут помещать что угодно и когда угодно, помимо типичной информации типа «name». В этом случае, использование объекта для представления меты излишне, хэш для этого подходит куда лучше ;-)

                  Да, пример достаточно редкий, но не «невозможный».
                  +1
                  Ага, берем шаблон, пишем на нем код, переписываем на PHP специально говнокодя.
                  И предлагаем сравнить этот нормальный код и этот говнокод.
                  Вам определенно надо идти в политику.

                  А теперь аналог для {{ category.metaInformation.name }} без говнокода:
                  <?= $category->metaInformation->name ?>

                  Шаблоны использовать необходимо, но использование PHP в виде шаблонизатора — обычная практика, а плюсы и минусы незначительны, и, помоему мнению, вопрос не стоит и выеденого яйца.
                    0
                    То есть наличие чистого публичного API домена для вас — говнокод, а опубличивание пропертей домена с целью упрощения шаблонов — вариант «без говнокода». ОК!
                      +1
                      Я еще раз повторю: ваши примеры разные, и сравнение не в пользу шаблонизатора PHP.
                      Я привел однотипные примеры, где выходная информация имеет одинаковую структуру.
                        0
                        Мои примеры абсолютно одинаковые. Twig автоматически заресолвит:

                        {{ category.metaInformation.name }}
                        

                        В:

                        $meta = $category->getMetaInformation();
                        echo $meta['name'];
                        

                        Или в:

                        echo $category->getMetaInformation()->getName();
                        

                        В зависимости от того, что из себя представляет $category. Это и называется отделением логики от представления.
                          0
                          В моем случае используется ActiveRecord и примеры тоже одинаковые. Только выглядят лучше.
                            +1
                            Т.е. вы специально вяжете ActiveRecord на все объекты, которые хотите выводить в шаблоне, чтобы упростить ваши шаблоны?

                            Давайте теперь представим, что $category собирается в памяти, никуда не персистится и имеет структуру, которую я в начале привел. Что будете делать? Привяжете туда ActiveRecord или просто добавите публичные проперти, чтобы упростить шаблон?
                              0
                              Нет не нак все, но данная сущность с именем «категория» у меня асоциириуется именно с AR.

                              С вами в данному члучае согласен, но вы выдаете частное за общее.
              0
              Есть ли вообще будущее у альтернативных шаблонизаторов? Smarty, Quicky (от developer), Twig… кажется каждый (кроме Quicky) кто пишет свой шаблонизатор выдумывает новый синтаксис, самый лучший. Может следует выстрадать самый лучший синтаксис вместе прежде чем делать его реализацию?
                +2
                А существует ли «самый лучший синтаксис»? Шаблонизаторы — такая же штука в этом плане, как и языки программирования. Назовите лучший :)
                  +1
                  Мне допустим использование шаблонизаторов типа Twig нравится лишь по одной причине. Ограничивает свободу. Иногда встречаются люди, которые кусок логики запихивают прямо в шаблон, а с Twigом так вот просто этого не сделать.
                    0
                      0
                      Использую Jade в nodeJS. Удобным не показался. Возможно я его не до конца понял, но слишком много приходилось писать js-кода в шаблонах, к напримеру, для того, чтобы задать аттрибуты.
                        0
                        Не знаю как в PHP, но в Python поверх Mako всё удобно.
                        0
                        Как по мне абсолютно бессмысленная вещь.
                      –1
                      В пхп вообще очень многое тырят с других языков. Например Twig это почти точь в точь шаблонизатор из Django
                        +3
                        Слово «тярят» для языков не подходит — это все равно, что сказать, что вы тырите идеи других людей, когда тоже решили пойти в школу, жениться или заняться програмированием: ведь до вас люди это тоже делали.
                          0
                          Хорошо. В пхп очень много копируют из других языков и технологий
                            +1
                            Именно. И это замечательно.
                              +1
                              Согласен. Этим они делают переход с пхп на другой язык-технологию ещё более простым )
                      +7
                      Начиная с php 5.4 директива short_open_tag исчезает, а поддержка шот-тегов теперь включена всегда. Поэтому глупо не использовать их, если в качестве языка для кодирования шаблонов используется сам php.

                      Вы не объясните от чего вы так все «зло» воспринимаете?
                        0
                        Шорттеги — добро, шаблонизация через php-интерпретатор — зло.
                          +5
                          Вы прям как Ленин с броневика… Аргументируйте пожалуйста!
                            +4
                            А для чего Вы используете тогда шорттеги? Во имя «добра», как Вы написали
                            +12
                            Шорттеги — ок, шаблонизатор на нативном PHP — вдвойне ОК
                              +7
                              Я за вариант — «Не использую, потому что не известно будет ли это поддерживаться сервером, а так бы использовал с удовольствием.»
                                +4
                                Не использую, потому что это может вызвать зло несовместимости — но стану использовать, когда PHP 5.4.0 завоюет мир (и умы хостеров), так что конструкция «<?=» сможет употребляться невозбранно.
                                  +3
                                  Хотелось бы конструкцию <?php=$var ?> — решило бы проблему излишнего синтаксиса и совместимости с xml
                                    0
                                    Эту проблему уже однозначно решила конструкция <?= $var ?>, следите за обновлениями PHP.
                                    Однозначную работу тегов <? ?> к сожалению не решили, т.к. беспокоятся об обратной совместимости старого кода(где работают с XML как со строками)
                                    +3
                                    Проявление чувства юмора при составлении опроса сводит на нет адекватность результатов голосования, но подчеркивает наличие чувства юмора у большинства Хабровчан.
                                      0
                                      Использую Twig:
                                      {{foo}}
                                        0
                                        Включаю сокращенную запись (short_open_tag) и радуюсь жизни =)

                                        <?=$variable?>
                                        

                                        <?foreach($arr as $v) {?>
                                          <?print_r($v)?>
                                        <?}?>
                                        


                                        XML:
                                        <?='<?xml version="1.0" encoding="UTF-8"?>'?>
                                        


                                        ЗЛО:
                                        <?php echo $foo ?>
                                        

                                        <? if(true): ?>
                                        <? endif; ?>
                                        
                                          +1
                                          Попробуйте генерить XML удобными средствами. Еще больше будете радоваться.
                                          +2
                                          Обычно те, кто используют «длинный» синтаксис по причине «совместимости с xml», при прямом вопросе, в каком именно случае эта совместимость реально требуется в их проектах, не могут ничего вразумительного ответить.
                                            0
                                            Вроде очевидно же: для совместимости с шаредами за полбакса в месяц, где админ мог влезть куда угодно. Обычно в их коде есть проверки на магические кавычки(<sarcasm>ведь отключать их нельзя, т.к. .htaccess может быть тоже отключен</sarcasm>) и прочую псевдозащитную ересь.
                                              +2
                                              Это актуально для популярных опенсорс-систем типа phpbb и т.д. (впрочем, в phpbb свой шаблонизатор). Там важна совместимость, чтобы все ставилось сразу же из коробки. Таких систем — довольно мало, и трудно поверить, что большая часть программистов, фанатично использующих длинный синтаксис, на самом деле разработчики таких систем. Большинство людей пишет конкретные проекта для конкретных целей, и совместимость с шаред-хостингами (которую к тому де можно легко подправить настройками php_flag в .htaccess на большинстве хостингов) не играет значительной роли.
                                                0
                                                Да не берите в голову, это был сарказм, т.к. начинающие разработчики не ценят свою работу(т.к. в основном не работают за деньги или демпингуют в нижайших ценовых сегментах), поэтому им часто не приходит в голову, что хостинг стоит намного дешевле работы, а в случае чего будет настроен так, как нужно.
                                                Если они так ответят, то можно будет спросить: «А если на хостинге нет PHP?»
                                            +1
                                            Но даже <?=$а?> — огромное зло, потому что на самом деле в 99.9% мест, где так написано, в действительности должно было быть написано <?=htmlspecialchars($а)?>. Увы, данная архитектурная проблема тянется с самой зари php, с ней уже ничего не сделать. В мире существуют миллионы сайтов с xss благодаря ней, и число растет. Шаблонизаторы только и спасение.
                                              0
                                              А почему не экранировать данные шаблона непосредственно перед отправкой в представление?
                                              Даже если у нас написана своя низкоуровневая быстрая f() функция, которая фильтрует что угодно — вызывать ее каждый раз как-то лень и некрасиво, разве нет?
                                                –1
                                                Мне кажется, что PHP не тот язык, в котором стоило бы заниматься подобной оптимизацией. Во всяком случае в большинстве ситуаций. Напоминает экономию спичек на фоне пожара. Гораздо важнее иметь легко-понимаемый лаконичный код и структуру, которую не потребуется через пол года переписывать. Ведь такого рода действия в контроллере противоестественны. 99% проектов на PHP не имеют никаких сложностей с производительностью, более того, чаще всего оная упирается в запросы к БД или кривую логику.

                                                А использование шаблонизаторов позволяет в разы упростить восприятие, написание вёрстки. А в случае, таких шаблонизаторов как XSLT, верстальщик ещё и лишается возможности выстрелить себе в ногу.
                                                  0
                                                  Таки я не говорил ничего против шаблонизаторов. Я предложил людям с развитым головным мозгом обсудить идею экранирования данных непосредственно перед отправкой в шаблон, чтобы не беспокоиться об этом в представлении и не мусорить его.
                                                    0
                                                    людям с развитым головным мозгом
                                                    Воспринимать как оскорбление?
                                                    обсудить идею экранирования данных непосредственно перед отправкой в шаблон
                                                    Ну а я о чём писал? На мой взгляд, это противоречит MVC, т.к. представление должно решать в каком виде необходимы данные, а не контроллер.
                                                      0
                                                      Воспринимать как оскорбление?

                                                      Нет.
                                                      На мой взгляд, это противоречит MVC, т.к. представление должно решать в каком виде необходимы данные, а не контроллер.

                                                      Контроллеру решать какие и в каком виде данные передаются в представление. Чем противоречит? Уже и приведение типа к целочисленному GET параметра в контроллере не сделать? :)
                                                        0
                                                        Уже и приведение типа к целочисленному GET параметра в контроллере не сделать
                                                        Причём тут это? Контроллер принял задачу, определил\обработал входные параметры, замучал модель и отправил итоговые данные в представление. А уж в каком виде их применит представление — дело 10-ое. Разве не так? На мой взгляд, в вашем случаем замусоривается контроллер.
                                                          0
                                                          Кажется мы не об одном и том же говорим. Я имею в виду нормально спроектированную систему. Мы можем переопределить класс View и переопределить метод Assign(или render, в заисимости от того как предаются данные) и автоматически принимать во вьюхе безопасные данные. Там же можно и решить проблему с получением оригинальных данных, когда нужно.

                                                          Не нужно в контроллере эту злосчастную низкоуровневую f() вызывать :D Это и правдо глупо.
                                                            0
                                                            Это и правдо глупо
                                                            Я использую XSLT, и никаких f() не вызываю, однако этим занимается сам шаблонизатор. Не вижу в этом никаких проблем, + всё очень гибко. Если мне в одном месте понадобится экранированные данные, а в другом нет — мне достаточно указать disable-output-escaping. Нет необходимости на уровне контроллера решать — какие данные мне передать в двух видах, какие экранировать, а какие нет. Особенно если учесть, что view-часть можно сильно измениться, без необходимости изменения логики получения итоговых данных.

                                                            Одну и ту же строку я могу использовать и как аттрибут, и как html, и как css, и как что угодно. Нет необходимости для этого лезть в controller и что-либо там менять. На мой взгляд, он, контроллер, об этом вообще ничего знать не должен. Он даже не обязан знать для чего эти данные добыл, что будет на выходе? HTML? XSLT? JSON? закодированное_письмо_для_внеземных_цивилизаций?
                                                          0
                                                          Дополню. Ситуация мне напоминает magic quotes.
                                                    0
                                                    А почему не экранировать данные шаблона непосредственно перед отправкой в представление?

                                                    Экранирование придется вызывать на месте, оно везде разное: для html нужно просто заменять &,<,>, для аттрибутов еще и экранировать кавычки, а при выводе в JS строки еще и удалять переводы строк, делать url_encode при выводе в урл и т.п.
                                                      0
                                                      Экранирование не надо «вызывать». Оно само должно вызываться, и сопротивляться своему выключению (даже однократному). Поэтому я и говорю, что экранирование во вью — дело шаблонизатора, а экранирование sql — дело библиотеки работы с бд. Само понятие «экранирование» — ущербно по своей природе: есть сырые данные, есть результат, а есть «серный ящик», который из первого делает второе по указанной вами инструкции (шаблонизатор, например). Нет в этой картине мира нигде никакого «экранирования».
                                                    0
                                                    Вы слишком плохо думаете о людях, когда говорите 99.9% мест. Я скорее уверен, что не более 1-2%, т.к. в тех местах, где htmlspecialchars нет, он и не предполагался автором, а предполагался прямой вывод HTML без экранирования, а 1-2% — это как раз человеческий фактор и ошибки новичков.
                                                      0
                                                      Я скорее уверен, что не более 1-2%

                                                      Думаю, вы ошибаетесь. Там около 67,2%
                                                        +1
                                                        Прямой вывод без экранирования реально необходим в подавляющем меньшинстве случаев. Настаиваю на этом как активных пользователь ShortXSLT — disable-output-escaping приходится применять исчезающе малое число раз.
                                                        –4
                                                        Что бы не делать <?=htmlspecialchars($a)?> нужно фильтровать и экранировать символы перед записью в db.
                                                          +4
                                                          <sarcasm>Конечно, а еще заменять все английские буквы «a» на русские и вырезать все знаки пунктуации.

                                                          Тогда можно и не экранировать перед записью в базу.
                                                          Да и при выводе можно не экранировать.

                                                          Ну и, конечно, любые данные обрезать до 255 символов перед записью тоже нужно: вдруг где переполнится что-то?</sarcasm>
                                                            +2
                                                            Что будете делать, когда нужны будут оригинальные данные, например для вывода в отличные от HTML форматы, поиска, изменения формата данных и т.д.?
                                                              –2
                                                              Удалять через str_replace лишние слэши перед выдачей *HEADWALL*
                                                                0
                                                                Какие нафиг слеши при HTML-экранировании?
                                                                  0
                                                                  Там выше писали про Magic Quotes, и я вспомнил случай на работе, когда пришлось дописывать пару фич к старинному приложению, в котором пользовательский ввод экранировался через Magic Quotes, что приводило при многократном сохранении данных к длинным рядам обратных слэшей в базе данных, которые я потом вырезал при экспорте :)
                                                          +2
                                                          Даже и не знаю. За все время работы ни разу не встречал хостинга, где невозможно было бы использовать «короткие теги» — как минимум, эта опция была доступна в htaccess'е.

                                                          В случае, если нужно включить в документ XML тоже есть решение. Это, конечно, костыль, но не слишком некрасивый:
                                                          <<??>?xml version="1.0" encoding="UTF-8"?<??>>
                                                          

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

                                                          Самое читаемое