Objetos ASP

Cada script ASP dispone desde el momento en que es ejecutado de una serie de objetos predefinidos. Estos objetos no hace falta crearlos. Se encuentran disponibles para cualquier script y permiten realizar funciones básicas como averiguar los parámetros pasados al script, enviar información al usuario, guardar variables persistentes, etc. Aquí exponemos un breve resumen de los más importantes, con sus propiedades y métodos más utilizados.

Response

Se utiliza para enviar la salida del script, es decir, lo que verá el usuario en su navegador.

Los métodos mas importantes del objeto response son:

  • Response.Write (cadena).Envía la cadena de caracteres al cliente. Equivale a intercalar código HTML entre el ejecutable.

    Así, el siguiente código

    <%
    if num > 1000 then
     Response.Write ("<h1>Se ha pasado de rosca</h1>")
    End if
    %>

    Es totalmente equivalente a éste

    <%
    if num > 1000 then %>
     <h1>Se ha pasado de rosca</h1>
    <% End if %>

    De hecho, el HTML intercalado se implementa internamente mediante sentencias Response.Write.

  • Response.Redirect (Url). Redirige la página ASP a la URL especificada.

    Por ejemplo, esto que sigue es una página ASP completa que simplemente redirige a la web www.arsys.es.

    <% Response.Redirect ("http://www.arsys.es") %>

    La redirección se implementa mediante cabeceras HTTP que son distintas que las enviadas cuando se muestra una página web. Eso significa que si se utiliza Response.Write o se intercala cualquier código HTML, ya no funcionará un posterior Response.Redirect porque se habrán enviado las cabeceras de mostrar una página web, no las de redirección.

    No obstante, existe una forma de rectificar y enviar un comando de redirección tras haber enviado comandos write. Esto implica el uso de la propiedad Buffer y los métodos Flush y Clear, como se explica a continuación.

  • Response.Flush. Envía de inmediato los datos del buffer.Si se establece en True la propiedad Response.Buffer, la salida del script (enviada mediante comandos Response.Write o HTML intercalado) no se envía directamente al navegador, sino que queda en un buffer (espacio intermedio de almacenamiento) del servidor.El método Response.Flush envía los datos del buffer al navegador. Otra forma de enviar los datos del buffer es simplemente dejar que termine el script o invocar el método End.
  • Response.Clear. Borra los datos del buffer.Utilizar un buffer sólo tiene sentido si pensamos que nos podemos arrepentir de los datos enviados. Este método permite precisamente eso, anular todos los comandos Response.Write y HTML intercalado que hayamos utilizado desde que pusimos en True la propiedad Response.Buffer.
  • Response.End. Termina el script y envía el buffer si está a True la propiedad Response.Buffer.
  • Response.Buffer. Si se establece en True, se utiliza un buffer para la salida de datos, en combinación con los métodos anteriormente descritos.A pesar de la insistencia en el buffer, es algo que prácticamente no se usa a no ser que sea realmente necesario, pues ralentiza el mostrado de la página web.

El único método realmente importante del objeto Response es Write.

Request

El objeto Request se utiliza para recoger los parámetros de entrada del script, es decir, los datos de los formularios o las variables pasadas mediante la interrogación en la URL. No tiene métodos ni propiedades dignas de mención, sino sólo tres colecciones muy importantes: Form, QueryString y ServerVariables.

Colección Request.Form

Mantiene la colección de parámetros pasados al script mediante el método POST, que es el usado preferentemente en los formularios, de ahí su nombre. Request.Form nos devuelve siempre la colección de parámetros. Por tanto, la expresión admite la sintaxis de las colecciones de Visual Basic, es decir:

  • Request.Form(“Param”) nos da el valor del parámetro de nombre Param siempre y cuando exista un único valor para dicho parámetro. Por ejemplo, nos daría el texto introducido en un control de formulario cuyo código HTML podría ser del estilo a <input type=text name="Param">.
  • Request.Form(3) nos da el valor del tercer elemento de la colección, es decir, el valor del tercer control del formulario.
  • Request.Form.Count nos da el número de parámetros pasados en el formulario.Como existe la posibilidad de parámetros multivaluados, como una lista de selección múltiple, la expresión Request.Form("Param") puede ser a su vez una colección: la colección de valores del parámetro.

    Por ejemplo, si en nuestro formulario tenemos una lista de selección múltiple, cuyo nombre sea Lista, la expresión

    Request.Form("Lista")[2]

    nos daría el segundo elemento seleccionado de la lista, y

    Request.Form("Lista").Count

    nos daría el número de elementos que ha seleccionado el usuario.

    Su valor será 1 si se trata de un parámetro monovaluado y 0 si es un parámetro no definido en el formulario.

