Что более эффективно и / или что лучше, чтобы эхо HTML или много открытых и закрытых php тегов?
Очевидно, что для больших областей HTML разумно открывать и закрывать теги php . Как насчет того, чтобы иметь дело с чем-то вроде генерации XML? Должны ли вы открывать и закрывать теги php одним эхом для каждой части данных или использовать одно эхо с тегами XML, включенными в цитаты?
С точки зрения обслуживания, нужно иметь HTML / XML как отдельный от кода, насколько это возможно, IMO, так что незначительные изменения могут быть сделаны легко даже нетехническим человеком.
Чем больше однородный блок разметки, тем чище работа.
Один из способов добиться этого – подготовить как можно больше к переменным и использовать синтаксис heredoc :
// Preparation $var1 = get_value("yxyz"); $var2 = get_url ("abc"); $var3 = ($count = 0 ? "Count is zero" : "Count is not zero"); $var4 = htmlentities(get_value("def")); // Output echo <<<EOT <fieldset title="$var4"> <ul class="$var1"> <li> $var2 </li> </ul> </fieldset> EOT;
Конечно, вы захотите использовать более разумные имена переменных.
Редактирование: ссылка, отмеченная @stesch в комментариях, дает некоторые хорошие аргументы в пользу использования сериализатора при создании XML и расширения, даже HTML, вместо того, чтобы распечатывать его, как показано выше. Я не думаю, что сериализатор необходим в каждой ситуации, особенно с точки зрения обслуживания, где шаблоны гораздо проще редактировать, но ссылка хорошо стоит прочитать. HOWTO избегает быть названным Bozo при производстве XML
Еще одно большое преимущество разделения между логикой и контентом заключается в том, что если переход к движку шаблонов или введение кэширования становится необходимым в один прекрасный день, практически безболезно реализовать, поскольку логика и код уже разделены.
PHP решает эту проблему тем, что известно как heredocs . Проверьте это, пожалуйста.
Пример:
echo <<<EOD <td class="itemname">{$k}s</td> <td class="price">{$v}/kg</td> EOD;
Примечание. Идентификатор heredoc (EOD в этом примере) не должен содержать пробелов или отступов.
Какой смысл для вас. Разница в производительности незначительна, даже если большое эхо быстрее.
Но отголосок большой строки трудно читать и больше <?php echo $this->that; ?> <?php echo $this->that; ?> расскажи историю 🙂
echo отправляет свой аргумент дальше по цепочке обработки запроса, и, в конце концов, эта строка отправляется клиенту через скачок сетевого сокета. В зависимости от того, как echo работает в сочетании с базовыми слоями программного обеспечения (например, веб-сервер), иногда ваш сценарий может работать быстрее, чем он может передавать данные клиенту. Без буферизации вывода, то есть. С буферизацией вывода вы торгуете памятью, чтобы получить скорость – вы echo сигналы быстрее, потому что они накапливаются в буфере памяти. Но только если не происходит никакой неявной буферизации. Вам нужно будет проверить исходный код Apache, чтобы узнать, как он обрабатывает данные stdout PHPs.
Тем не менее, все, что ниже, справедливо только для сценариев с включенной буферизацией, поскольку без него больше данных вы пытаетесь нажать одновременно, чем дольше вы должны ждать (клиент должен получать и подтверждать его, используя TCP!).
Эффективнее посылать большую строку за один раз, чем вывод N echo конкатенации. По аналогичной логике, для интерпретатора более эффективно вводить блок кода PHP (инструкцию по обработке PHP в разметке SGML / XML) один раз, чем вводить и выходить из него много раз.
Что касается меня, я собираю свою разметку не с echo , а с использованием XML DOM API. Это также соответствует статье, приведенной выше. (Я перепечатываю ссылку: http://hsivonen.iki.fi/producing-xml/ ) Это также отвечает на вопрос, следует ли использовать один или несколько тегов PHP. Используйте один тег, который является вашим полным скриптом, пусть он соберет полученную разметку и отправит ее клиенту.
Лично я предпочитаю то, что выглядит лучше, так как читаемость кода очень важна, особенно в командной среде. Что касается лучшей практики, я боюсь, что я не уверен, но обычно лучше всего оптимизировать последнее значение, чтобы сначала написать его для читаемости, а затем, если вы столкнулись с проблемами скорости, выполните некоторые рефакторинг.
Любые проблемы, которые у вас есть с эффективностью, скорее всего, будут в другом месте вашего кода, если вы не делаете миллионы эхо-сигналов.
Еще одна вещь, которую следует учитывать, это использование MVC для разделения ваших «взглядов» от всей вашей бизнес-логики, которая является очень чистым способом кодирования. Использование шаблона, такого как smarty, может сделать этот шаг еще одним шагом вперед к эпической победе.
Что бы вы ни делали, не печатайте XML!
См. HOWTO Избегайте быть названным Bozo при создании XML
Я поставил себе тот же вопрос давным-давно и придумал тот же ответ, это не значительная разница. Я вычитаю этот ответ с помощью этого теста:
<? header('content-type:text/plain'); for ($i=0; $i<10; $i++) { $r = benchmark_functions( array('output_embeed','output_single_quote','output_double_quote'), 10000); var_dump($r); } function output_embeed($i) { ?>test <?php echo $i; ?> :)<? } function output_single_quote($i) { echo 'test '.$i.' :)'; } function output_double_quote($i) { echo "test $i :)"; } function benchmark_functions($functions, $amount=1000) { if (!is_array($functions)||!$functions) return(false); $result = array(); foreach ($functions as $function) if (!function_exists($function)) return(false); ob_start(); foreach ($functions as $idx=>$function) { $start = microtime(true); for ($i=0;$i<$amount;$i++) { $function($idx); } $time = microtime(true) - $start; $result[$idx.'_'.$function] = $time; } ob_end_clean(); return($result); } ?>