Controles de servidor

de Microsoft

ASP.NET 2.0 mejora los controles de servidor de muchas maneras. En este módulo, trataremos algunos de los cambios arquitectónicos en la forma en que ASP.NET 2.0 y Visual Studio 2005 tratan los controles de servidor.

ASP.NET 2.0 mejora los controles de servidor de muchas maneras. En este módulo, trataremos algunos de los cambios arquitectónicos en la forma en que ASP.NET 2.0 y Visual Studio 2005 tratan los controles de servidor.

Ver estado

El cambio principal en el estado de vista en ASP.NET 2.0 es una reducción drástica del tamaño. Considere una página con solo un control Calendar en ella. Este es el estado de vista en ASP.NET 1.1.

dDwtMTg1NDkwMjc0Nzt0PDtsPGk8MT47PjtsPHQ8O2w8aTwxPjs
+O2w8dDxAMDxwPHA8bDxTRDs+O2w8bDxTeXN0ZW0uRGF0ZVRpbWUsIG1
zY29ybGliLCBWZXJzaW9uPTEuMC41MDAwLjAsIEN1bHR1cmU9bmV1dHJ
hbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OTwyMDA1LTE
xLTA4Pjs+Oz4+Oz47Ozs7Ozs7Ozs7Pjs7Pjs+Pjs+Pjs+lkX2YWqfACtP
/VWr8G03pob/+tU=

Ahora se muestra el estado de vista en una página idéntica en ASP.NET 2.0.

/wEPDwULLTEzNjg5MjAxMzgPZBYCAgMPZBYCAgEPPCsAC
gEADxYCHgJTRBYBBgDAEX8OsscIZGRkllfArINjlhvzQX7Xfign2q6HK5E=

Es un cambio bastante significativo y, teniendo en cuenta que el estado de vista se lleva hacia atrás y hacia delante sobre la conexión, este cambio puede dar a los desarrolladores un aumento significativo del rendimiento. La reducción del tamaño del estado de vista se debe en gran medida a la forma en que la controlamos internamente. Recuerde que el estado de la vista es una cadena codificada en Base64. Para comprender mejor el cambio en el estado de vista en ASP.NET 2.0, echemos un vistazo a los valores descodificados de los ejemplos anteriores.

Este es el estado de vista 1.1 descodificado:

t<-1854902747;t<;l<i<1>;>;l<t<;l<
i<1>;>;l<t<@0<p<p<l<SD;>;l<l<
System.DateTime, mscorlib, Version=1.0.5000.0, Culture=neutral, 
PublicKeyToken=b77a5c561934e089<2005-11-08>;>;>>;
>;;;;;;;;;;>;;>;>>;>>;>Eaj

Esto puede parecer un poco como gibberish, pero hay un patrón aquí. En ASP.NET 1.x, usamos caracteres únicos para identificar tipos de datos y valores delimitados mediante los <> caracteres. El "t" del ejemplo de estado de vista anterior representa un triplete. El triplete contiene un par de ArrayLists (el "l" representa un ArrayList). Uno de esos ArrayLists contiene un Valor Int32 ("i") con un valor de 1 y el otro contiene otro Triplet. El triplete contiene un par de ArrayLists, etc. Lo importante que hay que recordar es que usamos triples que contienen pares, identificamos los tipos de datos a través de una letra y usamos los < caracteres y > como delimitadores.

En ASP.NET 2.0, el estado de vista descodificado tiene un aspecto un poco diferente.