También es posible iterar sobre las colecciones anteriores mediante bucles For each. El siguiente ejemplo nos muestra todos los parámetros pasados al script y sus valores:

<%
For each param In Request.Form
Response.Write ("<p>")
Response.Write("El parámetro " & param & " toma el valor " &
 Request.Form(param) )
Response.Write("</p>")
Next
%>

Colección Request.QueryString

Mantiene la colección de parámetros pasados al script mediante el método GET, que es el utilizado cuando se escribe la URL seguida del símbolo ? y de los parámetros con sus valores.

Por ejemplo:

http://www.dominio.com/cgi-bin/miprog.asp?nombre=Pepe&apellido=Gotera

Invoca el script pasando las variables nombre (valor = Pepe) y apellido (valor = Gotera).

El símbolo & se utiliza como separador entre los distintos parámetros.

Aunque no es lo habitual, también los formularios pueden utilizar el método GET. Para ello basta con ponerlo en la marca <FORM> de la página web:

<FORM method=GET action = "MiForm.asp">

En este caso, los parámetros del formulario los obtendríamos en Request.QueryString en lugar de en Request.Form.

Colección Request.ServerVariables

Mantiene la colección de las variables de entorno del servidor web. Entre las mismas, podemos encontrar valores muy interesantes conocidos por el servidor web, como la dirección IP del usuario que está viendo las páginas, el login y contraseña si estamos en un directorio de acceso restringido, el nombre del dominio, el nombre del script, etc.

Estas son algunas de las variables de servidor:

VARIABLE
DESCRIPCIÓN
ALL_HTTP Todas las cabeceras HTTP enviadas por el cliente.
AUTH_PASSWORD La contraseña del cliente.
AUTH_USER Nombre de usuario autentificado en bruto (raw).
CERT_COOKIE ID de usuario único para el certificado del cliente, devuelto como cadena de caracteres. Puede ser usado como firma para el certificado al completo.
CERT_FLAGS El bit0 es puesto a 1 si está presente el certificado del cliente. El bit1 es puesto a 1 si la autoridad de certificados del certificado del cliente es inválida (no está en la lista de las reconocidas en el servidor).
CERT_ISSUER Campo del suministrador del certificado de cliente (O=MS, OU=IAS, CN=user name, C=USA).
CERT_KEYSIZE Número de bits de la clave SSL. Por ejemplo, 128.
CERT_SECRETKEYSIZE Número de bits en la clave secreta del certificado del servidor. Por ejemplo, 1024.
CERT_SERIALNUMBER Campo del número de serie del certificado del cliente.
CERT_SERVER_ISSUER Campo para el suministrador del certificado del servidor.
CERT_SERVER_SUBJECT Campo del sujeto del certificado del servidor.
CERT_SUBJECT Campo del sujeto del certificado del cliente.
CONTENT_LENGTH La longitud del contenido tal como es suministrado por el cliente.
CONTENT_TYPE El tipo de datos del contenido. Se usa con solicitudes que adjuntan información, como las solicitudes de http GET, POST, y PUT.
GATEWAY_INTERFACE La revisión de la especificación CGI usada por el servidor. El formato es CGI/revision.
HTTP_<HeaderName> El valor almacenado en la cabecera o header llamada HeaderName. Cualquier header distinto de los incluidos en esta tabla debe ser prefijado por HTTP_ para que la colección de ServerVariables pueda recuperar su valor. Tenga en cuenta que el servidor interpreta cualquier carácter con guión bajo (_) en HeaderName como guiones normales en el header. Por ejemplo, si escribe HTTP_MY_HEADER, el servidor busca por un header enviado como MY-HEADER.
HTTPS Devuelve una activación ON si la petición vino a través de un canal seguro (SSL), o devuelve una desactivación OFF si la petición es a través de un canal no seguro.
HTTPS_KEYSIZE Clave de tamaño en bits de una conexión Secure Sockets Layer. Por ejemplo, 128.
HTTPS_SECRETKEYSIZE Número de bits en una clave privada de certificado del servidor seguro. Por ejemplo, 1024.
HTTPS_SERVER_ISSUER Campo para el suministrador del certificado del servidor seguro.
HTTPS_SERVER_SUBJECT Campo del sujeto del certificado del servidor
INSTANCE_ID La ID para la instancia IIS en el modo texto. Si la instancia ID es 1, aparece como una cadena. Puede usar esta variable para recuperar la ID de la instancia del servidor web (en la base de datos) al cual corresponde la petición.
INSTANCE_META_PATH La ruta de la metabase para la instancia del IIS que responde a la petición.
LOCAL_ADDR Devuelve la dirección del servidor en la que entró la petición. Esto es importante en el caso de las máquinas multi-homed, donde puede haber múltiples direcciones IP enlazadas a una máquina, y puede interesar conocer cuál es la dirección usada por la petición.
LOGON_USER Nombre de usuario de la cuenta de Windows.
PATH_INFO Información sobre una ruta extra tal como es ofrecida por el cliente. Usted puede acceder a scripts usando su ruta virtual y la variable de servidor PATH_INFO. Si esta información proviene de una URL, es decodificada por el servidor antes de que sea pasada al script CGI.
PATH_TRANSLATED Versión traducida de PATH_INFO que toma la ruta y configura cualquier estructura necesaria de relación virtual-física.
QUERY_STRING Petición de información almacenada en la cadena siguiendo al signo de interrogación (?) en la solicitud http.
REMOTE_ADDR La dirección IP del host remoto que hace la consulta.
REMOTE_HOST El nombre del host que hace la consulta. Si el servidor no tiene esta información, utilizará REMOTE_ADDR y dejará esta variable vacía.
REMOTE_USER Cadena de nombre de usuario no localizada, introducida por el usuario. Este es el nombre que es realmente enviado por el usuario, distinto de aquellos que son modificados por cualquier filtro de autentificación instalado en el servidor.
REQUEST_METHOD Método usado para realizar la consulta. Para HTTP, éste es GET, HEAD, POST, etc.
SCRIPT_NAME Una ruta virtual al script que está siendo ejecutado. Es usado para autoreferenciar direcciones URL.
SERVER_NAME El nombre, alias DNS, o dirección IP del servidor, tal como aparecería en la autoreferencia de direcciones URL.
SERVER_PORT El número de puerto al que fue enviada la petición.
SERVER_PORT_SECURE Una cadena que contiene 0 ó 1. Si la petición está siendo manejada a través de un puerto seguro, entonces la cadena será 1. De otro modo, será 0.
SERVER_PROTOCOL El nombre y revisión del protocolo de peticiones de información. El formato es protocol/revision.
SERVER_SOFTWARE El nombre y versión del software del servidor que responde las peticiones. El formato es name/version.
URL Proporciona la porción básica de la URL.

Ejemplo:

<h3> Usted está viendo el dominio
<%= Request.ServerVariables("SERVER_NAME") %> </h3>

Server

El objeto Server sólo tiene un método importante, pero es el más importante de todo el esquema ASP, ya que es el que permite crear objetos componentes y extender la funcionalidad del ASP de forma ilimitada. Con Visual Basic Script, en ASP, y sin utilizar objetos componentes, no se puede hacer prácticamente nada; ni siquiera leer un archivo del disco. Toda la funcionalidad reside en los objetos componentes ActiveX.

El método Server.CreateObject

Crea una instancia del componente de servidor que se le pase como parámetro.
Su sintaxis es: Server.CreateObject(ProgID)

El parámetro ProgID es un identificador único del componente que suele darse en la forma Vendedor.Componente.

Por ejemplo:

