Qué son los Objetos ASP

Tras crear una web, cada script ASP dispone desde el momento en que es ejecutado de una serie de objetos predefinidos. Estos objetos ASP 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 ("https://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.

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

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">

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:

<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.

<%
Set herram = Server.CreateObject ("MSWC. Tools")
if herram.FileExists ("mipagina.html") Then
%>
<p>Esta es <a href="mipagina.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

<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="p2.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>

<%= Session("Nombre") %>

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.

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

<%= 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.

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>.

<%
' 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
%>

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

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.