Modelo de eventos de control de servidor ASP.NET
Los eventos producidos por los controles de servidor ASP.NET trabajan de manera diferente a los eventos en los formularios de cliente tradicionales o en aplicaciones Web basadas en cliente. La diferencia se basa principalmente en la separación existente entre el propio evento y el lugar donde se controla el evento.
En las aplicaciones basadas en cliente, los eventos se producen y controlan en el cliente. En las páginas de formularios Web Forms, los eventos asociados a los controles de servidor se producen en el cliente, pero son controlados en el servidor Web por el marco de trabajo de página ASP.NET.
Para los eventos que se producen en el cliente, el modelo de control de eventos de formularios Web Forms necesita que la información del evento se capture en el cliente y que se transmita un mensaje de evento al servidor mediante un envío HTTP. EL marco de trabajo de la página debe interpretar el envío para determinar el evento ocurrido y, a continuación, llamar al método apropiado del código del servidor para controlar dicho evento. Para obtener más información, vea Eventos en controles de servidor de ASP.NET.
El modelo de control de eventos de formularios Web Forms
.gif)
ASP.NET controla virtualmente todos los mecanismos para capturar, transmitir e interpretar el evento. Cuando crea controladores de eventos en una página de formularios Web Forms, no necesita conocer los mecanismos utilizados para capturar la información del evento y que esté disponible para el código. Puede crear controladores de eventos casi de la misma forma que en un formulario de cliente tradicional. Aún así, hay diversos aspectos del control de eventos en páginas de formularios Web Forms que se deben tener en cuenta.
Conjunto de eventos intrínsecos
Debido a que los eventos de formularios Web Forms requieren una acción de ida y vuelta al servidor para procesarse, pueden afectar al rendimiento del formulario. Por lo tanto, los controles de servidor ofrecen un conjunto limitado de eventos intrínsecos, normalmente sólo de tipo clic. Algunos controles de servidor admiten una versión especial del evento onchange, provocado cuando cambia el valor del control. Por ejemplo, el control CheckBox de servidor Web produce un evento de cambio cuando el usuario hace clic en la casilla. Los eventos que tienen lugar con frecuencia (y que pueden provocarse sin que el usuario lo sepa), como por ejemplo onmouseover, no se admiten en controles de servidor.
**Nota **Algunos controles de servidor admiten un conjunto de eventos de más alto nivel. Por ejemplo, el control de servidor Web Calendar provoca un evento SelectionChanged que consiste en una versión más abstracta del evento Click.
Argumentos de eventos
Los eventos de los controles de servidor Web y HTML siguen un modelo de .NET Framework estándar para métodos controladores de eventos. Todos los eventos pasan dos argumentos: un objeto que representa al objeto que ha provocado el evento, y un objeto evento que contiene la información específica del evento. El segundo argumento suele ser de tipo System.EventArgs, pero para algunos controles es de un tipo específico de dicho control. Por ejemplo, para un control ImageButton de servidor Web, el segundo argumento es de tipo ImageClickEventArgs, que incluye información sobre las coordenadas donde el usuario ha hecho clic.
Eventos Postback y Non-Postback en controles de servidor Web
En los controles de servidor Web, algunos eventos, generalmente los eventos Click, hacen que el formulario sea devuelto al servidor. Los eventos de cambio en los controles de servidor HTML y Web, como el control TextBox, se capturan pero no se envían inmediatamente. En lugar de ello, el control los almacena en memoria caché hasta la próxima vez que se produzca un envío. A continuación, cuando se procesa de nuevo la página en el servidor, se producen y procesan todos los eventos pendientes.
Nota Si el explorador lo admite, los controles de validación pueden comprobar la introducción de datos por el usuario mediante secuencias de comandos de cliente sin acciones de ida y vuelta al servidor. Para obtener más detalles, vea Introducción a la validación de los datos insertados por el usuario en formularios Web Forms.
Durante el procesamiento de la página en el servidor, se procesan primero los eventos, sin ningún orden en particular. Cuando se han procesado todos los eventos de cambio, se procesa el evento Click que causó el envío del formulario.
**Nota **No debería crear lógica de aplicación donde los eventos de cambio deban producirse en un orden específico a no ser que tenga un conocimiento detallado del procesamiento de eventos de página. Para obtener más información, vea Ejemplo del evento Postback.
Puede especificar si un evento de cambio produce el envío del formulario. Los controles de servidor Web que admiten un evento de cambio incluyen la propiedad AutoPostBack. Cuando esta propiedad está establecida en true, el evento de cambio del control provoca el envío inmediato del formulario, sin esperar un evento clic. Por ejemplo, de forma predeterminada, el evento CheckedChanged de un control CheckBox no provoca el envío de la página. Sin embargo, si se establece la propiedad AutoPostBack del control en true, se especifica que, tan pronto como el usuario haga clic en la casilla de verificación, la página se enviará al servidor para ser procesada.
Nota Para que la propiedad AutoPostBack funcione correctamente, el explorador del usuario deberá estar configurado para permitir la ejecución de secuencias de comandos. Ésta es la configuración predeterminada en la mayoría de casos. Sin embargo, algunos usuarios inhabilitan la ejecución de secuencias de comandos por razones de seguridad. Para obtener detalles, vea Controles de servidor ASP.NET y funciones del explorador.
Eventos en burbuja
Los controles de servidor Web como Repeater, DataList y DataGrid pueden contener controles de botón que a su vez produzcan eventos. Por ejemplo, cada fila de un control DataGrid puede contener uno o varios botones creados dinámicamente mediante plantillas.
En lugar de que cada botón provoque un evento individualmente, los eventos de los controles anidados se ejecutan en burbuja, es decir, se envían al contenedor. El contenedor produce por turnos un evento genérico con parámetros, denominado ItemCommand, que permiten saber qué control en concreto ha producido el evento original. Respondiendo a este evento único, puede ahorrarse tener que escribir controles de eventos individuales para cada control secundario.
El evento ItemCommand incluye los dos argumentos de evento estándar, un objeto que hace referencia al origen del evento y un objeto de evento que contiene información específica del evento.
Nota Los controles de servidor Web DataGrid y DataList admiten eventos adicionales, como por ejemplo EditCommand, DeleteCommand y UpdateCommand, que son casos especiales de eventos en burbuja.
En el caso de botones, se puede utilizar la propiedad CommandArgument para pasar una cadena especificada por el usuario al controlador de eventos, para ayudar a identificar el botón que ha provocado el evento. Por ejemplo, en un control DataList, los botones provocan el evento ItemCommand. Se puede establecer la propiedad CommandArgument de cada botón en un valor distinto (por ejemplo, el valor de un botón puede ser "ShowDetails" y "AddToShoppingCart" el de otro botón), y más adelante capturar dichos valores en el controlador de eventos.
Delegados de eventos en páginas de formularios Web Forms
Un evento es un mensaje; en realidad, algo parecido a "se ha hecho clic en un botón". En una aplicación, se desea traducir el mensaje a una llamada a un método del código, como por ejemplo "Button1_Click". El enlace entre el mensaje del evento y un método específico (es decir, un controlador de evento) se lleva a cabo mediante un delegado de evento. Para obtener más información, vea Eventos y delegados.
En páginas de formularios Web Forms, no suele ser necesario crear del código de los delegados de forma explícita. Si se utiliza el Diseñador de Web Forms en Visual Studio, el diseñador genera el código que enlaza automáticamente los eventos con los métodos. En Visual Basic, esto se lleva a cabo mediante la palabra clave Handles en la declaración del controlador del evento, como se ve en este ejemplo:
Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
En Visual C#, el diseñador genera un delegado de controlador de eventos explícito en la página, similar al siguiente:
private void InitializeComponent()
{
this.Load += new System.EventHandler(this.Page_Load);
}
Como alternativa, el marco de trabajo de la página ASP.NET admite también una forma automática de asociar eventos de página con métodos. Si el atributo AutoEventWireup de la directiva Page se establece en true (o si falta, ya que es true de forma predeterminada), el marco de trabajo de la página llama de forma automática a los eventos de página, específicamente a los métodos Page_Init y Page_Load. En tal caso, no se necesita una cláusula Handles ni un delegado explícitos.
La desventaja del uso del atributo AutoEventWireup es que precisa que los controladores de eventos de la página tenga nombres específicos y predecibles. Esto limita la flexibilidad para asignar nombres a los controladores de eventos. Por tanto, en Visual Studio, el atributo AutoEventWireup se establece en false de forma predeterminada y el diseñador genera código explícito para enlazar los eventos con los métodos.
Si establece AutoEventWireup en true, Visual Studio generará código para enlazar los eventos, y el marco de trabajo de la página llamará a los eventos automáticamente según sus nombres. El resultado es que es posible que se llame dos veces al mismo código de evento cuando se ejecuta la página. En consecuencia, cuando trabaje con Visual Studio deberá dejar siempre el parámetro AutoEventWireup establecido en false.
Responder a eventos de cliente y de servidor en controles de servidor ASP.NET
En la mayoría de casos, los eventos de interés son aquellos que se provocan en el código del servidor. Sin embargo, si conviene para la aplicación, también se pueden controlar eventos de cliente para controles de servidor ASP.NET escribiendo secuencias de comandos de cliente.
Nota No se puede utilizar la sintaxis HTML para enlazar eventos de cliente para controles de servidor Web. En su lugar, se deben agregar al código atributos de enlace de eventos. Tiene un ejemplo en la tabla siguiente.
Por ejemplo, imagine que ha convertido un elemento de botón de imagen de HTML en un control de servidor HTML. Normalmente, en una página de formularios Web Forms controlaría el evento Click del botón de imagen en el código del servidor. Sin embargo, podría desear también usar código de cliente para cambiar la imagen cuando el usuario mueve el mouse (ratón) sobre ella. Puede hacerlo creando una secuencia de comandos de cliente para el evento onmouseover del botón de imagen. (En este ejemplo, se asume que está trabajando con un explorador compatible con HTML 4.0, como Microsoft Internet Explorer 4.0 o posterior).
**Nota **En el caso de que un controlador de eventos en el cliente tenga el mismo nombre que un controlador de eventos en el servidor, siempre se ejecutará primero el controlador de eventos en el cliente y después el controlador de eventos en el servidor. Sin embargo, este escenario puede producir confusión, por lo que se recomienda planear una convención de nombres.
Controlar un evento Clic en código de cliente y de servidor
Hay un evento determinado (el evento onclickdel cliente) que presenta una dificultad si se desea controlar en el cliente y en el servidor. El problema ocurre a causa de que todos los controles de botones del servidor (y otros controles cuya propiedad AutoPostBack está establecida en true) envían la página al servidor. Sin embargo, en HTML, sólo unos pocos controles envían un formulario de forma inherente:
- El botón enviar (submit) de HTML (
<INPUT type=submit>), que es el control HtmlInputButton con el tipo establecido en Submit o Image. Se puede agregar este control mediante la ficha HTML del Cuadro de herramientas. - El control Button de servidor Web (
<asp:button>).
En el caso de los demás controles especificados para el envío de la página, se agrega a ésta una breve secuencia de comandos de cliente, a la que se llama para enviar el formulario cuando se hace clic en el control. Por tanto, dichos controles ya utilizan el evento de cliente OnClick para llamar a la secuencia de comandos de envío.
Se pueden crear controladores de cliente OnClick para todos los controles, pero se debe elegir el enfoque que funciona con cada tipo de control. En la siguiente tabla se resumen las estrategias que se utilizan para los diversos tipos de controles.
| Control | Estrategia |
|---|---|
| HtmlInputButton, que incluye botones de control de servidor HTML, cuyo tipo se establece en Submit, Reset o Image | Incluir un atributo onclick en la sintaxis HTML del control:
En el servidor, los botones de este tipo provocan un evento ServerClick en lugar de un simple evento Click. El evento de cliente se provoca en primer lugar, y luego se envía el formulario y se controla el evento de servidor. |
| Los demás controles HTML (que no envían un formulario de forma predeterminada) | Incluir un atributo onclick en la sintaxis HTML del control, pero seguido de un punto y coma (;):
Esto hace que se llame a su función en primer lugar, antes de llamar a la secuencia de comandos de envío del cliente. |
Controles de servidor Web, incluidos los botones (<asp:button>) y otros controles (por ejemplo, <asp:checkbox>) |
La sintaxis HTML no permite especificar un evento de cliente para un control de servidor Web. En su lugar, se deberá agregar, en tiempo de ejecución, un atributo de evento al control en el código de servidor, utilizando un código similar a:
Nota Para el control Button de servidor Web, no es necesario agregar el punto y coma, porque dicho control envía la página de forma automática. |
Eventos de aplicación y de sesión
Aparte de los eventos de página y de control, el marco de trabajo de las páginas ASP.NET proporciona formas de trabajar con eventos que pueden provocarse al iniciarse o detenerse la aplicación, o cuando la sesión de usuario de un individuo determinado se inicia o se detiene:
- Los eventos de aplicación se provocan para todas las solicitudes que se hacen a una aplicación. Por ejemplo, Application_BeginRequest se provoca cada vez que se solicita una página de formulario Web Forms o un servicio Web XML de la aplicación. Este evento le permite inicializar recursos que se utilizarán para cada petición a la aplicación. Un evento correspondiente, Application_EndRequest, le proporciona la oportunidad de cerrar o eliminar los recursos utilizados por la petición.
- Los eventos de sesión son similares a los eventos de aplicación (existen los eventos Session_Start y Session_End), pero se producen con cada sesión dentro de la aplicación. Una sesión comienza cuando un usuario solicita una página por primera vez desde la aplicación y termina cuando la aplicación cierra explícitamente la sesión o cuando la sesión excede el tiempo de espera.
Se pueden crear controladores para estos tipos de eventos en el archivo Global.asax. Para obtener información detallada, vea Archivo Global.asax y Sintaxis de Global.asax.
Vea también
Control de eventos del servidor en páginas de formularios Web Forms | Archivo Global.asax | Introducción a la administración del estado de formularios Web Forms | Trabajar con instancias de Httpapplication