asp-classic - for - submit asp classic
Response.Write vs<%=%> (15)
Debe enmarcar estas preguntas en términos de reutilización de código y mantenimiento del código (también conocido como legibilidad). Realmente no hay ganancia de rendimiento de ninguna manera.
Teniendo en cuenta que esto es para asp clásico
Que es mejor, todo el HTML contenido en Response.Write Statements o insertar variables en HTML a través de <% =%>.
P.ej
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 estoy preguntando desde un punto de vista del rendimiento en el que 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?
Dejando de lado los problemas de lectura / mantenimiento del código que otros han abordado, tu pregunta fue específicamente sobre el rendimiento cuando tienes múltiples variables para insertar, así que supongo que vas a repetir varias veces el fragmento de código. En ese caso, debe obtener el mejor rendimiento utilizando una sola Response.Write sin concatenar todas las nuevas líneas:
Response.Write "<table><tr><td class=""someClass"">" & someVar & "</td></tr></table>"
El navegador no necesita las líneas nuevas o las pestañas o cualquier otro formato bonito para analizar el HTML. Si busca rendimiento, puede eliminar todos estos. También reducirá su salida de HTML, 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, quiere minimizar el cambio de contexto entre HTML y ASP: recibirá un golpe por cada salto de uno a otro.
Para ayudar con la legibilidad al compilar una declaración más larga, puede usar el carácter y las pestañas de continuación de línea de VBScript en su código fuente (pero no el resultado) 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 se dejan caer muchas variables en la salida (es decir, una gran cantidad de cambios 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 aparte, y, por supuesto, no siempre es una opción.
Actualización: consulte los consejos 14 y 15 de 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 .
Desde un punto de vista de preferencia personal, prefiero el método <% =%> porque creo que proporciona un mejor contenido variable de separación del contenido estático.
El formato de respuesta renderizará 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 forma inapropiada. Quédate con la otra opción.
Intento usar el paradigma MVC cuando hago ASP / PHP. Hace las cosas más fáciles de mantener, rediseñar, 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 con 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.
Muchas de las respuestas aquí indican que los dos enfoques producen el mismo resultado y que la elección es de estilo y rendimiento de codificación. Parece que se cree que el contenido estático fuera de <%%> se convierte en una sola Respuesta.Escribir.
Sin embargo, sería más exacto decir que el código fuera de <%%> se envía con BinaryWrite.
Response.Write toma una cadena Unicode y la codifica en la página Response.CodePage antes de colocarla en el búfer. Ninguna codificación de este tipo tiene lugar para el contenido estático en un archivo ASP. Los caracteres que están fuera de <%%> se vuelcan en bytes literales por bytes en el búfer.
Por lo tanto, donde Response.CodePage es diferente de la página de códigos que se utilizó para guardar el archivo ASP, los resultados de los dos enfoques pueden diferir.
Por ejemplo, digamos que tengo este contenido guardado en una página de códigos 1252 estándar: -
<%
Response.CodePage = 65001
Response.CharSet = "UTF-8"
%>
<p> The British £</p>
<%Response.Write("<p> The British £</p>")%>
El primer párrafo está distorsionado, ya que £ no se enviará utilizando la codificación UTF-8, el segundo 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 guardados difiere de la página de códigos de salida. Por este motivo, prefiero guardar como UTF-8, incluir <% @ codepage = 65001 y establecer Response.Charset = "UTF-8".
No hay mejora en el rendimiento cambiando a Response.Write, y puede ser más rápido de leer y mantener usando la notación de acceso directo.
Prefiero <%= %> únicamente porque facilita el desarrollo de Javascript. Puedes escribir código que haga referencia a tus controles como este
var myControl = document.getElementById(''<%= myControl.ClientID %>'');
Puedo usar ese control de la forma que quiera en mi código de JavaScript sin tener que preocuparme por los IDs codificados.
Response.Write puede romper un poco de código AJAX de ASP.NET en algunas ocasiones, así que trato de evitarlo a menos que lo use para representar cosas específicas en controles personalizados.
Prefiero el método <% =%> en la mayoría de las situaciones por varias razones.
- El HTML está expuesto al IDE para que pueda ser procesado y le brinde información sobre herramientas, cierre de etiquetas, etc.
- Mantener la sangría en el HTML de salida es más fácil, lo que puede ser muy útil con el diseño de reelaboración.
- Nuevas líneas sin agregar vbCrLf en todo y otra vez para revisar el origen de salida.
<%= %> y el resto se expande a Response.Write() por lo que es el mismo al final.
Mi ASP clásico está oxidado, 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 como es. Esto, sin embargo:
<table>
<tr>
<td class="someClass"><%= someVariable %></td>
</tr>
</table>
resultados 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, 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 UI HTML), mientras que el segundo es trivial de mantener.
accesorios para @Euro Micelli - el mantenimiento es la clave (que es también la razón por la cual idiomas como Ruby, Python, y en el pasado (aún así ...) C # y Java patearon C, C ++ y Assembly- los humanos podían mantener el código , que es mucho más importante que eliminar algunos ms de una carga de página.
Por supuesto, C / C ++ etc. tienen su lugar ... pero esto no es todo. :)
Primero, el factor más importante que debe considerar es la facilidad de mantenimiento. Podría comprar una granja de servidores con el dinero y el tiempo que de otra forma desperdiciaría al tener 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 scripts directos, 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 <%= %> lleva a la versión moderna del "código de spaghetti": la temida "sopa de etiqueta". No podrás hacer cara o cruz de la lógica. Por otro lado, demasiado uso de Response.Write significa que nunca podrás ver la página hasta que se muestre. Usa <%= %> 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 tiene solo unos pocos lugares con texto variable para reemplazar, la sintaxis <%= %> es muy compacta y legible. Sin embargo, a medida que el <%= %> comienza a acumularse, oscurecen cada vez más el HTML y, al mismo tiempo, el HTML oscurece cada vez más su lógica. Como regla general, una vez que comience a tomar bucles, debe parar y pasar a Response.Write`.
No hay muchas otras reglas duras y rápidas. Debe decidir por su página particular (o sección de la página) cuál es más importante, o más difícil de entender o más fácil de romper: su lógica o su HTML? Por lo general, es uno o el otro (he visto cientos de casos de ambos)
Si tu lógica es más crítica, deberías pesar más hacia Response.Write ; hará que la lógica se destaque. Si HTML es más crítico, favor de <%= %> , lo que hará que la estructura de la página sea más visible.
A veces tuve 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.
Si tiene que escribir y mantener una aplicación ASP clásica, debe consultar el motor gratuito de plantillas KudzuASP.
Es capaz de separar el código y el HTML al 100% y permite el contenido condicional, la sustitución de variables, el control de nivel de plantilla de la página asp original. If-Then-Else, Try-Catch-Finally, Switch-Case y otras etiquetas estructurales están disponibles, así como etiquetas personalizadas basadas en la página asp o en librerías dinámicamente cargables (archivos de código asp). Las etiquetas estructurales pueden integrarse dentro de otras estructuras 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 la 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, establece las condiciones iniciales e invoca la plantilla. La plantilla contiene diseño HTML. Una vez que la página asp invoca a la plantilla, se convierte en un recurso impulsado por eventos totalmente impulsado por la evaluación de la plantilla y la estructura que contiene.
Estoy de acuerdo con Jason , más ahora que .NET está ofreciendo un marco MVC como alternativa a ese espantoso Formulario Web / Postback / ViewState .NET comenzó con.
Tal vez es porque yo era el clásico ASP / HTML / JavaScript de la vieja escuela y no un programador de aplicaciones de escritorio VB que me hizo simplemente no entender "The Way of the Web Form?" pero estoy tan contento de que parezca que estamos dando un rodeo completo y volviendo a una metodología a la que se refiere Jason .
Con esto en mente, siempre elegiría una página incluida que contenga los tokens de modelo / lógica y <% =%> dentro de su "vista" de HTML de plantilla efectivamente. Su HTML será más "legible" y su lógica se separará tanto como el ASP clásico; estás matando un par de pájaros con esa piedra.
<% = Bazify ()%> es útil cuando está generando HTML a partir de una breve expresión en línea con algo de HTML .
Response.Write "foo" es mejor cuando necesitas hacer algo de HTML en línea con una gran cantidad de código .
Técnicamente, son lo mismo.
Hablando de su ejemplo, sin embargo, el código Response.Write hace una gran cantidad de concatenación de cadenas con &, que es muy lenta en VBScript . Además, como dijo Russell Myers , no está etiquetado de la misma manera que su otro código, que podría ser involuntario.