-1368920138 d 
 d 
 
 
 SD 
 dddWc A ('ڮ

Debería observar un gran cambio en la apariencia del estado de vista descodificado. Este cambio tiene varios fundamentos arquitectónicos. El estado de vista en ASP.NET 1.x usó LosFormatter para serializar los datos. En la versión 2.0, usamos la nueva clase ObjectStateFormatter. Esta clase se diseñó específicamente para ayudar en la serialización y deserialización del estado de vista y el estado de control. (El estado de control se tratará en la sección siguiente). Hay muchas ventajas adquiridas cambiando el método por el que tienen lugar la serialización y la deserialización. Uno de los más dramáticos es el hecho de que, a diferencia de LosFormatter que usa TextWriter, ObjectStateFormatter usa BinaryWriter. Esto permite que ASP.NET 2.0 almacene el estado de vista una serie de bytes en lugar de cadenas. Por ejemplo, un entero. En ASP.NET 1.1, un entero requería 4 bytes de estado de vista. En ASP.NET 2.0, ese mismo entero solo requiere 1 byte. Se realizaron otras mejoras para reducir la cantidad de estado de vista que se almacena. Los valores DateTime, por ejemplo, ahora se almacenan mediante TickCount en lugar de una cadena.

Como si todo eso no fuera suficiente, se prestaba especial atención al hecho de que uno de los mayores consumidores del estado de vista en 1.x era DataGrid y controles similares. Un inconveniente importante de los controles, como DataGrid, en el que se refiere al estado de vista, es que a menudo contiene grandes cantidades de información repetida. En ASP.NET 1.x, esa información repetida simplemente se almacenó sobre y de nuevo, lo que da lugar a un estado de vista sobredimensionado. En ASP.NET 2.0, usamos la nueva clase IndexedString para almacenar dichos datos. Si se repite una cadena, solo almacenamos el token para IndexedString y el índice dentro de una tabla en ejecución de objetos IndexedString.

Estado de control

Una de las principales gripes que los desarrolladores tenían con el estado de vista era el tamaño que agregó a la carga HTTP. Como se mencionó anteriormente, uno de los mayores consumidores del estado de vista es el control DataGrid. Para evitar grandes cantidades de estado de vista generados por DataGrid, muchos desarrolladores simplemente deshabilitan el estado de vista para ese control. Desafortunadamente, esa solución no siempre era una buena. El estado de vista de ASP.NET 1.x no solo contiene los datos necesarios para la funcionalidad correcta del control. También contiene información sobre el estado de la interfaz de usuario del control. Esto significa que si quiere permitir la paginación en DataGrid, debe habilitar el estado de vista aunque no necesite toda la información de la interfaz de usuario que contiene el estado de vista. Es un escenario de todo o nada.

En ASP.NET 2.0, el estado de control resuelve ese problema de forma agradable a través de la introducción del estado de control. El estado de control contiene los datos absolutamente necesarios para la funcionalidad adecuada de un control. A diferencia del estado de vista, el estado de control no se puede deshabilitar. Por lo tanto, es importante que los datos que se almacenan en estado de control se controlen cuidadosamente.

Nota:

El estado de control se conserva junto con el estado de vista en el campo de formulario oculto __VIEWSTATE.

Este vídeo es un tutorial de estado de vista y estado de control.

Screenshot of the walkthrough video that describes the view state and control state fields, showing a Windows Explorer browser window.

Abrir vídeo en pantalla completa

Para que un control de servidor lea y escriba en el estado de control, debe realizar tres pasos.

Paso 1: Llamar al método RegisterRequiresControlState

El método RegisterRequiresControlState informa ASP.NET que un control debe conservar el estado de control. Toma un argumento de tipo Control, que es el control que se está registrando.

Es importante tener en cuenta que el registro no persiste de la solicitud a la solicitud. Por lo tanto, se debe llamar a este método en cada solicitud si un control es conservar el estado de control. Se recomienda llamar al método en OnInit.

protected override void OnInit(EventArgs e) { Page.RegisterRequiresControlState(this); base.OnInit(e); }

Paso 2: Invalidar SaveControlState

El método SaveControlState guarda los cambios de estado de control de un control desde la última publicación. Devuelve un objeto que representa el estado del control.

Paso 3: Invalidar LoadControlState

El método LoadControlState carga el estado guardado en un control. El método toma un argumento de tipo Object que contiene el estado guardado para el control.

Cumplimiento completo de XHTML

Cualquier desarrollador web conoce la importancia de los estándares en las aplicaciones web. Para mantener un entorno de desarrollo basado en estándares, ASP.NET 2.0 es totalmente compatible con XHTML. Por lo tanto, todas las etiquetas se representan según los estándares XHTML en los exploradores que admiten HTML 4.0 o superior.

La definición DOCTYPE de ASP.NET 1.1 era la siguiente:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN

En ASP.NET 2.0, la definición DE DOCTYPE predeterminada es la siguiente:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Si lo desea, puede modificar el cumplimiento predeterminado de XHTML a través del nodo xhtmlConformance en el archivo de configuración. Por ejemplo, el siguiente nodo del archivo web.config cambiará el cumplimiento de XHTML a XHTML 1.0 Strict:

<xhtmlConformance mode="Strict" />

Si lo desea, también puede configurar ASP.NET para usar la configuración heredada que se usa en ASP.NET 1.x de la siguiente manera:

<xhtmlConformance mode="Legacy" />

Representación adaptable mediante adaptadores

En ASP.NET 1.x, el archivo de configuración contenía una sección <browserCaps> que rellenaba un objeto HttpBrowserCapabilities. Este objeto permitió a un desarrollador determinar qué dispositivo está realizando una solicitud determinada y representar el código de forma adecuada. En ASP.NET 2.0, el modelo ha mejorado y ahora usa la nueva clase ControlAdapter. La clase ControlAdapter invalida los eventos del ciclo de vida del control y controla la representación de controles en función de las funcionalidades del agente de usuario. Las funcionalidades de un agente de usuario específico se definen mediante un archivo de definición de explorador (un archivo con una extensión de archivo .browser) almacenado en la carpeta c:\windows\microsoft.net\framework\v2.0.****\CONFIG\Browser.

Nota:

La clase ControlAdapter es una clase abstracta.

Al igual que la sección <browserCaps> de 1.x, el archivo de definición del explorador usa una expresión regular para analizar la cadena del agente de usuario para identificar el explorador solicitante. Define funcionalidades concretas para ese agente de usuario. ControlAdapter representa el control a través del método Render. Por lo tanto, si invalida el método Render, no debe llamar a Render en la clase base. Si lo hace, puede hacer que la representación se produzca dos veces, una vez para el adaptador y una vez para el propio control.

Desarrollo de un adaptador personalizado

Puede desarrollar su propio adaptador personalizado heredando de ControlAdapter. Además, puede heredar de la clase abstracta PageAdapter en los casos en los que se necesita un adaptador para una página. La asignación de controles al adaptador personalizado se realiza a través del elemento <controlAdapters> en el archivo de definición del explorador. Por ejemplo, el siguiente XML de un archivo de definición de explorador asigna el control Menu a la clase MenuAdapter:

<controlAdapters> <adapter controlType="System.Web.UI.WebControls.Menu" adapterType="System.Web.UI.WebControls.Adapters.MenuAdapter" /> </controlAdapters>

Con este modelo, resulta bastante fácil que un desarrollador de controles se dirija a un dispositivo o explorador determinado. También es bastante sencillo para un desarrollador tener un control completo sobre cómo se representan las páginas en cada dispositivo.

Representación por dispositivo

Las propiedades de control de servidor de ASP.NET 2.0 se pueden especificar por dispositivo mediante un prefijo específico del explorador. Por ejemplo, el código siguiente cambiará el texto de una etiqueta en función del dispositivo que se use para examinar la página.

<asp:Label ID="lblBrowser" runat="server" Text="You are browsing from an unknown device." ie:Text="You are browsing from Internet Explorer." mozilla:Text="You are browsing from Firefox."> </asp:Label>

Cuando la página que contiene esta etiqueta se examina desde Internet Explorer, la etiqueta mostrará el texto que indica "Está navegando desde Internet Explorer". Cuando se explora la página desde Firefox, la etiqueta mostrará el texto "You are browseing from Firefox". Cuando se examine la página desde cualquier otro dispositivo, se mostrará "Está navegando desde un dispositivo desconocido". Cualquier propiedad se puede especificar mediante esta sintaxis especial.

Establecer el foco

ASP.NET desarrolladores de 1.x suelen preguntar sobre cómo establecer el foco inicial en un control determinado. Por ejemplo, en una página de inicio de sesión, resulta útil que el cuadro de texto Id. de usuario obtenga el foco cuando se cargue la página por primera vez. En ASP.NET 1.x, esto requiere escribir algún script del lado cliente. Aunque este script es una tarea trivial, ya no es necesario en ASP.NET 2.0 gracias al método SetFocus. El método SetFocus toma un argumento que indica el control que debe recibir el foco. Este argumento puede ser el identificador de cliente del control como una cadena o el nombre del control Server como un objeto Control. Por ejemplo, para establecer el foco inicial en un control TextBox denominado txtUserID cuando se cargue la página por primera vez, agregue el código siguiente a Page_Load:

if (!IsPostBack) {
    SetFocus(txtUserID);
}

o bien,

if (!IsPostBack) {
    SetFocus(txtUserID.ClientID);
}

ASP.NET 2.0 usa el controlador Webresource.axd (descrito anteriormente) para representar una función del lado cliente que establece el foco. El nombre de la función del lado cliente es WebForm_AutoFocus como se muestra aquí:

<script type="text/javascript"> <!-- WebForm_AutoFocus('txtUserID'); // --> </script>

Como alternativa, puede usar el método Focus para un control para establecer el foco inicial en ese control. El método Focus deriva de la clase Control y está disponible para todos los controles de ASP.NET 2.0. También es posible establecer el foco en un control determinado cuando se produce un error de validación. Esto se tratará en un módulo posterior.

Nuevos controles de servidor en ASP.NET 2.0

A continuación se muestran nuevos controles de servidor en ASP.NET 2.0. Veremos más detalles sobre algunos de ellos en módulos posteriores.

ImageMap Control

El control ImageMap permite agregar zonas activas a una imagen que puede iniciar una publicación o navegar a una dirección URL. Hay tres tipos de zonas activas disponibles; CircleHotSpot, RectangleHotSpot y PolygonHotSpot. Los puntos de acceso se agregan a través de un editor de colecciones en Visual Studio o mediante programación en el código. No hay ninguna interfaz de usuario disponible para dibujar zonas activas en una imagen. Las coordenadas y el tamaño o radio del punto de acceso deben especificarse mediante declaración. Tampoco hay ninguna representación visual de un punto de acceso en el diseñador. Si un punto de acceso está configurado para navegar a una dirección URL, la dirección URL se especifica a través de la propiedad NavigateUrl del punto de acceso. En el caso de un punto de acceso posterior, la propiedad PostBackValue permite pasar una cadena en el post back que se puede recuperar en el código del lado servidor.

Screenshot of the HotSpot Collection Editor screen being displayed over the Default dot A S P X file window.

Figura 1: Editor de colecciones de HotSpot en Visual Studio

BulletedList Control

El control BulletedList es una lista con viñetas que se puede enlazar fácilmente a los datos. La lista se puede ordenar (numerada) o no ordenar a través de la propiedad BulletStyle. Cada elemento de la lista se representa mediante un objeto ListItem.

Screenshot of the Bulleted List tasks dropdown menu over an unordered list, with the Choose Data Source option being hovered over.

Figura 2: Control BulletedList en Visual Studio

HiddenField Control

El control HiddenField agrega un campo de formulario oculto a la página, el valor de que está disponible en el código del lado servidor. Por lo general, se espera que el valor de un campo de formulario oculto permanezca sin cambios entre los backs posteriores. Sin embargo, es posible que un usuario malintencionado cambie el valor antes de volver a publicar. Si esto sucede, el control HiddenField generará el evento ValueChanged. Si tiene información confidencial en el control HiddenField y desea asegurarse de que permanece sin cambios, debe controlar el evento ValueChanged en el código.

Control FileUpload

El control FileUpload de ASP.NET 2.0 permite cargar archivos en un servidor web a través de una página de ASP.NET. Este control es bastante similar a la clase ASP.NET 1.x HtmlInputFile con algunas excepciones. En ASP.NET 1.x, se recomienda comprobar si la propiedad PostedFile es nula para determinar si tiene un buen archivo. El control FileUpload de ASP.NET 2.0 agrega una nueva propiedad HasFile que puede usar para el mismo propósito y es un poco más eficaz.

La propiedad PostedFile sigue estando disponible para acceder a un objeto HttpPostedFile, pero algunas de las funciones de HttpPostedFile ahora están disponibles intrínsecamente con el control FileUpload. Por ejemplo, para guardar un archivo cargado en ASP.NET 1.x, llame al método SaveAs en el objeto HttpPostedFile. Con el control FileUpload en ASP.NET 2.0, llamaría al método SaveAs en el propio control FileUpload.

Otro cambio significativo en el comportamiento 2.0 (y probablemente el cambio más significativo) es que ya no es necesario cargar todo el archivo cargado en la memoria antes de guardarlo. En 1.x, cualquier archivo que se cargó se guarda completamente en la memoria antes de escribirse en el disco. Esta arquitectura impide la carga de archivos grandes.

En ASP.NET 2.0, el atributo requestLengthDiskThreshold del elemento httpRuntime permite configurar cuántos kilobytes se mantienen en un búfer en memoria antes de escribirse en el disco.

IMPORTANTE: la documentación de MSDN (y la documentación en otra parte) especifica que este valor está en bytes (no kilobytes) y que el valor predeterminado es 256. El valor se especifica realmente en Kilobytes y el valor predeterminado es 80. Al tener un valor predeterminado de 80 000, nos aseguramos de que el búfer no termine en el montón de objetos grandes.

Control del asistente

Es bastante habitual encontrar ASP.NET desarrolladores que tienen dificultades para recopilar información en una serie de "páginas" mediante paneles o transferencias de página a página. Con más frecuencia que no, el esfuerzo es frustrante y consume mucho tiempo. El nuevo control Asistente resuelve los problemas al permitir pasos lineales y no lineales en una interfaz del asistente con la que los usuarios están familiarizados. El control Asistente presenta formularios de entrada en una serie de pasos. Cada paso es de un tipo determinado especificado por la propiedad StepType del control. Los tipos de paso disponibles son los siguientes:

Tipo de paso Explicación
Automático El asistente determina automáticamente el tipo de paso en función de su posición dentro de la jerarquía de pasos.
Start El primer paso, que a menudo se usa para presentar una instrucción introductoria.
Paso Un paso normal.
Finalizar El paso final, normalmente se usa para presentar un botón para finalizar el asistente.
Completo Presenta un mensaje que comunica el éxito o el error.

Nota:

El control Wizard realiza un seguimiento de su estado mediante ASP.NET estado de control. Por lo tanto, la propiedad EnableViewState se puede establecer en false sin perjuicio alguno.

Este vídeo es un tutorial del control Wizard.

Screenshot of a video walkthrough of the Wizard Control. The Server Controls screen with a Microsoft Visual Studio window is displayed.

Abrir vídeo en pantalla completa

Localizar el control

El control Localize es similar a un control Literal. Sin embargo, el control Localize tiene una propiedad Mode que controla cómo se representa el marcado que se agrega a él. La propiedad Mode admite los siguientes valores:

Modo Explicación
Transformación El marcado se transforma según el protocolo del explorador que realiza la solicitud.
Acceso directo El marcado se representa tal como está.
Codificación El marcado que se agrega al control se codifica mediante HtmlEncode.

Controles MultiView y View

El control MultiView actúa como un contenedor para los controles View y el control View actúa como contenedor (como un control Panel) para otros controles. Cada vista de un control MultiView se representa mediante un único control View. El primer control View de MultiView es la vista 0, la segunda es la vista 1, etc. Puede cambiar las vistas especificando ActiveViewIndex del control MultiView.

Control Sustitución

El control Sustitución se usa junto con ASP.NET almacenamiento en caché. En los casos en los que quiera aprovechar el almacenamiento en caché, pero tiene partes de una página que se deben actualizar en cada solicitud (es decir, partes de una página que están exentas del almacenamiento en caché), el componente sustitución proporciona una excelente solución. El control no representa realmente ninguna salida por sí sola. En su lugar, se enlaza a un método en el código del lado servidor. Cuando se solicita la página, se llama al método y el marcado devuelto se representa en lugar del control de sustitución.

El método al que está enlazado el control De sustitución se especifica a través de la propiedad MethodName. Ese método debe cumplir los siguientes criterios:

  • Debe ser un método estático (compartido en VB).
  • Acepta un parámetro de tipo HttpContext.
  • Devuelve una cadena que representa el marcado que debe reemplazar el control de la página.

El control Sustitución no tiene la capacidad de modificar ningún otro control de la página, pero tiene acceso al HttpContext actual a través de su parámetro.

GridView Control

El control GridView es el reemplazo del control DataGrid. Este control se tratará con más detalle en un módulo posterior.

DetailsView Control

El control DetailsView permite mostrar un único registro de un origen de datos y editarlo o eliminarlo. Se trata con más detalle en un módulo posterior.

FormView Control

El control FormView se usa para mostrar un único registro de un origen de datos en una interfaz configurable. Se trata con más detalle en un módulo posterior.

AccessDataSource Control

El control AccessDataSource se usa para enlazar datos a una base de datos de Access. Se trata con más detalle en un módulo posterior.

ObjectDataSource Control

El control ObjectDataSource se usa para admitir una arquitectura de tres niveles para que los controles se puedan enlazar a datos a un objeto de negocio de nivel intermedio, en lugar de un modelo de dos niveles donde los controles se enlazan directamente al origen de datos. Se analizará con más detalle en un módulo posterior.

Control XmlDataSource

El control XmlDataSource se usa para enlazar datos a un origen de datos XML. Se trata con más detalle en un módulo posterior.

SiteMapDataSource Control

El control SiteMapDataSource proporciona enlace de datos para controles de navegación del sitio basados en un mapa de sitio. Se analizará con más detalle en un módulo posterior.

El control SiteMapPath

El control SiteMapPath muestra una serie de vínculos de navegación a los que se suele denominar rutas de navegación. Se trata con más detalle en un módulo posterior.

El control Menú muestra menús dinámicos mediante DHTML. Se trata con más detalle en un módulo posterior.

TreeView (Control)

El control TreeView se usa para mostrar una vista jerárquica de árbol de datos. Se trata con más detalle en un módulo posterior.

Control Login

El control Login proporciona un mecanismo para iniciar sesión en un sitio web. Se trata con más detalle en un módulo posterior.

Control LoginView

El control LoginView permite mostrar diferentes plantillas en función del estado de inicio de sesión de un usuario. Se trata con más detalle en un módulo posterior.

Control PasswordRecovery

El control PasswordRecovery se usa para recuperar contraseñas olvidadas por parte de los usuarios de una aplicación de ASP.NET. Se trata con más detalle en un módulo posterior.

LoginStatus

El control LoginStatus muestra el estado de inicio de sesión de un usuario. Se trata con más detalle en un módulo posterior.

LoginName

El control LoginName muestra el nombre de usuario de un usuario después de iniciar sesión en una aplicación de ASP.NET. Se trata con más detalle en un módulo posterior.

CreateUserWizard

CreateUserWizard es un asistente configurable que ofrece a los usuarios la posibilidad de crear una cuenta de pertenencia ASP.NET para usarla en una aplicación de ASP.NET. Se trata con más detalle en un módulo posterior.

ChangePassword

El control ChangePassword permite a los usuarios cambiar su contraseña para una aplicación de ASP.NET. Se trata con más detalle en un módulo posterior.

Varias WebParts

ASP.NET 2.0 se distribuye con varios elementos web. Estos se tratarán en detalle en un módulo posterior.