Si la sala de informática está a punto de cerrar o estás ansioso por salir con una chica, salta directamente al cuarto párrafo natural.
Los scripts que se describen a continuación incluyen scripts del lado del servidor y scripts del lado del cliente que se refieren a la parte del script que se ejecuta en el servidor. Por ejemplo, el Response.Write común obviamente se ejecuta en el lado del servidor. Los scripts se pueden escribir utilizando los lenguajes VBScript y JScript; en este artículo se utilizan VBScript y Jscript.
También se puede considerar que los scripts del lado del cliente incluyen dos lenguajes: VBScript y JavaScript, que son lenguajes de script que se ejecutan en el navegador del cliente. Por ejemplo, cuando visitamos una página web y aparece un cuadro de mensaje, esto se hace usando scripts del lado del cliente (alerta, msgbox, etc.), y obviamente no es algo que los scripts del lado del servidor puedan hacer. Hay otra gran diferencia entre los scripts del lado del cliente y los scripts del lado del servidor (en navegadores como IE y Firefox), y es que los scripts del lado del cliente pueden acceder al Modelo de objetos de documento (DOM) y pueden manipular objetos en la página (como como modificar el título de la página, modificar el atributo internalHTML de un div, etc.).
Primero, echemos un vistazo al proceso de ejecución de la página ASP.
1. IIS encuentra el archivo ASP y lo envía al motor ASP (normalmente ASP.DLL) para su procesamiento.
2. El motor abre el archivo ASP y encuentra el contenido entre <% y %> y, por supuesto, el contenido entre <script runAt=server> y el </script> correspondiente. Estos contenidos se denominan bloques de script. El motor solo analiza el contenido del bloque de secuencia de comandos, y el resto del contenido se ignora y se inserta entre los bloques de secuencia de comandos como caracteres sin sentido. Es necesario explicar que, de hecho, el contenido que se analiza es más que esto. Los archivos de inclusión del lado del servidor de la clase <!--#include ***--> también son incluidos y procesados por el motor. Si lee muchos programas, también sabrá que algunos objetos <object> cuyos atributos runAt están marcados como Servidor también se procesarán. No los discutiremos en profundidad aquí.
3. El motor ejecuta los scripts en el bloque de script. Estos scripts del lado del servidor se ejecutan en su conjunto, es decir, se puede escribir el siguiente código:
<%
Yo tenue
Para i=1 a 5
%> ¡Hola mundo!
<% Siguiente %>
El motor no analiza estos bloques de script por separado, lo que provoca errores de sintaxis en ambos bloques de script. Entonces llegamos a la siguiente conclusión: no todo el código de script que no es del servidor se enviará al cliente. Es posible que este código de script que no sea del servidor esté restringido por el bloque de script. El servidor definitivamente no se preocupará por la ejecución de los scripts del cliente, pero puede generar diferentes scripts del cliente a través de scripts del lado del servidor.
4. Finalmente, el motor genera un flujo de texto, o el resultado de la ejecución del script, que puede considerarse como una cadena, que es el código de la página web enviada al navegador del cliente. El navegador del cliente muestra la página. En este momento, el código fuente (archivo fuente) de la página no contiene el script del lado del servidor, pero contiene el resultado de la ejecución del script del lado del servidor (esto es obvio).
<%… %> y <script runat=servidor>…</script>
Todos son scripts del lado del servidor que se procesan y ejecutan al mismo tiempo. Se desempeñan como una unidad.
<% … %> y <script language=…>…</script>
El primero es un script del lado del servidor y el segundo es un script del lado del cliente. El primero se ejecuta primero y el segundo después.
De hecho, este no es necesariamente el caso. Es posible que los dos scripts se ejecuten al mismo tiempo, pero los espacios siguen siendo diferentes: el primero se ejecuta en el servidor y el segundo se ejecuta en el. navegador del cliente. Lógicamente, los primeros deben ejecutarse antes que los segundos. Al mismo tiempo, también llegamos a la conclusión: durante la ejecución de la misma página, el script del lado del cliente no puede retroalimentar al script del lado del servidor en cualquier caso, es decir, el cliente busca su libro de visitas y lo envía. Los mensajes nuevos o cualquier valor obtenido por el script del lado del cliente tampoco se pueden procesar en la misma respuesta del servidor.
Acerca de las llamadas a componentes
Tenga en cuenta que los scripts del lado del servidor y los scripts del lado del cliente son scripts. Naturalmente, puede crear componentes xmlhttp, componentes ADODB.Connection, etc., pero no se pueden colocar en ningún lugar.
Si xmlhttp se usa para rastrear páginas web (como colecciones) desde el servidor, debe crearse en el script del servidor. Si se usa para que el ajax del cliente acceda a la página del lado del servidor en segundo plano sin actualizar, entonces se ejecuta. en el cliente y, naturalmente, en el cliente Creado al final.
El componente ADODB.Connection se utiliza para acceder a la base de datos. En términos generales, se crea en el lado del servidor. Después de todo, es el programa asp del lado del servidor el que ejecuta los datos de la base de datos, pero si su base de datos está realmente conectada en el cliente. lado (como este http://bbs .bccn.net/thread-224966-1-2.html), entonces debe crearse en el script del cliente.
En definitiva, cosas contradictorias y cada bando tiene sus propias características. Diferentes cosas tienen diferentes contradicciones; una misma cosa tiene diferentes contradicciones en diferentes procesos y etapas de desarrollo; diferentes contradicciones en una misma cosa y dos aspectos diferentes de una misma contradicción tienen cada uno sus particularidades (pueden omitir a los que no entiendan) Don No mires…). Este principio requiere que nos adhiramos al principio del análisis concreto de problemas específicos y, bajo la guía del principio de universalidad de las contradicciones, analicemos concretamente las particularidades de las contradicciones y encontremos el método correcto para resolverlas. Nos oponemos a utilizar un método para resolver las contradicciones de cosas diferentes. Una llave abre una cerradura, y esto es lo que significa cantar cualquier canción que escuches en cualquier montaña.
Los scripts VBScript del lado del servidor utilizan el método Server.CreateObject(className) para crear objetos, y los scripts VBScript del lado del cliente utilizan el método CreateObject(className) para crear objetos.
Errores típicos
<%
Función TTamaño(b)
'Esta es mi función personalizada
Tamaño T=China
función final
%>
<a href=javascript:<%TSize('Variable')%> >Haga clic aquí para usar la función que definí</a>
(http://bbs.bccn.net/thread-225244-1-1.html)
Análisis de errores:
Confundir la diferencia entre scripts del lado del servidor y scripts del lado del cliente. Durante la ejecución real, encontraremos que el cliente no recibe ningún código como TSize en absoluto, porque TSize es un programa del lado del servidor procesado por el motor (tenga en cuenta que el procesamiento de funciones del motor es puramente para scripts del lado del servidor). llamadas y no se enviará de vuelta al cliente) desaparece y no es posible que funcione en el cliente. Esto significa que los scripts del lado del cliente no pueden llamar directamente a funciones de los scripts del lado del servidor.
De hecho, este programa tiene un error de sintaxis. Cuando el motor procesa este contenido, primero encuentra el contenido entre <% y%>, es decir, <%TSie('variable')%>. con reglas de sintaxis de VBScript. Bueno, si lo cambia a <%=TSize(variable)%>, no habrá errores de sintaxis en el script del lado del servidor. En este momento, la función TSize puede devolver el valor China normalmente, por lo que el atributo href lo recibe. el cliente está escrito así: javascript: China, no se puede hacer cumplir.
Impacto de los scripts del lado del servidor en los scripts del lado del cliente
Como se mencionó anteriormente, los scripts del lado del servidor se ejecutan lógicamente antes que los scripts del lado del cliente, por lo que un código como este es factible:
<%
Yo tenue
Para i=1 a 5
Respuesta.Escribir <tipo de script=texto/javascript> _
& alerta('¡Hola mundo! & i & ')</script>
Próximo
%>
Respecto a la ejecución de Response.Redirect y javascript
Tenga en cuenta que el siguiente código está escrito incorrectamente:
<%
Respuesta.Redireccionamiento index.asp
Respuesta.Escribir <tipo de script=texto/javascript> _
& alert('¡Contraseña incorrecta!')</script>
%>
Este es un error común. Los escritores a menudo piensan que escribir código de esta manera hará que el cliente muestre un mensaje de error de contraseña y luego lo redirija a index.asp. De hecho, esto no puede suceder incluso si el orden de las dos líneas. Si se intercambia el código, no será posible lograr este efecto.
La razón tiene que ver con la forma en que el servidor maneja las dos líneas de código. Es imposible que estas dos líneas de código funcionen al mismo tiempo.
Response.Write es enviar un fragmento de texto al cliente. El contenido de este texto puede ser un script. Luego, el navegador del cliente puede ejecutar el script después de recibirlo.
Response.Redirect envía un encabezado HTTP al cliente (¿qué es el encabezado HTTP? Digámoslo de esta manera, por ejemplo, escribir en las cookies del cliente es información del encabezado HTTP, y la información del encabezado HTTP se envía de regreso al cliente antes del cuerpo HTTP Navegador , es por esto que a veces obtenemos un error al modificar las Cookies después de apagar el buffering del servidor, porque el cuerpo ya comenzó a transmitir y no se permite enviar encabezados HTTP. información.), el contenido de la información le dice al navegador del cliente que debe saltar a la página para navegar. Tenga en cuenta que esta información de redireccionamiento entra en vigor de inmediato, lo que significa que esta información de redireccionamiento es exclusiva cuando el búfer está activado, independientemente de. si se ha utilizado Response. Write escribe cuánto contenido se escribe en el búfer. Una vez que se llama a Response.Redirect, el búfer se borrará y esta instrucción de encabezado se enviará al navegador del cliente. Si rastreamos dinámicamente la ejecución del programa, también encontraremos que después de llamar a Response.Redirect, el programa deja de ejecutarse, así que tenga en cuenta que el programa del lado del servidor debe cerrar la conexión de datos y otras operaciones antes de llamar a Response.Redirect.
Entonces, ¿cómo debería modificarse el ejemplo anterior? Si no está dispuesto a modificar index.asp para agregar un mensaje de secuencia de comandos, solo puede ejecutar la instrucción de redirección en la secuencia de comandos del cliente, de esta manera:
<%
Respuesta.Escribir <tipo de script=texto/javascript> _
& alerta('!');ubicación.href='index.asp'</script>
%>
Información del contacto
Si tiene algún comentario y sugerencia, especialmente errores y deficiencias en el artículo, o si desea agregar material nuevo al artículo, puede contactarme a través del foro de programación. Por supuesto, también puedes publicar preguntas después de esta publicación.
Vale la pena mencionar que si tiene preguntas sobre algoritmos y estructuras de datos, como no comprender por qué su programa está incorrecto o solicitar el código fuente de un determinado algoritmo, es posible que no obtenga una respuesta oportuna al utilizar esta información de contacto. Por favor pregunta en el foro de programación.
-------------------------------------------------- ----------------------------------
derechos de autor
Copyright (c) 2008 multiple1902
Se concede permiso para copiar, distribuir y/o modificar este documento bajo los términos de la Licencia de documentación libre GNU Versión 1.2 o cualquier versión posterior publicada por la Free Software Foundation.