Выход из HTML в PHP или использование Echo? Что лучше? - PullRequest
41 голосов
/ 03 февраля 2009

С точки зрения производительности, что было бы лучше. Использование PHP для отображения всего HTML-вывода, чтобы я мог перелистывать его с различными частями рабочего кода и переменных или экранировать HTML-код для php периодически по всем документам.

Я знаю, что могут быть некоторые проблемы с читабельностью, но меня это не беспокоит.

Спасибо всем!

Пример 1

echo '<html>',
     '<body>',
     'The content of the ',$container,' element is displayed in your ', $other_container,
     '</body>',
     '</html>';

OR

<html>
<body>
The content of the <?php echo $container; ?> element is displayed in your <?php echo $other_container; ?>
</body>
</html>

Ответы [ 13 ]

33 голосов
/ 03 февраля 2009

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

Например:

<table>
    <tr>
        <td colspan="<?php echo $numCols; ?>">
            <?php echo $a; ?>, <?php echo $b; ?>, and <?php echo $c?>
        </td>
    </tr>
</table>

против

<?php
echo "<table>"
    . "<tr>"
    .    "<td colspan=\"" . $numCols . "\">"
    .        $a . ", " . $b . " and " . $c
    .    "</td>"
    . "</tr>"
    . "</table>"
; ?>

Или

<?php
echo "<table>
         <tr>
            <td colspan='{$numCols}'>
               {$a}, {$b}, and {$c}
            </td>
         </tr>
      </table>";
?>

Также не забудьте о printf

<?php
printf("<table>"
    . "<tr>"
    .    "<td colspan=\"%d\">%s, %s and %s</td>"
    . "</tr>"
    . "</table>"
    , $numCols
    , $a
    , $b
    , $c
);
?>
31 голосов
/ 03 февраля 2009

Что читать легче всего.

Разница в производительности довольно незначительна по сравнению с почти любой другой проблемой, с которой вы столкнетесь. Определенно удобочитаемость - первый вопрос здесь.

22 голосов
/ 03 февраля 2009

Давайте процитируем руководство :

Пример, приведенный здесь, надуман, конечно, но для вывода большой блоки текста, выпадающие из PHP режим разбора вообще больше эффективнее, чем отправка всего текста через echo () или print ().


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

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

8 голосов
/ 03 февраля 2009

Я не знаю о производительности этого, но в PHP вы также можете использовать то, что, как я считаю, называется «Heredoc», что, я думаю, помогает с удобочитаемостью при такого рода выводе.

Пример Никфа:

<table>
    <tr>
        <td colspan="<?php echo $numCols; ?>">
            <?php echo $a; ?>, <?php echo $b; ?>, and <?php echo $c?>
        </td>
    </tr>
</table>

становится:

<?php
echo <<<EOT
<table>
    <tr>
        <td colspan="$numCols">
            $a , $b, and  $c
        </td>
    </tr>
</table>

EOT;

?>

Я считаю, что в конечном итоге читабельность - это субъективная вещь, поэтому ваш пробег может варьироваться!

Ruth

8 голосов
/ 03 февраля 2009

Это не имеет отношения к общей скорости вашего приложения, с которым вы идете.

При этом я знаю, что вы сказали, что вам все равно, но, пожалуйста, используйте 2-й, так как его примерно в миллион раз легче читать. И читаемость огромная .

5 голосов
/ 03 февраля 2009

Это относится к сфере микрооптимизации. Большую часть вашего времени занимает инициализация PHP-движка, запускающего работу.

Так что, если у вас нет порядка десятков тысяч строк (или даже больше), вы не должны беспокоиться об этом.

Чтобы добавить, я провел небольшой тест из миллиона строк, где я использовал php для их печати и где я использовал php для вызова программы c, которая сделала то же самое, и разница была крошечной.

Немного больше информации.

То, что происходит во втором примере, заключается в том, что вы «включаете / выключаете» PHP, это не совсем то, что происходит, но для этого примера он подходит.

То, о чем вы должны больше беспокоиться, будет ли в этом коде много логики? Собираюсь ли я разделить эту строку на еще больше строк или даже разместить ее в разных местах? Это вид приложения MVC?

