do_shortcode - PHP-¿Hacer eco o no hacer eco?

shortcodes in html wordpress

Question

¿Qué es más eficiente y / o qué es una mejor práctica, hacer eco del HTML o tener muchas etiquetas de php abiertas y php ?

Obviamente, para grandes áreas de HTML es sensato abrir y cerrar las etiquetas php . ¿Qué pasa cuando se trata de algo como generar XML? ¿Debería abrir y cerrar las etiquetas php con un solo eco para cada pieza de datos o usar un solo eco con las etiquetas XML incluidas en las citas?

Answer 1

Desde una perspectiva de mantenimiento, uno debe tener el HTML / XML tan separado del código como la IMO posible, de modo que una persona no técnica pueda realizar cambios menores fácilmente.

Cuanto más bloque homogéneo es el marcado, más limpio es el trabajo.

Una forma de lograr esto es preparando la mayor cantidad posible de variables y utilizando la sintaxis 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;

Usted querrá usar nombres de variables más sensibles, por supuesto.

Edición: El enlace señalado por @stesch en los comentarios proporciona algunos buenos argumentos para utilizar un serializador al producir XML, y por extensión, incluso HTML, en lugar de imprimirlo como se muestra arriba. No creo que sea necesario un serializador en todas las situaciones, especialmente desde un punto de vista de mantenimiento donde las plantillas son mucho más fáciles de editar, pero el enlace bien vale la pena leerlo. Cómo evitar ser llamado Bozo al producir XML

Otra gran ventaja de la separación entre la lógica y el contenido es que si la transición a un motor de plantillas, o la introducción del almacenamiento en caché se hace necesaria algún día, es casi fácil de implementar porque la lógica y el código ya están separados.

Answer 2

Hagas lo que hagas, no imprimas XML!

Vea hsivonen.iki.fi/producing-xml

Answer 3

Lo que tenga sentido para ti. La diferencia de rendimiento es marginal, incluso si un eco grande es más rápido.

Pero un eco de una cadena grande es difícil de leer y más <?php echo $this->that; ?> <?php echo $this->that; ?> contar una historia :)

Answer 4

Me hice la misma pregunta hace mucho tiempo y se me ocurrió la misma respuesta, no es una diferencia considerable. Deduzco esta respuesta con esta prueba:

<?
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);
}
?>

Answer 5

PHP resuelve este problema por lo que se conoce como heredocs . Compruébalo por favor.

Ejemplo:

 echo <<<EOD
<td class="itemname">{$k}s</td>
<td class="price">{$v}/kg</td>
EOD;

Nota: El identificador heredoc (EOD en este ejemplo) no debe tener ningún espacio o sangría.

Answer 6

Personalmente, tiendo a preferir lo que parece mejor, ya que la legibilidad del código es muy importante, especialmente en un entorno de equipo. En cuanto a las mejores prácticas, me temo que no estoy seguro; sin embargo, en general es una buena práctica optimizar el último significado de que primero debe escribirlo para facilitar la lectura y luego, si tiene problemas de velocidad, haga una refactorización.

Es probable que cualquier problema que tenga con eficiencia esté en otra parte de su código, a menos que esté haciendo millones de ecos.

Otra cosa a considerar es el uso de un MVC para separar sus "vistas" de toda la lógica de su negocio, que es una forma muy clara de codificar. El uso de un marco de plantilla como smarty puede llevar este paso un paso más hacia la victoria épica.

Answer 7

echo envía su argumento más abajo en la cadena de procesamiento de la solicitud y, finalmente, esta cadena se envía al cliente a través de un zócalo de red. Dependiendo de cómo funcione el echo junto con las capas de software subyacentes (por ejemplo, el servidor web), algunas veces su script puede ejecutarse más rápido de lo que puede enviar datos al cliente. Sin búfer de salida, eso es. Con el búfer de salida, intercambia memoria para ganar velocidad; los echo son más rápidos porque se acumulan en un búfer de memoria. Pero solo si no hay un buffering implícito en marcha. Uno tendrá que inspeccionar el código fuente de Apache para ver cómo trata los datos stdout PHP.

Dicho esto, todo lo que se indica a continuación es válido solo para los scripts de búfer de salida, ya que sin él, cuanta más información intente enviar, más tiempo tendrá que esperar (el cliente tiene que recibirlo y reconocerlo, ¡a través de TCP!).

Es más eficiente enviar una cadena grande a la vez que hacer la concatenación de N echo . Por lógica similar, es más eficiente que el intérprete ingrese el bloque de código PHP (instrucción de procesamiento de PHP en el marcado SGML / XML) una vez que ingrese y salga muchas veces.

En cuanto a mí, armo mi marca no con echo , sino con XML DOM API. Esto también está de acuerdo con el artículo vinculado anteriormente. (Reimprimo el enlace: hsivonen.iki.fi/producing-xml ) Esto también responde a la pregunta de si usar una o varias etiquetas PHP. Use una etiqueta que sea su secuencia de comandos completa, deje que reúna el marcado resultante y envíelo al cliente.