2009-02-03 15 views
40

En términos de rendimiento, ¿qué sería mejor? Usar PHP para hacer eco de todo el resultado HTML, así puedo darle más vida a los diversos bits del código de trabajo y las variables, o escapar de HTML a php periódicamente en todos los documentos.¿Escape HTML a PHP o usa eco? ¿Cual es mejor?

Sé que puede haber algunos problemas de legibilidad, pero no me preocupa eso.

¡Gracias a todos!

Ejemplo 1

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

O

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

Se corrigió el código para usted. En el futuro, sangría el código de 4 espacios para que stackoverflow lo reconozca como código :) –

+0

segundo ejemplo es el camino a seguir. cualquier otra cosa es un olor a código. ninguna persona seria estaría en desacuerdo –

Respuesta

33

Es todo sobre lo que le parezca más legible. Por supuesto, esto variará con cada situación. Si estuvieras haciendo una página completa, y hubiera secciones grandes que no tuvieran PHP, rompería PHP y solo escribiría el HTML simple, mientras que si hubiera una sección que tuviera muchas variables PHP , Lo haría todo en PHP.

Por ejemplo:

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

frente:

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

O

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

También no se olvide de printf

<?php 
printf("<table>" 
    . "<tr>" 
    . "<td colspan=\"%d\">%s, %s and %s</td>" 
    . "</tr>" 
    . "</table>" 
    , $numCols 
    , $a 
    , $b 
    , $c 
); 
?> 
+1

estaba leyendo los primeros, y no completamente de acuerdo. Estoy mucho más de acuerdo con tu sugerencia! Quédate con lo que sea predominante – benlumley

+4

Has perdido el heredoc;) – MarcinWolny

5

Se cae en el campo de la micro optimizaciones. La mayor parte de su tiempo se debe a la inicialización del motor PHP que inicia el trabajo.

De modo que a menos que tenga un pedido de decenas de miles de líneas (o incluso más), no debería preocuparse por ello.

Para agregar, hice una pequeña prueba de un millón de líneas donde utilicé php para imprimirlas y donde utilicé php para llamar a un programa c que hacía lo mismo y la diferencia era minúscula.

Un poco más de información.

Lo que está sucediendo en el segundo ejemplo es que estás "encendiendo/apagando" PHP, no es exactamente lo que está sucediendo, pero para este ejemplo cabe.

Lo que debería preocuparle más es que el código tenga mucha lógica al respecto? ¿Voy a dividir esa cuerda en otras cuerdas o incluso colocarla en diferentes lugares? ¿Es esta la Vista de una aplicación MVC?

Para 1 y 2 podría ser un lanzamiento entre cualquiera de los métodos. Pero para 3 me gustaría ir con el método 2 por estas razones.

Una vista en una aplicación web MVC es principalmente html/css. Así que quiero ver que esté formateado correctamente y quiero ver en mi editor el color html. Entonces eso es un plus.

+0

Entiendo su punto, pero aún me gustaría saber la diferencia. Gracias. –

8

Es bastante irrelevante para la velocidad general de la aplicación con la que va.

Habiendo dicho eso, sé que dijiste que no te importa, pero usa el segundo porque es un millón de veces más fácil de leer. Y la legibilidad es enorme.

30

Cualquiera que sea más fácil de leer.

La diferencia de rendimiento es bastante insignificante en comparación con casi cualquier otro problema que pueda encontrar. Definitivamente la legibilidad es sin duda el primer problema aquí.

2

Para bits pequeños, simplemente lo guardo todo en cadenas PHP, como cuando recorro una matriz para generar una lista. Pero para montones más grandes de marcado lo mantengo fuera del PHP y simplemente paso a PHP cuando es necesario.

Esto se debe en gran parte a que prefiero optimizar para la mantenibilidad. No solo porque es más rápido ver qué sucede cuando el html tiene aplicado el resaltado de sintaxis adecuado, sino también porque es menos probable que se cometan errores resultantes de una lectura defectuosa del código.

Realmente no hay una mejor manera. Solo trato de ser coherente con lo que se describe arriba, y mantener los ojos abiertos para situaciones en las que quizás la otra forma sería una mejor manera de manejarlo.

22

Citemos the manual:

El ejemplo dado aquí es artificial, por supuesto, pero para dar salida a grandes bloques de texto, el abandono de PHP modo de análisis es generalmente más eficiente que enviar todo del texto a echo() o print().


Pero por favor, escuchen a los demás y evitar este tipo de optimización micro y elegir la que es más legible.