<%
Set herram = Server.CreateObject ("MSWC. Tools")
if herram.FileExists ("mipagina.html") Then
%>
<p>Esta es <a href="/blogmipagina.html">mi página</a> </p>
<% else %>
<p>Lo siento. Mi página ha desaparecido</p>
<% end if %>

MSWC.Tools es el ProgID del objeto Tools de Microsoft, que viene con la instalación de ASP. No es un objeto predefinido como Response o Request, sino que hay que crearlo como cualquier otro. En Visual Basic los objetos se asignan a variables utilizando Set. Después de creado, podemos acceder a sus métodos y propiedades. En este caso, utilizamos el método FileExists que nos dice si existe o no un archivo dada su URL relativa.

Session

Lo interesante del objeto Session son las variables que nosotros podemos guardar en él. Esas variables permanecen entre distintas páginas web y son únicas para cada usuario. Así, si usted guarda el nombre del usuario en una variable del objeto Session, podrá incorporarlo a todas las demás páginas, ya que ese dato no se pierde al terminar el script. Además, aunque haya varios usuarios viendo simultáneamente las páginas no hay problema, ya que cada uno tiene un objeto session distinto. La sintaxis es:

Session("variable") = valor

Esto guarda el valor en la variable. Para recuperarlo más adelante en éste u otro script distinto, sólo tendríamos que escribir Session(“variable”). En PerlScript el objeto Session se implementa como un hash con la sintaxis:

$Session{variable} = valor

Ejemplo:

Puede guardar este script con el nombre p2.asp.

Este ejemplo es prácticamente igual al p1.asp con la única diferencia de que se guarda el nombre del usuario en el objeto Session.

