Выйти из HTML на PHP или использовать эхо? Что лучше?

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

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

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

Пример 1

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

ИЛИ

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

Это все, о чем вы найдете наиболее читаемым. Конечно, это будет меняться в зависимости от ситуации. Если вы делали целую страницу, и там были большие разделы, в которых не было 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 ); ?> 

Какой из них проще всего читать.

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

Приведем руководство :

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


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

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

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

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

Я не знаю о производительности этого, но в 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; ?> 

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

Рут

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

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

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

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

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

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

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

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

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

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

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

 <?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 имеет несколько конкретных преимуществ:

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

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

Это во многом потому, что я предпочитаю оптимизировать ремонтопригодность. Не только потому, что быстрее видеть, что происходит, когда html имеет соответствующую подсветку синтаксиса, но и потому, что он также допускает ошибки, вызванные ошибочным чтением кода.

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

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

 <?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 необходимо соблюдать ту же осторожность, что и строки.

Последнее гораздо читаемо. Это также более легко редактируется (например, вам не нужно скрывать кавычки в HTML). И он сохраняет пробелы без каких-либо проблем, что может быть предпочтительным, особенно для целей отладки.

Я почти хочу, чтобы PHP позволял print() и echo() автоматически преобразовывать символы HTML, чтобы люди перестали использовать их для генерации HTML.

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

Как говорили другие, если вы выходите в html, используйте <?php echo $whatever; ?> <?php echo $whatever; ?>

Если вам нужно вывести тонну информации в буферизацию вывода.