¿Puedo proponer una tercera solución? ¿Has oído hablar de los motores de plantillas? Te ayudan a crear una separación clara entre el código y la presentación, lo que generalmente conduce a un código más limpio que es más fácil de mantener. Un motor de plantilla popular es, p. smarty, pero hay cientos con diferentes puntos fuertes.

+0

Me sorprende que cualquiera encuentre el eco fuera más fácil de leer ya que los IDEs que he encontrado ignoran el formato html en html echoed. – Ishmael

+0

Plus 1 para citar el manual de rendimiento. – lowtechsun

1

Este último es mucho más legible. También es más fácil de editar (no tiene que escapar las comillas en HTML, por ejemplo). Y preserva el espacio en blanco sin ningún tipo de molestia, que puede ser preferible, especialmente para fines de depuración.

Casi deseo que PHP habilite print() y echo() para convertir automáticamente caracteres HTML para que las personas dejen de usarlos para generar HTML.

3

En términos de rendimiento ... no es importante. La legibilidad del código es el rey, una pequeña fracción de un por ciento de la diferencia de rendimiento no va a cambiar nada.

La versión HTML sin formato suele ser la más fácil de leer (y probablemente también tenga el mejor rendimiento para lo que vale, pero lo que vale es: nada). Esto no sorprende: PHP es un lenguaje de plantillas HTML, el punto está entrelazando HTML en un nivel de sintaxis de lenguaje.

Mire el código de nickf para ver cómo mantenerlo legible. La sangría es importante! Ponga un nivel de sangrado dentro de cada estructura de control de PHP también, para que pueda hacer un seguimiento de ellos. p.ej.:

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

Por último, cuando la salida de contenido, tales como $ contenedor en su ejemplo, debe siempre htmlspecialchars() que, o tendrá que tener una aplicación completa de los agujeros de seguridad HTML-inyección, como cualquier otro novato PHP (e incluso muchos desarrolladores profesionales, por desgracia). Esto importa cualquiera que sea el método que use para generar contenido.

Debido a htmlspecialchars es todo un nombre de función fastidiosamente larga, podría intentar definir su propia función de acceso directo:

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

<ul> 
    <?php foreach ($things as $thing) { ?> 
     <li> <?php h($thing['name']) ?> </li> 
    <?php } ?> 
</ul> 
8

No sé sobre el rendimiento de esta, pero dentro de PHP también se puede usar lo que Creo que se llama "Heredoc", que creo que ayuda con la legibilidad en este tipo de resultados. ejemplo

de nickf:

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

se convierte en:

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

EOT; 

?> 

yo creo que en última instancia, la legibilidad es una cosa subjetiva, por lo que su experiencia puede variar!

Ruth

+1

Pensé que heredoc era perfecto, pero puede haber una advertencia para tener en cuenta dependiendo del caso de uso. Si hay algún espacio en blanco antes del último 'EOT;' todo se rompe. Hay una serie de razones por las cuales esto puede suceder involuntariamente. Sólo sé consciente de ello. – user1167442

1

usted debería considerar seriamente Nunca colocar PHP dentro de HTML. Está mezclando la lógica con la vista, lo que hace que un proyecto sea complicado.

Como otros han dicho, si la salida en HTML, utilice <?php echo $whatever; ?>

Si tiene que emitir una tonelada de información mirar en el búfer de salida.

3

Código como si el siguiente programador que se hiciera cargo del proyecto fuera un asesino en serie. En otras palabras, use la segunda opción que mencionó.

+1

Una buena regla a seguir. – edude05

3

Esto debería considerarse más un problema de legibilidad y mantenimiento que un problema de rendimiento.

Por lo tanto, la opción 2 tiene un par de ventajas concretas:

  1. colores de código. Con la opción 1, todo se colorea como una declaración de eco que dificulta la lectura de HTML.
  2. Intellisense: con muchos IDE, HTML dentro de una declaración de eco de PHP no interactuará con intellisense, por lo que escribirás todo ese HTML a mano.
2

Yo prefiero usar la función php heredoc, de esta manera no necesito escapar cualquier carácter, por ejemplo:

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

Nota:

texto Heredoc comporta como un doble -cadena citada, sin las comillas dobles . Esto significa que las comillas en un heredoc no tienen que ser escapadas, pero los códigos de escape listados anteriormente todavía se pueden usar. Las variables se expanden, pero se debe tener el mismo cuidado cuando se expresan variables complejas dentro de un heredoc como con strings.

Cuestiones relacionadas