<html>
<head>
<title>Pequeña prueba del objeto Session</title>
</head>
<body>
<%
nombre = Request.Form("nombre")
if nombre = "" then
%>
<p>Por favor, escriba su nombre </p>
<form method = "Post" action="/blogp2.asp">
<input type ="text" name = "nombre">
<input type = "submit" value = " Enviar ">
<%
else
Response.Write ("Su nombre es " & nombre & ".
No se preocupe que no se me va a olvidar.")
Session("Nombre") = nombre
end if
%>
</body>
</html>

Para escribir el nombre del usuario en páginas ASP posteriores a ésta, basta con que intercale el código

<%= Session("Nombre") %>

en el HTML de la página.

Application

Es prácticamente igual que el objeto Session y sirve para lo mismo (guardar variables), con la única diferencia de que las variables son únicas para la aplicación en su conjunto, no para cada sesión de usuario.

Por tanto, en el objeto Application se deben guardar variables que vayan a ser comunes a todos los usuarios, no las específicas como su nombre.

Esto implica también que si deseamos modificar el valor de una variable guardada en el objeto Application, es necesario bloquear el objeto para evitar que desde otra sesión se acceda simultáneamente a la misma variable. Para ello existen los métodos Lock y Unlock.

  • El método Application.Lock bloquea el objeto impidiendo que otros clientes modifiquen cualquier variable guardada.
  • El método Application.Unlock desbloquea el objeto permitiendo que otros clientes modifiquen las variables del objeto Application.

Ejemplo:

Una variable típica para guardar en el objeto Application es el número de visitas a la web. La variable no debe estar asociada a un cliente en concreto, sino que debe ser general. En la página en cuestión pondríamos el siguiente código:

<%
Application.Lock
Application("NumVisitas") = Application("NumVisitas") + 1
Application.Unlock
%>

Cuando queramos mostrar el número de visitas recibidas, bastará con que insertemos

<%= Application("NumVisitas") %>

Los eventos de los objetos Session y Application y el archivo global.asa

Los objetos Application y Session tienen eventos al estilo de los formularios de Visual Basic, sólo que mucho más limitados. De hecho, cada objeto sólo tiene dos eventos: uno que se lanza cuando es creado y otro cuando es destruido.

Eso significa que podemos escribir código de inicialización que se ejecutará cada vez que un usuario acceda por primera vez a nuestras páginas (creación de un objeto Session) o cuando acceda el primer usuario (creación del objeto Application). Asimismo, podemos escribir código de limpieza justo cuando se termine la sesión de un usuario o al terminar la aplicación en su conjunto.

El código de estos eventos ha de estar en un archivo de nombre global.asa que debe estar en el directorio raíz de la aplicación. El archivo global.asa es opcional y puede contener tres tipos de información:

  • Eventos de creación y destrucción de aplicación y sesiones.
  • Marcas <OBJECT> para crear objetos de servidor con alcance de sesión o aplicación (método alternativo al de Server.CreateObject).
  • Bibliotecas de tipos de objetos componentes.

Los eventos de Session y Application han de estar en marcas <SCRIPT> como se indica en el ejemplo de global.asa siguiente:

<SCRIPT LANGUAGE=VBScript RUNAT=Server>
sub Application_onStart
Application("NumSesionesActivas") = 0
Application("NumSesionesTotales") = 0
End sub
sub Session_onStart
Application.Lock
Application("NumSesionesActivas") = Application("NumSesionesActivas") + 1
Application("NumSesionesTotales") = Application("NumSesionesTotales") + 1
Application.UnLock
End sub
sub Session_onEnd
Application.Lock
Application("NumSesionesActivas") = Application("NumSesionesActivas") -1
Application.UnLock
End sub
sub Application_onEnd
End sub
</SCRIPT>

Aquí se utilizan los eventos para guardar el número de sesiones activas y totales de nuestra aplicación, es decir, el número de clientes que nos está viendo en un momento dado, y el total que nos ha visitado. Como se trata de datos globales y no ligados a una sesión, hay que guardarlos en el objeto Application, y cuando se quieren modificar, es necesario bloquear primero dicho objeto.

¿Cuánto dura una sesión y cómo funciona?

Lógicamente el servidor web no puede saber si el usuario está todavía leyendo la última página que descargó de la web o se ha ido ya a dormir. De ahí que la duración de una sesión se mida por el tiempo de inactividad del usuario.

Para medir éste el objeto Session dispone de una propiedad llamada Session.Timeout en la que el tiempo se mide en minutos.

Cuando un usuario de Internet ve por primera vez cualquier página ASP de nuestra aplicación, el servidor web automáticamente le envía una cookie y crea para él un objeto Session con llamada al evento de creación que se encuentre en global.asa. Si pasan los minutos indicados en Session.Timeout sin que el usuario haya visto una nueva página, la sesión se da por concluida y el objeto Session del usuario es destruido.

La cookie es una pieza de información que el servidor web envía al cliente para que se guarde en su disco duro. Cuando el cliente vuelve al sitio web reenvía la cookie al servidor y de esa forma éste puede distinguir a los usuarios y hacerles un seguimiento individual.

Más sobre objetos componentes: alcance y creación

Los objetos que se crean mediante Server.CreateObject (ProgID) tienen un alcance a nivel de script, es decir, cuando termina el script los objetos son eliminados. Sin embargo, en ciertas ocasiones será conveniente que los objetos tengan duración de sesión o incluso de aplicación. Hay dos formas de dar alcance de sesión o de aplicación a un objeto:

  • Guardarlo en una variable del objeto Session o Application.
  • Crearlo en global.asa mediante una marca <OBJECT>.

Primer método. Ejemplo:

<%
' Para crearlo con alcance de sesion lo guardamos en el objeto Session
Set Session("miobjeto") = Server.CreateObject("MPX.Tool")
........
........
' Para verlo después en otra página ASP
Set miobjeto = Session("miobjeto")
miobjeto.show
%>

Segundo método. Ejemplo:

Este procedimiento es el más cómodo. En primer lugar escribimos lo siguiente en el global.asa:

<OBJECT RUNAT=Server SCOPE=Session ID=miobjeto PROGID="MPX.Tool">
</OBJECT>

Y ahora ya nos podemos referir al objeto en cualquier página ASP sin más que llamarlo por su nombre: miobjeto.show.

En general, conviene no abusar del alcance de Session o de Application para los objetos, ya que además de consumir recursos innecesariamente, podemos perder cualidades.

Por ejemplo, si queremos conectarnos a una base de datos mediante un DSN, no es conveniente dar alcance de Session al objeto Connection y dejar la base de datos abierta. Además de consumir recursos del servidor, perderemos la opción de pooling del ODBC.