Respuesta: Escribe vs <% =% >

Question

Teniendo en cuenta que esto es para asp clásico

Lo que es mejor, todo el HTML contenido en Response.Write Sentencias o insertando variables en HTML a través de <% =% > ;.
Por ejemplo,

Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<td class=""someClass"">" & someVariable & "</td>" & vbCrLf
Response.Write "</tr>" & vbCrLf
Response.Write "</table>" & vbCrLf

VS

<table>
  <tr>
     <td class="someClass"><%= someVariable %></td>
  </tr>
</table>

Principalmente pregunto desde el punto de vista del rendimiento, ¿cuál tendrá el menor impacto en el servidor cuando haya múltiples variables para insertar?

Si no hay diferencias técnicas, ¿cuáles son los argumentos para uno sobre el otro?

Answer 1

Primero, el factor más importante que debe tener en cuenta es la facilidad de mantenimiento. Puede comprar una granja de servidores con el dinero y el tiempo que de otro modo perdería si tuviera que descifrar un sitio web desordenado para mantenerlo.

En cualquier caso, no importa. Al final del día, ¡todo lo que hace ASP es simplemente ejecutar un script! El analizador ASP toma la página y transforma <% = expression% > en llamadas de script directas, y cada bloque contiguo de HTML se convierte en una llamada gigante a Response.Write . La secuencia de comandos resultante se almacena en caché y se reutiliza a menos que la página cambie en el disco, lo que hace que la secuencia de comandos en caché se vuelva a calcular.

Ahora, el uso excesivo de <% =% > conduce a la versión moderna de " código de espagueti " ;: la temida " etiqueta de sopa " ;. No podrás hacer cara o cruz de la lógica. Por otro lado, el uso excesivo de Response.Write significa que nunca podrá ver la página hasta que se muestre. Use <% =% > cuando sea apropiado para obtener lo mejor de ambos mundos.

Mi primera regla es prestar atención a la proporción de " texto variable " a "texto estático".

