Eventos en ASP.NET
Las tecnologías avanzan en todos los frentes, y Microsoft
saca pecho desde hace años con su Framework .NET. Una
evolución interesante para el mundo de desarrollo en
lenguages propietarios que siempre aportan avances al mundo
tecnológico.
Introducción
En este tutorial veremos los eventos del ciclo de vida de una
aplicación web en ASP.NET. Recordemos que ASP.NET se basa en
el concepto de Web
Form, a diferencia de las aplicaciones de escritorio (los Window Form).
Ambos tienen un ciclo de vida diferente y basan su comportamiento en
eventos, pero debemos diferenciar ambos conceptos; todo lo que sigue a
continuación es propio de los desarrollos web
el framework .NET.
Los eventos en ASP.NET se clasifican en tres grupos:
- Eventos a nivel de aplicación. Son eventos
globales de nuestra web,
como pueden ser el inicio de la aplicación,
finalización de una sesión,
etc - Eventos a nivel de página. Habitualmente
lanzados por el
usuario, como el submit de un formulario o pulsar sobre un enlace. - Eventos a nivel de servidor. Son los eventos propios de los
controles de servidor de los Web Forms
Antes de entrar en detalles, echemos un vistazo al ciclo de
vida de una
aplicación web y sus eventos principales.
Eventos en el ciclo de vida de una aplicación web
Una aplicación web inicia propiamente su existencia
cuando un cliente se conecta a su página de inicio (es el
inicio de una sesión). El servidor web Internet Information
Server (IIS) levanta el
proceso aspnet_wp.exe (en caso de ser necesario, podría
estar ya activo con el servidor dando servicio) y carga el ensamblado
DLL que contiene el
código programado de la página
solicitada y que se ejecuta en lado servidor. El servidor crea una
instancia del Web Form solicitado, lo
completa accediento a los recursos e información necesarios,
ejecuta la
lógica de negocio y emite como respuesta ese Web Form en
formato HTML al browser cliente. Tras esto, la instancia del Web Form y
sus recursos son liberados de memoria.
petición web de una aplicación.
El ciclo se repite: el usuario rellena un formulario HTML,
envía los datos al servidor, éste crea un Web
form, le asigna los datos enviados y procesa los eventos,
envía el Web form resultante como HTML y se libera junto con
sus recursos. Vemos cómo los el ciclo de vida de un Web Form
es muy corto.
Continua
la
navegación por la web (e.g. proceso de un formulario)
Sin embargo, la aplicación web sigue viviendo hasta
que todas las sesiones a las que está dando servicio
finalizan. Tras un tiempo sin
atender nuevos eventos en una sesión, el servidor destruye
la sesión, y cuando no queda ninguna activa, finaliza la
aplicación web (el CLR libera de memoria los recursos de la
aplicación tales como el DLL cargado) y se lanza un evento
Application_End.
No hay clientes activos:
las sesiones expiran y la
aplicación web correspondiente finaliza
Debemos aclarar que por sesión entendemos una instancia de
navegador emitiendo peticiones a un servidor. Un usuario puede tener
múltiples navegadores abiertos y por tanto
múltiples sesiones iniciadas.
Si queremos que la información persista entre las
distintas instancias volátiles y sin estado de los
Web form, podemos
hacer uso de dos niveles de ámbito en el servidor:
- Variables a nivel de aplicación. Es un espacio
global existente en todo el ciclo de vida de la aplicación
web, y accesible desde todas las sesiones a las que ésta da
servicio en un determinado momento. - Variables a nivel de sesión. La
aplicación web tiene reservados tantos espacios de memoria
reservados como sesiones tenga activas y reducidas a su
ámbito e inaccesibles fuera de ellas (independientes entre
sí).
Eventos de las aplicaciones y de las sesiones
Vamos a enumerar los manejadores de (métodos que
capturan) los eventos y a ponerlos en práctica con
pequeños ejemplos en C# programados con Visual Studio .NET.
La signatura de los métodos son de la forma
protected void <nombre_manejador> (Object
sender, EventArgs e)
siendo <nombre_manejador> éstos:
| Manejador de evento |
Acción asociada |
| Application_Start | Primera visita a la página inicio de la aplicación web |
| Application_BeginRequest | Inicio petición al servidor (solicitar una página) |
| Application_EndRequest | Fin de petición al servidor (la página ya ha sido solicitada) |
| Application_End | Todas las sesiones de usuario expiran |
| Application_AuthenticateRequest | Petición de autenticación |
| Application_Error | La aplicación lanza un error |
| Session_Start | Un nuevo usuario solicita una página de la aplicación web |
| Session_End | Un usuario deja de hacer peticiones a la aplicación web y su tiempo de sesión expira. |
Los manejadores de eventos se encuentran definidos en el
fichero del
proyecto Global.asax:
Vamos a escribir un ejemplo que cuente el número de
veces que el servidor recive eventos de un internauta como nosotros.
Para ello utilizamos los mapas que ofrece el IIS como
variables de estado para almacenar objetos en memoria en sus
distintos ámbitos (‘Application’ para aplicación
y ‘Session’ para sesión) :
|
protected { //Initializations Application[«activeSessions»]=0;
Application[«activeApplications»]=(int)Application[«activeApplications»]+1; }
protected { Application[«activeSessions»]=(int)Application[«activeSessions»]+1; // Once in a Response.Write(«<p>Web }
protected { }
protected { }
protected { //the Application[«activeSessions»]=(int)Application[«activeSessions»]-1; }
protected { } |
Una vez compilada la aplicación accedemos a la URL
del ejemplo:
http://localhost/eventosASPNET/events_page.aspx
y vemos algo
así:
Desde otro navegador, accedemos a la misma
aplicación web:
Y más!:
 |
 |
Ahora bien: dos pestañas de un misno navegador
Internet Explorer se interpretan como dos peticiones dentro de una
misma sesión (son dos instancias de un mismo browser
contenedor). Por
en la siguiente captura sólo se muestran las trazas de la
request (no se captura ningún evento de inicio de
sesión porque ésta ya la inició
la pestaña de la izquierda):
Eventos de los Web Form
Si una página la hemos programado con un Web Form,
podemos utilizar los siguientes eventos para capturar una amplia
variedad de situaciones:
| Manejador de evento | Acción asociada |
| Page_Init | El servirdor crea una instancia del Web Form, carga sus controles y los inicializa con lo recibido del estado de la vista (datos del browser del cliente que vienen con la request). |
| Page_Load | Los controles del servidor se cargan en un nuevo objeto de tipo Page. Ahora el programador puede acceder a la información de la vista y manejar los controles de la página, contenido, etc. |
| Page_PreRender | El objeto Page va a renderizarse en código interpretable por el browser en cuanto finalice este evento. |
| Page_Unload | El objeto Page deja de ser referfenciable, se destruye. |
| Page_Disposed | La memoria ocupada por Page es liberada. |
| Page_Error | Evento iniciado cuando se ha producido una excepción no capturada. |
| Page_AbortTransaction | Una operación transaccional ha sido finalizada sin llegar a su fin. |
| Page_CommitTransaction | La transacción se ha completado con éxito. |
| Page_DataBinding | Un control de servidor se ha conectado a una fuente de datos. |
Eventos de los controles de servidor
Los controles de servidor son aquellos elementos que
introducimos en
nuestros Web Forms y pueden lanzar acciones, e.g. botones, listas,
áreas de texto, etc. Si hemos trabajado antes con ellos
seguro
que nos vendrá a la mente el hecho de su variedad en
función de sus propósitos y acciones que se
permiten al
usuario. Es por esto que los eventos, concretando este razonamiento,
han sido divididos en tres grupos:
- Eventos de envío. Son los eventos lanzados por
controles
que emiten un envío (post) al servidor de manera inmediata
para
procesar el Web Form. Por ejemplo al enviar un formulario pulsando
sobre el botón de aceptación. Estos controles
son:
Button, Link Button e Image Button. - Eventos de caché. Estos eventos se producen en
la vista y
serán procesados en el servidor cuando se envíe
la
información mediante un evento de envío. Por
ejemplo el
seleccionar un elemento de una lista provoca un cambio de estado de la
misma que luego, en servidor, podremos obtener. Controles con eventos
de caché son TextBox, DropDownList, CheckBox… - Eventos de validación. Son los eventos que se
procesan
dentro de la página web. El ejemplo típico es la
validación de que un campo de entrada está
vacío o
no cuando es obligatorio, usando capacidades de validación
del
propio componente.
En el ciclo de vida de un Web Form se aplica el siguiente algoritmo de
manejo de eventos:
- Los controles con validación hacen las
validaciones en el
propio cliente antes de que la página sea enviada al
servidor
(se ha tenido que producir un evento de envío previamente). - La página se envía y se suceden los
eventos
Page_Init y Page_Load. Se procesan los eventos cacheados por orden
temporal y finalmente se procesa el evento de envío. - Nuestra lógica de negocio realiza las acciones
pertinentes con los controles.
Orden de los eventos de
los controles de servidor; 1º:
validación, 2º: cache, 3º:
envío.
Vamos a utilizar los eventos de Web Form y de controles en
otro ejemplo. Conforme a la imagen anterior, tenemos un Web Form con
dos campos de texto Nombre y Apellidos. Ambos son obligatorios y
decidimos controlarlo en la propia página (con un
componente RequiredFieldValidator). Una vez todo es correcto, se hace
la request y en servidor mostramos la secuencia de manejo de eventos.
La primera imagen muestra una pulsación del
botón Enviar con los campos obligatorios vacíos.
el propio navegador gestiona los eventos de validación y se
omite la request:
Lo mismo ocurre si dejamos un campo vacío y
pretendemos hacer el envío:
Finalmente introducimos los dos campos y obtenemos por
pantalla el orden por el que el sevidor maneja los eventos del Web Form:
El código para
esto es simple y se aloja en la clase C# events_page.aspx.cs asociado
al Web Form events_page.aspx:
|
private void btnEnviar_Click(object { Response.Write(«[Servidor] Procesando } private void { Response.Write(«[Servidor] Procesando }
private void { Response.Write(«[Servidor] Procesando } |
Conclusiones
Un buen desarrollo web con .NET comienza dominando la
teoría
de los eventos de nuestra aplicación, saber cuales son,
donde se
procesan y cómo podemos manejarlos en nuestra
lógica
programada. Los eventos son la interfaz
aplicación/programador
que permiten desarrollos rápidos de aplicaciones,
característica esencial del framework .NET.
En Autentia no dejamos de lado estas
tecnologías; las estudiamos, las aplicamos a nuestros
proyectos y, como siempre, compartimos la información
con vosotros. Deseamos que esto resulte útil para
favorecer el desarrollo de software con calidad.