Для 1 и 2 это может быть бросок между любым методом. Но для 3 я бы пошел по методу 2 по этим причинам.

Вид в веб-приложении MVC в основном html / css. Поэтому я хочу, чтобы это было правильно отформатировано, и я хочу видеть в моем редакторе HTML-раскраску Так что это плюс.

3 голосов
/ 06 февраля 2009

Это должно рассматриваться скорее как проблема читабельности и обслуживания, чем проблема производительности.

Таким образом, у варианта 2 есть пара конкретных преимуществ:

  1. Кодовая раскраска. С опцией 1 все окрашено как выражение эха, что затрудняет чтение HTML.
  2. Intellisense - со многими IDE HTML в эхо-выражении PHP не будет включать intellisense, поэтому вы будете вводить весь этот HTML вручную.
3 голосов
/ 06 февраля 2009

Код, как если бы следующий программист, принявший проект, был серийным убийцей. Другими словами, используйте второй вариант, который вы упомянули.

3 голосов
/ 03 февраля 2009

С точки зрения производительности ... это не важно. Читаемость кода важна, ничтожная доля разницы в производительности ничего не изменит.

Необработанную HTML-версию обычно легче всего читать (и, вероятно, она также имеет лучшую производительность, хотя она и стоит: ничего). Это неудивительно: PHP является языком шаблонов HTML, вся точка чередует HTML на уровне синтаксиса языка.

Посмотрите на код Никафа, чтобы увидеть, как сохранить его читабельным. Отступ важен! Установите уровень отступа внутри каждой структуры управления PHP, чтобы вы могли отслеживать их. eg.:

<?php if ($error) { ?>
    <p> Oh no, error! </p>
<?php } ?>

Наконец, при выводе контента, такого как $ container в вашем примере, вы всегда должны использовать htmlspecialchars (), иначе у вас будет приложение, полное дыр в безопасности HTML-инъекций, как и любой другой новичок в PHP (и даже многие профессиональные разработчики, к сожалению). Это имеет значение, какой бы метод вы не использовали для вывода контента.

Поскольку htmlspecialchars - довольно длинное имя функции, вы можете попробовать определить собственную функцию быстрого доступа:

<?php
    function h($s) {
        echo(htmlspecialchars($s, ENT_QUOTES));
    }
?>

<ul>
    <?php foreach ($things as $thing) { ?>
        <li> <?php h($thing['name']) ?> </li>
    <?php } ?>
</ul>
2 голосов
/ 14 апреля 2014

Я предпочитаю использовать функцию php heredoc , поэтому мне не нужно экранировать символы, например:

<?php

$title = "heredoc is cool!!!";
$mySite = "http://www.php.net";

echo <<<LOL
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
<head>

  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <meta name="viewport" content="width=device-width, initial-scale=1.0"> 

  <title> $title </title>

 <link rel="shortcut icon" href="$mySite/favicon.ico">
 <link rel="search" type="application/opensearchdescription+xml" href="$mySite/phpnetimprovedsearch.src" title="Add PHP.net search">
 <link rel="alternate" type="application/atom+xml" href="$mySite/releases/feed.php" title="PHP Release feed">
 <link rel="alternate" type="application/atom+xml" href="$mySite/feed.atom" title="PHP: Hypertext Preprocessor">

 <link rel="canonical" href="$mySite/manual/en/language.types.string.php">
 <link rel="shorturl" href="$mySite/types.string">

 <link rel="contents" href="$mySite/manual/en/index.php">
 <link rel="index" href="$mySite/manual/en/language.types.php">
 <link rel="prev" href="$mySite/manual/en/language.types.float.php">
 <link rel="next" href="$mySite/manual/en/language.types.array.php">
LOL;
?>

Примечание:

Текст Heredoc ведет себя как строка в двойных кавычках, без двойные кавычки. Это означает, что кавычки в heredoc не должны быть сбежал, но коды перехода, перечисленные выше, все еще можно использовать. Переменные расширяются, но нужно проявлять такую ​​же осторожность, когда Выражение сложных переменных внутри heredoc как со строками.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...