Si solo tiene unos pocos lugares con texto variable para reemplazar, la sintaxis <% =% > es muy compacta y fácil de leer. Sin embargo, a medida que el <% =% > comienza a acumularse, oscurecen más y más el HTML y, al mismo tiempo, el HTML oculta cada vez más su lógica. Como regla general, una vez que comience a tomar bucles, debe detenerse y cambiar a Response.Write`.

No hay muchas otras reglas duras y rápidas. Necesita decidir para su página particular (o sección de la página) cuál es más importante, o naturalmente más difícil de entender o más fácil de romper: ¿su lógica o su HTML? Suele ser uno u otro (he visto cientos de casos de ambos)

Si su lógica es más crítica, debería pesar más hacia Response.Write ; hará que la lógica se destaque. Si tu HTML es más crítico, favorece <% =% > , lo que hará que la estructura de la página sea más visible.

A veces he tenido que escribir ambas versiones y compararlas una al lado de la otra para decidir cuál es más legible; es un último recurso, pero hágalo mientras el código esté fresco en su mente y se alegrará tres meses después cuando tenga que hacer cambios.

Answer 2

Desde un punto de vista de preferencia personal, prefiero el <% =% > método, ya que creo que proporciona una mejor separación del contenido variable del contenido estático.

Answer 3

Dejando a un lado los problemas de lectura / mantenimiento del código que otros han abordado, su pregunta fue específicamente sobre el rendimiento cuando tiene múltiples variables para insertar, por lo que supongo que va a repetir algo como su fragmento de código varias veces. En ese caso, debe obtener el mejor rendimiento utilizando una sola respuesta. Escriba sin concatenar todas las nuevas líneas:

Response.Write "<table><tr><td class=""someClass"">" & someVar & "</td></tr></table>"

El navegador no necesita las nuevas líneas o las pestañas o cualquier otro formato bonito para analizar el HTML. Si buscas rendimiento, puedes eliminar todo esto. También hará que su salida HTML sea más pequeña, lo que le dará tiempos de carga de página más rápidos.

En el caso de una sola variable, realmente no hace mucha diferencia. Pero para múltiples variables, desea minimizar el cambio de contexto entre HTML y ASP: recibirá un golpe por cada salto de una a la otra.

Para ayudar con la legibilidad al construir una declaración más larga, puede usar el carácter de continuación de línea VBScript y las pestañas en su código fuente (pero no la salida) para representar la estructura sin afectar su rendimiento:

Response.Write "<table>" _
        & "<tr>" _
            & "<td class=""someClass"">" & someVar & "</td>" _
        & "</tr>" _
        & "<tr>" _
            & "<td class=""anotherClass"">" & anotherVar & "</td>" _
        & "</tr>" _
        & "<tr>" _
            & "<td class=""etc"">" & andSoOn & "</td>" _
        & "</tr>" _
    & "</table>"

No es tan legible como la versión HTML, pero si coloca muchas variables en la salida (es decir, una gran cantidad de cambio de contexto entre HTML y ASP), verá un mejor rendimiento.

Si las ganancias de rendimiento valen la pena o si sería mejor escalar su hardware es una pregunta separada, y, por supuesto, no siempre es una opción.

Actualización: consulte los consejos 14 y 15 en este artículo de MSDN de Len Cardinal para obtener información sobre cómo mejorar el rendimiento con Response.Buffer y evitar el cambio de contexto: http://msdn.microsoft.com/en-us/library/ms972335.aspx#asptips_topic15 .

Answer 4

Muchas de las respuestas aquí indican que los dos enfoques producen el mismo resultado y que la opción es codificar el estilo y el rendimiento. Parece que se cree que el contenido estático está fuera de <%% > se convierte en una sola respuesta. Escribir.

Sin embargo, sería más exacto decir el código fuera de <%% > se envía con BinaryWrite.

Response.Write toma una cadena Unicode y la codifica en el Response.CodePage actual antes de colocarla en el búfer. No existe tal codificación para el contenido estático en un archivo ASP. Los caracteres fuera de <%% > se vuelcan literalmente byte por byte en el búfer.

Por lo tanto, cuando el Response.CodePage es diferente del CodePage que se utilizó para guardar el archivo ASP, los resultados de los dos enfoques pueden diferir.

Por ejemplo, supongamos que tengo este contenido guardado en una página de códigos estándar 1252: -

<%
     Response.CodePage = 65001
     Response.CharSet = "UTF-8"
 %>
<p> The British £</p>
<%Response.Write("<p> The British £</p>")%>

El primer párrafo está confuso, ya que & # 163; no se enviará utilizando la codificación UTF-8, la segunda está bien porque la cadena Unicode suministrada está codificada en UTF-8.

Por lo tanto, desde un punto de vista de rendimiento, es preferible usar contenido estático, ya que no necesita codificación, pero se necesita cuidado si la página de códigos guardada difiere de la página de códigos de salida. Por esta razón, prefiero guardar como UTF-8, incluir <% @ codepage = 65001 y establecer Response.Charset = " UTF-8 " ;.

Answer 5

Prefiero el <% =% > método en la mayoría de las situaciones por varias razones.

1. El HTML está expuesto al IDE por lo que que puede ser procesado dándote información sobre herramientas, cierre de etiquetas, etc.
2. Mantener la sangría en el HTML de salida es más fácil, que puede ser muy útil para reelaborar el diseño.
3. Nuevas líneas sin agregar vbCrLf en todo y nuevamente para revisar la fuente de salida.

Answer 6

El formato de respuesta representará HTML así:

<table>
<tr>
<td class="someClass">variable value</td>
</tr>
</table>

Como resultado, no solo los medios para producir su código serán ilegibles, sino que el resultado también se tabulará de manera inapropiada. Quédese con la otra opción.

Answer 7

Prefiero <% =% > únicamente porque facilita el desarrollo de Javascript. Puede escribir código que haga referencia a sus controles de esta manera

var myControl = document.getElementById('<%= myControl.ClientID %>');

Entonces puedo usar ese control de la forma que desee en mi código JavaScript sin tener que preocuparme por las ID codificadas.

Response.Write puede romper algunos códigos ASP.NET AJAX en algunas ocasiones, así que trato de evitarlo a menos que lo use para representar cosas específicas en controles personalizados.

Answer 8

Intento usar el paradigma MVC cuando hago ASP / PHP. Hace que las cosas sean más fáciles de mantener, reestructurar y ampliar. En ese sentido, tiendo a tener una página que representa el modelo. Es principalmente VB / PHP y establece vars para su uso posterior en la vista. También genera trozos de HTML cuando se repite para su posterior inclusión en la vista. Entonces tengo una página que representa la vista. Eso es principalmente HTML salpicado de <% =% > Etiquetas El modelo es #include -d en la vista y listo. La lógica del controlador generalmente se realiza en JavaScript en una tercera página o en el lado del servidor.

Answer 9

Mi ASP clásica está oxidada, pero:

Response.Write "<table>" & vbCrlf
Response.Write "<tr>" &vbCrLf
Response.Write "<tdclass=""someClass"">" & someVariable & "</td>" & vbCrLf 
Response.Write "</tr>" & vbCrLf 
Response.Write "</table>" & vbCrLf

esto se ejecuta tal cual. Esto, sin embargo:

<table>
  <tr>
     <td class="someClass"><%= someVariable %></td>
  </tr>
</table>

resulta en:

Response.Write"<table>\r\n<tr>\r\n<td class="someClass">"
Response.Write someVariable
Response.Write "</td>\r\n</tr>\r\n</table>"

Donde \ r \ n es un vbCrLf

Entonces, técnicamente, el segundo es más rápido. SIN EMBARGO, la diferencia se mediría en milisegundos individuales, por lo que no me preocuparía. Me preocuparía más que el primero sea prácticamente imposible de mantener (especialmente por un desarrollador de HTML-UI), mientras que el segundo es trivial de mantener.

apoyos a @Euro Micelli: el mantenimiento es la clave (que también es la razón por la cual lenguajes como Ruby, Python y en el pasado (aunque ...) C # y Java patearon traseros sobre C, C ++ y Assembly, los humanos podrían mantener el código, que es mucho más importante que reducir algunos ms de una carga de página.

Por supuesto, C / C ++ etc. tienen su lugar ... pero este no lo es. :)

Answer 10

<% =% > y el resto se expande a Response.Write () para que sea lo mismo al final.

Answer 11

No hay mejora de rendimiento al cambiar a Response.Write, y puede ser más rápido de leer y mantener utilizando la notación de acceso directo.

Answer 12

Debería enmarcar estas preguntas en términos de reutilización de código y mantenimiento de código (también conocido como legibilidad). Realmente no hay ganancia de rendimiento de ninguna manera.

Answer 13

<% = Bazify ()% > es útil cuando genera HTML a partir de una expresión corta en línea con algo de HTML .

Response.Write " foo " es mejor cuando necesita hacer algo de HTML en línea con mucho código .

Técnicamente, son lo mismo.

Hablando de su ejemplo, sin embargo, el código Response.Write hace muchas concatenaciones de cadenas con & amp ;, que es muy lento en VBScript . Además, como Russell Myers dijo , no está etiquetado de la misma manera que su otro código, lo que puede ser involuntario .

Answer 14

Estoy de acuerdo con Jason , más aún ahora que .NET ofrece un marco MVC como alternativa a eso horrible Web Form / Postback / ViewState .NET comenzó con.

Tal vez sea porque yo era un ASP / HTML / JavaScript clásico de la vieja escuela y no era un programador de aplicaciones de escritorio VB que me hizo simplemente no entender el "Formulario del Camino de la Web". pero estoy tan contento de que parece que estamos dando un círculo completo y volviendo a una metodología como Jason se refiere.

Con eso en mente, siempre elegiría una página incluida que contenga su modelo / lógica y <% =% > tokens dentro de su plantilla de HTML "ver". Su HTML será más "legible" y su lógica se separó tanto como lo permite ASP clásico; estás matando a un par de pájaros con esa piedra.

Answer 15

Si debe escribir y mantener una aplicación ASP clásica, debe consultar el motor de plantillas KudzuASP gratuito.

Es capaz de 100% de código y separación HTML y permite contenido condicional, sustitución de variables, control de nivel de plantilla de la página asp original. If-Then-Else, Try-Catch-Finalmente, Switch-Case y otras etiquetas estructurales están disponibles, así como etiquetas personalizadas basadas en la página asp o en bibliotecas cargables dinámicamente (archivos de código asp) Las etiquetas estructurales se pueden incrustar dentro de otras etiquetas estructurales etiquetas a cualquier nivel deseado.

Las etiquetas personalizadas y las bibliotecas de etiquetas son fáciles de escribir y se pueden incluir en el nivel de código de la página asp o mediante el uso de una etiqueta de inclusión en el nivel de plantilla.

Las páginas maestras se pueden escribir invocando un motor de plantillas en el nivel de página maestra y aprovechando un segundo motor de plantillas hijo para cualquier contenido interno.

En KudzuASP su página asp contiene solo código, crea el motor de plantillas, configura las condiciones iniciales e invoca la plantilla. La plantilla contiene diseño HTML. Una vez que la página asp invoca la plantilla, se convierte en un recurso impulsado por eventos totalmente impulsado por la evaluación de la plantilla y la estructura que contiene.