teoria_asp_Español

5/16/2018 teoria_asp_Espa ol - slidepdf.com

http://slidepdf.com/reader/full/teoriaaspespanol 1/160

ASP.NETMarco Antonio Peña Basurto Juan López Rubio



.



© Universitat Oberta de Catalunya 3 ASP.NET

Índice

Índice .................................................................................................... 3 Introducción ........................................................................................ 5 Objetivos ............................................................................................... 6 1. Aplicaciones para la Web y ASP.NET ............................................ 7

1.1. Introducción ...................................................................................... 7 1.2. Fundamentos de la Web .................................................................... 8 1.3. Aplicaciones Web ............................................................................ 10 1.4. ASP y ASP.NET ................................................................................. 12 1.5. Características de ASP.NET .............................................................. 13 1.6. Arquitectura de ASP.NET: modelos de código y ejecución .............. 15 1.7. Arquitectura de ASP.NET: modelo de proveedores .......................... 20 1.8. Espacios de nombres de ASP.NET .................................................... 22 1.9. ASP.NET y Windows Forms ............................................................. 23

2. Formularios Web (Web Forms) .................................................... 25 2.1. Interfaces para la Web ..................................................................... 25 2.2. Controles de servidor ...................................................................... 26 2.3. Diseño de interfaces ........................................................................ 32 2.4. Eventos ............................................................................................ 36 2.5. Acceso al flujo de HTML .................................................................. 40

3. Primera aplicación ASP.NET ........................................................ 42 3.1. Introducción .................................................................................... 42 3.2. Creación del proyecto ..................................................................... 43 3.3. Diseño de la interfaz ........................................................................ 44 3.4. Comportamiento de la interfaz ....................................................... 46 3.5. Pruebas y depuración ...................................................................... 47 3.6. Observaciones.................................................................................. 49

4. Procesamiento de formularios ..................................................... 50 4.1. Ciclo de vida de una página Web Forms ......................................... 50 4.2. Formularios HTML y Web Forms .................................................... 53 4.3. Validación de datos ......................................................................... 56 4.4. Enlace a datos (Data Binding) ......................................................... 64

5. Aplicaciones Web .......................................................................... 68 5.1. Aplicaciones Web ASP.NET ............................................................. 68 5.2. El archivo Global.asax ..................................................................... 70 5.3. Gestión del estado ........................................................................... 73 5.4. Gestión del estado en la práctica ..................................................... 77 5.5. Configuración de la aplicación ........................................................ 85

6. Seguridad ....................................................................................... 91 6.1. Autenticación y autorización .......................................................... 91 6.2. Seguridad y el modelo de proveedores ............................................ 98 6.3. Herramienta de configuración de la seguridad .............................. 101




6.4. Controles de Login ........................................................................ 102 6.5. API de pertenencia a grupo ........................................................... 108

7. Diseño de la interfaz de usuario ................................................ 110 7.1. Controles personalizados .............................................................. 110 7.2. Páginas maestras ............................................................................ 119 7.3. Temas visuales ............................................................................... 124 7.4. Web Parts....................................................................................... 129

I. Controles Web Forms : Referencia .............................................. 135 I.1. Generalidades ................................................................................. 135 I.2. La clase System.Web.UI.Control .................................................... 136 I.3. La clase System.Web.UI.WebControls.WebControl....................... 137 I.4. La clase System.Web.UI.Page ......................................................... 138 I.5. Controles HTML de servidor .......................................................... 140 I.6. Controles Web de servidor (Standard) ........................................... 142 I.7. Controles de validación de servidor ............................................... 146 I.8. Controles de acceso a datos ........................................................... 147 I.9. Controles de login .......................................................................... 148 I.10. Controles de navegación ............................................................. 149 I.11. Controles Web Part ...................................................................... 149

II. Instalación del servidor Web IIS ............................................... 152 II.1. IIS y ASP.NET en Windows XP Profesional ................................... 152 II.2. IIS y ASP.NET en Windows 2003 Server ........................................ 155 II.3. Alternativas a IIS ........................................................................... 157

Actividades ....................................................................................... 158 Bibliografía ...................................................................................... 160




Introducción

Aunque ASP.NET toma su nombre de la anterior tecnología de Microsoft

para el desarrollo Web, ASP, la nueva plataforma .NET difiere considerable-

mente. ASP.NET está construida completamente sobre el Common Language

Runtime (CLR), hecho compartido por todos los componentes de la plata-

forma .NET. Esto permite a los desarrolladores la construcción de aplicacio-

nes usando cualquiera de los lenguajes soportados por el .NET Framework,

como Visual Basic .NET, JScript .NET, C#, etc., pero también usando lengua-

jes como Perl o Python. Al contrario que otras tecnologías basadas en código

de script, ASP.NET ofrece un rendimiento mejorado, puesto el código de

servidor se precompila en forma de DLLs en el servidor Web.

ASP.NET simplifica la transición de los programadores acostumbrados al

desarrollo para Windows hacia el desarrollo Web, puesto que permite la

creación de páginas Web a partir de controles y eventos de forma similar a

como se construye una interfaz Windows tradicional. Sin embargo, así como

un control Windows se dibuja a sí mismo en la pantalla, los controles Web

generan segmentos de código HTML que se incrustan en las páginas que el

servidor envía al navegador del cliente.

El amplio conjunto de controles, clases y herramientas disponibles, propor-ciona una alta productividad en el desarrollo para la Web y especialmente en

lo que respecta a la generación de la interfaz de usuario. Otros aspectos, co-

mo el acceso a bases de datos, también están ampliamente integrados con

ASP.NET, facilitando así el desarrollo de aplicaciones Web empresariales que

visualicen datos provenientes de diversas fuentes.

Este tema explora todos estos aspectos, incluyendo las novedades de la ver-

sión 2.0, con el enfoque puesto en lo relativo a la generación de interfaces de

usuario. Así pues, inicialmente se introducen los conceptos básicos y se crea

una aplicación de ejemplo. A continuación se dedica buena parte del texto a

la comprensión de los mecanismos fundamentales en los que se asienta la

ejecución de las aplicaciones. Al tiempo, se proponen actividades comple-

mentarias sobre la aplicación base que permiten poner en práctica los con-

ceptos expuestos. A lo largo de todo el texto, numerosos ejemplos permiten

asimilar los contenidos de forma progresiva.




Objetivos

Algunos de los objetivos fundamentales que deben alcanzarse al completar

este tema pueden resumirse en:

Reforzar algunos conceptos básicos relativos a la construcción de aplica-

ciones para la Web.

Asimilar el concepto de control de servidor y los aspectos relacionados

como la gestión de eventos.

Comprender el concepto de Round trip.

Ser capaces de implementar mecanismos de validación de datos.

Comprender los mecanismos de gestión del estado en una aplicaciónASP.NET.

Ser capaces de implementar controles de usuario y controles personaliza-

dos básicos.

Ser capaces de configurar adecuadamente lo fundamental en una aplica-

ción ASP.NET.

Ser capaces de implementar mecanismos sencillos de autenticación y

autorización de usuarios.

Aprender a utilizar los espacios de nombres más importantes de ASP.NET

mediante C#.

Desarrollar una aplicación sencilla de ejemplo.




1. Aplicaciones para la Web y ASP.NET

El objetivo de este apartado es situar los contenidos del módulo en un con-

texto más global, el de la Web y el desarrollo de aplicaciones para la Web.

Por ello, antes de introducir la tecnología ASP.NET se revisan algunas nocio-

nes fundamentales y se establece el vocabulario a emplear en adelante.

1.1. Introducción

La World Wide Web (WWW) fue creada originalmente con el objetivo de

facilitar la transferencia de documentos (estáticos) y su navegación mediante

el uso de enlaces entre sí. Así, el lenguaje HTML permitió la construcción dehiper-documentos que incluían texto, imágenes y enlaces (hiperenlaces) a

otros documentos. Poco tiempo después los documentos dejaron de ser está-

ticos para pasar a auto-modificarse mientras el usuario interaccionaba con

ellos. El así llamado HTML dinámico (DHTML) incluye, no sólo HTML, sino

también porciones de programa que ejecuta el navegador del usuario para

generar el código HTML que finalmente se visualiza. Algunas tecnologías

remarcables en dicho ámbito incluyen JavaScript, Flash de Macromedia,

applets de Java, etc.

Al margen del intercambio de documentos, ya desde su origen, la infraes-tructura de la WWW ha servido también como plataforma para facilitar la

ejecución de aplicaciones. En ese sentido destacan dos grandes familias: los

CGI y las páginas de servidor.

Mediante CGI (Common Gateway Interface ) se puede crear una interfaz que

comunica el servidor de páginas Web con aplicaciones convencionales. Así

ante una solicitud al servidor Web, éste puede ejecutar una aplicación que

genere las páginas Web correspondientes como respuesta. Este tipo de pro-

gramas puede escribirse en cualquier lenguaje de programación, siendo algu-

no de los más habituales C o Perl, por lo que los CGI suelen orientarse más a

programadores que a diseñadores de páginas Web.

Las páginas de servidor se denominan así puesto que cuando un usuario las

solicita a través de su navegador, el servidor no las devuelve directamente,

tal como haría con una página HTML convencional. Sin embargo, somete las

páginas a un procesado previo, ejecutando en el propio servidor el código

incrustado en dichas páginas. Así pues este tipo de páginas consisten en una

mezcla de HTML con código que debe compilarse o interpretarse en el pro-

pio servidor, para que éste genere la página completa antes de devolverla alusuario. Destacan en este ámbito tecnologías como JSP de Java, PHP o ASP

de Microsoft.

JavaScript es un lenguaje descript orientado a objetosmuy usado en la construcciónde páginas Web para acceder dinámicamente a los objetosque forman una página.




Pongamos un poco más de propiedad en todo este mar de acrónimos.

1.2. Fundamentos de la Web

La Web se fundamenta en el uso de tres estándares. Las URL (Uniform Re-

source Locator ), que especifican una forma de otorgar una “dirección” única

a una página Web. El protocolo HTTP (Hyper Text Transfer Protocol ), que

especifica la manera en que el navegador y el servidor se envían información

mutuamente. Y el lenguaje HTML (Hyper Text Markup Language ), que pro-

porciona un método para codificar la información de los documentos de

forma que pueda visualizarse en una gran variedad de dispositivos. Aunque

las compañías que producen programas y contenidos para la Web respetan

dichos estándares mayoritariamente, el W3C (World Wide Web Consortium )

es el organismo encargado de mantener actualizados estos y otros estándarespara que la comunicación el Web sea efectiva. La Figura 1 muestra la relación

entre todos estos elementos.

URLs

De forma sencilla, una URL es la dirección que escribimos en el navegador

Web para conectarnos a un sitio Web, e.g. http://www.uoc.edu . Una URL

consta de cuatro partes que detallamos a continuación.

Protocolo: Especificado mediante el texto anterior a los dos puntos, e.g.

HTTP, HTTPS, FTP, TELNET, etc. El protocolo indica al navegador qué ti-

po de servicio usar para conectar con el servidor deseado. Si no se especi-

fica ninguno, el navegador asume deseamos conectar con un servidor

Web y por lo tanto asume que se trata del protocolo HTTP.

Servidor de destino: Por ejemplo, en http://www.uoc.edu, www.uoc.edu

es el servidor de destino.

Figura 1. Anatomía de una aplicación Web.

Servidor Web

PC/Mac/Unix/...

+ NavegadorCliente

Servidor

Solicitud:

http://www.digimon.com

Respuesta:

<html>….</html>

RedTCP/IP, HTTP, HTML

http://en.wikipedia.org/wiki/World_Wide_Web_Consortium



http://www.uoc.edu/

http://www.uoc.edu/

http://www.uoc.edu/

http://www.uoc.edu/

http://www.uoc.edu/

http://www.uoc.edu/

http://www.uoc.edu/

http://www.uoc.edu/

http://www.uoc.edu/





Número de puerto: Permite indicar a qué puerto concreto del servidor de

destino debe encaminarse la conexión. Por ejemplo, en

http://www.uoc.edu:80 se especifica el puerto 80. Si no se especifica ningún

puerto, el navegador usará el puerto 80 que es el puerto usado por defecto

por el protocolo HTTP.

Ruta: Especifica la ruta en el servidor hasta el archivo que deseamos visua-

lizar. En la URL http://www.uoc.edu/web/cat/index.html, por ejemplo, la ru-

ta /Web/cat/index.html indica que queremos visualizar el contenido del

documento index.html alojado en el subdirectorio cat del directorio Web.

HTTP

HTTP es un protocolo sencillo del tipo solicitud-respuesta entre clientes y

servidores. El cliente típico de HTTP, un navegador Web, inicia una solicitud

estableciendo una conexión en el puerto 80 (por defecto) del servidor. Un

proceso que “escucha” en el puerto 80 del servidor HTTP ident ifica el tipo desolicitud y responde en consecuencia, con un mensaje de error o con el con-

tenido del documento solicitado. Una conversación típica entre un navega-

dor y un servidor Web en www.example.org tendría un aspecto como el si-

guiente. A la respuesta le seguiría el texto HTML de la página Web alojada en

el servidor.

HTML

HTML es el lenguaje usado por una página Web para dar formato al texto ylas imágenes que la componen. Es un lenguaje de texto puro basado en un

conjunto de códigos especiales (marcas) que indican al navegador cómo

aplicar el formato. Existen muchas marcas diferentes para especificar gran

cantidad de combinaciones de formato. Todas se componen de una marca

de inicio del formato y de una marca de final del mismo. Por ejemplo, po-

demos crear con nuestro editor de texto favorito un documento HTML, al

que podríamos llamar hola.html, con el siguiente contenido:

<b>Hola Mundo UOC!!!!</b>

Solicitud:GET / HTTP/1.1Host: www.example.org

Respuesta:HTTP/1.1 200 OKDate: Mon, 23 May 2005 22:38:34 GMTServer: Apache/1.3.27 (Unix) (Red-Hat/Linux)Last-Modified: Wed, 08 Jan 2004 22:11:55 GMTEtag: "3f80f-1b6-3e1cb03b" Accept-Ranges: bytesContent-Length: 438Connection: closeContent-Type: text/html

http://www.uoc.edu/

http://www.uoc.edu/

http://www.uoc.edu/web/cat/index.html



http://www.example.org/





http://www.uoc.edu/




Al abrir este documento con el navegador veríamos la frase escrita en negrita,

tal como indican las marcas de inicio (<b>) y fin de negrita (</b>).

Aunque ya hemos mencionado a navegadores y servidores Web en los párra-

fos anteriores, daremos aquí una definición más precisa. Diremos que un

navegador (browser ) Web es un programa capaz de interpretar un documen-

to HTML y visualizarlo en pantalla de acuerdo con las marcas que éste espe-

cifica. Existe gran variedad de navegadores Web, como Internet Explorer (IE),

Mozilla, Opera, Netscape, etc. Por su parte, un servidor Web es un ordena-

dor que almacena documentos HTML y permanece a la espera de conexiones

de los navegadores. Un programa, el servidor propiamente, se encarga de

atender las peticiones y retornar los documentos. Como servidores Web

podríamos citar Internet Information Services (IIS) o Apache, entre otros.

Con estos elementos, la así llamada, navegación por la Web sucede de lasiguiente forma. Cuando escribimos una URL en el navegador, éste intenta

conectar con el servidor indicado en la parte correspondiente de la URL. Si

consigue conectar, el navegador envía la ruta indicada en la URL. Si la ruta

existe en el servidor, éste devuelve el documento HTML al navegador, quien

la interpreta y finalmente visualiza.

1.3. Aplicaciones Web

Una aplicación Web es un programa distribuido a través de Internet o de una

red de área local y que los usuarios ejecutan a través de un navegador. En los

últimos años las aplicaciones Web se han vuelto muy populares debido a la

ubicuidad del navegador Web, a menudo llamado cliente-ligero (thin client ).

En el modelo tradicional cliente-servidor, cada aplicación requiere de un

programa cliente propio que debe instalarse independientemente en cada

ordenador desde donde quiera ejecutarse la aplicación. Las actualizaciones

en el servidor a menudo conllevan también actualizaciones en todos los

clientes, lo que sin duda es ineficiente y costoso.

Por el contrario, una aplicación Web genera la interfaz de usuario en forma

de un conjunto de páginas Web estándar. Aunque una página Web es técni-

camente un documento estático, una secuencia de páginas Web bien dis-

puestas proporcionan una sensación de interactividad muy próxima a la de

las aplicaciones convencionales. Así pues, una aplicación Web puede ejecu-

tarse desde cualquier ordenador que tenga un navegador instalado. Además

las actualizaciones sólo afectan al lado del servidor, el navegador cliente no

tiene por qué cambiar.

Actualmente es muy comúndotar a las aplicaciones deinterfaces Web.




Recientemente, hay una tendencia muy fuerte hacia la creación de interfaces

Web para todo tipo de aplicaciones. Esto incluye aplicaciones ya clásicas

como Webmail, buscadores, diccionarios on-line , etc. También aplicaciones

monousuario han cambiado a la filosofía basada en páginas Web. Por ejem-

plo, todos los sistemas de ayuda de aplicaciones y sistemas operativos de

Microsoft se basan en el uso de HTML, un mini-servidor Web incrustado en

el sistema y un componente navegador también incrustado. Finalmente,

otro ámbito de uso de las aplicaciones Web son las interfaces de configura-

ción de equipos de comunicaciones como switches , routers , puntos de acce-

so Wi-Fi, etc.

Aunque una aplicación Web puede construirse de diversas maneras, típica-

mente constan de tres capas:

La capa de interfaz de usuario, encargada del aspecto visual de la aplica-

ción y de la interacción con el usuario, está compuesta por las páginasHTML que el usuario solicita a un servidor Web y que visualiza en un na-

vegador Web.

La capa de lógica de negocio está compuesta por los módulos que imple-

mentan la lógica de la aplicación y que se ejecutan en un servidor de apli-

caciones. Esta capa suele tener la forma de un programa creado a partir de

alguna tecnología de generación de contenido Web dinámico, como

CGIs, PHP, Java Server Pages (JSP) o Active Server Pages (ASP).

La capa de datos está compuesto por los datos, normalmente gestionados

por un sistema de gestión de bases de datos (servidor de datos), que ma-

neja la aplicación Web.

En definitiva, las aplicaciones Web han pasado de ser simples extensiones de

un conjunto de páginas Web estáticas, a complejas aplicaciones desarrolladas

en base a muchas capas. Esto permite mayor adaptabilidad y robustez, im-

prescindibles para el desarrollo de técnicas de escalabilidad y balanceo de

carga, en aplicaciones que deban dar servicio a gran número de usuarios

simultáneamente.

Para concluir, cabe apuntar el hecho de que la programación de aplicaciones

Web presenta una serie de dificultades que no suelen darse en la programa-

ción de aplicaciones tradicionales.

Implementación de interfaces de usuario ricas . Una interfaz de usuario con

un layout complejo, gran cantidad de contenido dinámico, etc. puede ser

muy difícil de construir usando HTML. La dificultad se acentúa si lo que

queremos es que la interfaz de usuario pueda visualizarse en múltiples plata-

formas.

Separación entre cliente y servidor. El cliente (navegador) y el servidor son

programas diferentes, que se ejecutan en ordenadores diferentes y con siste-

Webmail se refiere genérica-mente a una aplicación Webque permite leer y enviar correo electrónico desde unnavegador.

Un servidor de aplicaciones es

un servidor Web con capaci-dad de procesamiento, por loque suele ser a la vez servidor Web y servidor de lógica denegocio.

Hablamos de layout en unainterfaz de usuario para des-cribir tanto el proceso comoel resultado mismo de posi-cionar y dimensionar losdiferentes elementos quecomponen la interfaz en elespacio de ventana o página Web destinado a ello.




mas operativos que también pueden ser diferentes. En consecuencia las dos

partes de la aplicación comparten muy poca información, i.e. pueden co-

municarse pero sólo intercambian pequeños bloques de datos.

Ejecución sin estado. Cuando un servidor recibe la solicitud de una página,

éste la busca, la procesa y la retorna al navegador cliente. Inmediatamente

después el servidor descarta toda información relacionada con la página

recién servida. Si el usuario solicita la misma página posteriormente, el servi-

dor repite el proceso desde cero. Dicho de otro modo, el servidor no tiene

memoria de las páginas que procesa. En consecuencia si una aplicación nece-

sita mantener información relacionada con una página, es la propia aplica-

ción quien debe encargarse de ello.

Desconocimiento de las capacidades de los navegadores. En muchos casos

las aplicaciones Web acaban siendo accedidas por usuarios que usan diversosnavegadores. Cada navegador tiene sus propias capacidades, lo que hace

complicado construir aplicaciones que se ejecuten igualmente bien en todos

ellos.

Problemas de escalabilidad. A menudo las aplicaciones Web fallan al enfren-

tarse al problema de la escalabilidad, para dar soporte a muchos usuarios o

para distribuirse en múltiples servidores, por ejemplo.

1.4. ASP y ASP.NET

Las siglas ASP (Active Server Pages ) se refieren a la tecnología de Microsoft

que permite que un servidor Web, además de alojar y servir páginas HTML,

ejecute código de script incrustado en dichas páginas. En particular el motor

de ASP funciona habitualmente sobre el servidor Web de Microsoft IIS (In-

ternet Information Services ), que se distribuye como componente del siste-

ma operativo Windows a partir de Windows 2000.

Un archivo ASP es básicamente un archivo HTML, pero puede contener

también código en forma de scripts . Dicho código se ejecuta siempre en el

servidor, no en el navegador del usuario. Así, cuando el navegador solicita

un archivo ASP, IIS no lo devuelve directamente sino que pasa la solicitud al

Los archivos ASP usan laextensión .asp

VBScript (Visual Basic Scrip-ting Edition) es un subconjun-to de Visual Basic usado en ASP, aunque también se usacomo lenguaje de script en

Windows.

<html><head><title>Ejemplo ASP</title>

</head><body>

<h1>ASP en la UOC</h1><%For H=1 To 5

Response.Write "<h" & H & ">Titulo de nivel " & H & "</h" & H & ">"Next %>

</body></html>

Figura 2. Ejemplo de página ASP.




motor de ASP. Este analiza el archivo y ejecuta el código en su interior, para

finalmente devolver como resultado un archivo HTML. En el ejemplo de la

Figura 2 podemos ver la sección de código script delimitada por las marcas

<% y %>. Se trata de código VBScript que se ejecuta en el servidor previa-

mente a la devolución de la página HTML. Si salvamos el código del ejemplo

usando cualquier editor de texto (como el bloc de notas de Windows, por

ejemplo) en un archivo con extensión .asp y posteriormente lo abrimos con

un navegador, veremos que el contenido que se visualiza no muestra el

código sino el resultado de su ejecución. Es más, si solicitamos al navegador

que nos muestre el código fuente de la página, lo que veremos será el archi-

vo HTML resultante de la ejecución del código, no el código en sí mismo.

La última versión de ASP es la 3.0, aunque nunca habrá una versión 4.0. Por

el contrario ASP.NET, originalmente conocida como ASP+, es la nueva gene-

ración de ASP, desarrollada completamente desde cero. No se trata de unanueva versión de ASP, sino de un nuevo paradigma en el desarrollo de apli-

caciones Web basadas en código de servidor sobre la plataforma .NET. No

existe compatibilidad completa con versiones anteriores, por lo que una

aplicación ASP debe sufrir algunas modificaciones para ejecutarse sobre

ASP.NET. Para que el servidor diferencie las aplicaciones implementadas con

esta nueva tecnología, los archivos de ASP.NET utilizan una nueva exten-

sión: .aspx. Como motor de proceso de páginas de servidor, ASP.NET es simi-

lar a otras tecnologías como PHP o JSP.

ASP.NET ofrece gran cantidad de características interesantes para los diseña-

dores y desarrolladores de aplicaciones Web, entre las que destacan el sopor-

te a múltiples lenguajes de programación, la programación orientada a even-

tos, componentes basados en XML, escalabilidad, alto rendimiento, etc. El

siguiente apartado detalla estos y otros aspectos.

1.5. Características de ASP.NET

ASP.NET proporciona una plataforma de desarrollo completamente integra-

da con el Framework de .NET, lo que permite la construcción sencilla deaplicaciones Web complejas en el servidor. ASP.NET se caracteriza por una

serie de ventajas y mejoras respecto a otras plataformas existentes. Sin ánimo

de ser exhaustivos:

Interfaz de usuario rica. Las aplicaciones ASP.NET pueden incluir en sus

páginas multitud de controles, tanto controles HTML que pueden manipu-

larse mediante scripts , como controles orientados a objetos para representar

datos de forma avanzada.

Independencia del navegador. ASP.NET posibilita que toda la lógica de laaplicación esté en el servidor, eliminado la necesidad de escribir código es-

pecífico para diversos navegadores. En todo caso, también posibilita que las

Los archivos ASP.NET usan laextensión .aspx

ASP sólo admite código escri-to en VBScritp y JScript.




aplicaciones se beneficien automáticamente de las capacidades específicas de

cada navegador, generando código cliente eficiente.

Soporte multi-lenguaje. Al estar integrado con el .NET Framework las pági-

nas ASP.NET pueden incluir código escrito en cualquiera de los lenguajes de

la plataforma, como C#, Visual Basic .NET, etc. y no simples lenguajes de

script . Al ser una componente más del .NET Framework, toda la potencia del

mismo es directamente accesible para los desarrolladores de aplicaciones

ASP.NET, por lo que no es necesario recurrir a librerías externas para generar

gráficos, acceder a bases de datos, trabajar con XML, etc.

Modelo de objetos consistente e intuitivo. El entorno de desarrollo de pági-

nas ASP.NET proporciona un modelo de objetos que permite al desarrollador

pensar en los formularios como un todo, y no como piezas separadas cliente

y servidor. Adicionalmente los controles de servidor aportan una abstracciónrespecto al contenido HTML de una página Web y respecto a la interacción

entre el navegador y el servidor. En general pueden usarse los controles de

servidor como si se usasen controles en una aplicación de escritorio tradicio-

nal, sin pensar en el código HTML necesario para mostrarlos y procesarlos.

Orientación a eventos. Web Forms aporta a la construcción de aplicaciones

Web el tradicional método de escritura de métodos para controlar y atender

a los eventos que se producen en la interfaz de usuario. Así, todos los objetos

de ASP.NET que pueden incluirse en una página son receptivos a eventos

que pueden procesarse mediante código .NET de una forma estructurada.

Gestión del estado de forma intuitiva. ASP.NET gestiona automáticamente

el estado de los formularios y los controles, además de proporcionar meca-

nismos explícitos par gestionar el estado de información específica de la

aplicación.

Autenticación y gestión de usuarios. ASP.NET soporta autenticación basada

en formularios, incluyendo gestión de cookies , redirección en caso de fallo

de autenticación, etc. Además permite la definición de perfiles de usuariopor aplicación, para proporcionar acceso a diferentes contenidos o ejecutar

diferente código en función del usuario.

Configuración y despliegue simplificados. Las aplicaciones se configuran

mediante archivos de texto planos que pueden modificarse aún con la apli-

cación en ejecución y sin necesidad de reiniciar el servidor Web. Las actuali-

zaciones en el código no requieren tampoco del reinicio del servidor pues

basta con cambiar el código y el servidor redirecciona las peticiones hacia el

nuevo código.

Rendimiento mejorado. El código en ASP.NET es compilado por lo que su

ejecución se beneficia de optimizaciones nativas y sistemas de cache , entre

Una aplicación ASP.NET tieneacceso a todos los servicios dela plataforma .NET




otros, para conseguir un mejor rendimiento. El código sólo se compila la

primera vez que es accedido, a diferencia de los entornos interpretados en los

que el código se analiza cada vez que es accedido. ASP.NET 2.0 soporta arqui-

tecturas de 64 bits, i.e. permite usar todo el espacio de direcciones de los

nuevos servidores. La migración a 64 bits puede ser tan sencilla como copiar

el código de 32-bits al servidor, dejar que el motor de ASP.NET 2.0 lo compi-

le y finalmente lo ejecute como una aplicación nativa de 64 bits. Sin cam-

bios en el código.

Escalabilidad. ASP.NET proporciona facilidades de comunicación entre ser-

vidores de forma que una aplicación compleja o muy solicitada puede distri-

buirse en granjas de servidores con muy pocos cambios en la lógica de la

aplicación.

Multiplataforma . Un inconveniente que suele achacarse a ASP.NET el hechode estar ligado a los sistemas Windows. Si bien esto es cierto, lo es a medias.

Existen actualmente diversos proyectos en desarrollo, como SSCLI/ROTOR

(http://msdn.microsoft.com/net/sscli/) o Mono (http://www.mono-project.com)

que permiten usar .NET, y por tanto ASP.NET, en otros sistemas operativos

como Linux, FreeBSD o Mac OS/X. Además, al margen de IIS, también puede

usarse Apache junto con Cassini como servidores Web para ASP.NET.

1.6. Arquitectura de ASP.NET: modelos de código y ejecución

Como ya hemos comentado previamente, una página de ASP.NET es un

documento de texto en el que se combinan contenidos en forma de marcas

de HTML o XHTML junto a porciones de código escrito en cualquiera de los

lenguajes de .NET. Así pues, la forma más simple de una página de ASP.NET

consistiría en tomar cualquier archivo HTML y cambiarle la extensión. La

Figura 3 muestra un ejemplo de página ASP.NET (equivalente al de la Figura

2). En ASP.NET es imprescindible la marca <%@ Page con el atributo Language,

ya que puede usarse cualquier lenguaje de .NET (C# en el ejemplo). Igual que

en ASP, el código se delimita entre las marcas <% y %>.

Aunque para este ejemplo concreto no es necesario, para que una aplicación

ASP o ASP.NET puede ejecutarse creando dinámicamente el contenido de la

Cassini es un servidor Web de

ejemplo programado con.NET y preparado para servir páginas ASP.NET

<%@ Page Language="C#" %><html>

<head><title>Ejemplo ASP .NET</title>

</head><body>

<h1>ASP .NET en la UOC</h1><%int H; for (H=1; H<=5; H++) { %>

<h<%=H%>>Titulo de nivel <%=H%> </h<%=H%>><%} %>

</body>

</html>

Figura 3. Ejemplo de página ASP.NET.

http://msdn.microsoft.com/net/sscli/



http://www.mono-project.com/








página respuesta, es necesario que los diferentes archivos que forman parte

de la aplicación se hallen en el lugar adecuado del servidor Web (véase el

Apéndice “Instalación del servidor Web IIS”). IIS, el servidor Web por defec-

to, atiende las peticiones del protocolo HTTP e invoca al motor de ASP.NET

en caso de que el documento solicitado sea un archivo .aspx. El motor ejecuta

el código incrustado en la página mediante las facilidades del .NET Frame-

work, lo que permite realizar tareas como acceder a bases de datos o ejecutar

algoritmos complejos. La Figura 4 ilustra este proceso a alto nivel.

Como se ha visto en el ejemplo de la Figura 3 una página ASP.NET puedecombinar el aspecto visual (marcas HTML) y la lógica de una aplicación (e.g.

código C#). El resultado es en general un archivo poco inteligible y difícil de

mantener. Lo recomendable es, como mínimo, separar ambas cosas median-

te la técnica denominada code-behind . Esta técnica consiste básicamente en

alojar en archivos separados el código HTML y la lógica de la aplicación. Así,

el código HTML se almacena en un archivo con extensión .aspx, mientras que

el código ejecutable se almacena en un archivo con extensión .aspx.cs, .aspx.vb,

etc. dependiendo del lenguaje de programación especificado (ver Figura 5).

Además se establece un vínculo entre la página .aspx y el código mediante los

atributos Codebehind e Inherits en la marca Page. La Figura 6 muestra cómo que-daría el código del ejemplo anterior empleando la técnica de code-behind . La

Figura 7 muestra el aspecto visual de la página Web resultante.

El archivo referenciado mediante el atributo Codebehind debe contener una

clase con el mismo nombre que el indicado por el atributo Inherits. El motor

de ASP.NET no abrirá el módulo de código fuente, sino que usará su nombre

como referencia para buscar una DLL que contenga la clase indicada. El atri-

buto Language hace referencia al lenguaje utilizado dentro del archivo .aspx,

no al lenguaje usado para implementar la citada DLL.

Figura 4. Arquitectura de ASP.NET.

Aplicación ASP.NET

.NET Framework

<HTML><script>… </script>

… </HTML>

Controles Web

HTTP

SGBD

ADO.NET

IIS

Windows

app.aspx




Archivo ASP.NET_UOC_cb.aspx

<%@ Page Language="C#" Codebehind="ASP.NET_UOC_cb.aspx.cs"Inherits="UOC.EjemploASPNET" %><html>

<head><title>Ejemplo ASP .NET con code behind</title>

</head><body>

<h1>ASP .NET en la UOC con code behind</h1></body>

</html>

Figura 6. Ejemplo de página ASP.NET con code-behind .

Archivo ASP.NET_UOC_cb.aspx.cs

using System;using System.Web;using System.Web.UI;

namespace UOC {public class EjemploASPNET : System.Web.UI.Page {

private void Page_Load (object sender, System.EventArgs e) {for (int H=1; H<=5; H++)

Response.Write("<h" + H + ">Titulo de nivel " + H + "</h" + H + ">");}

}}

Figura 7. Ejemplo de página ASP.NET con code-behind .: ejecución.

Figura 5. Modelo code-behind en ASP.NET.




En ASP.NET 2.0 y Visual Studio 2005 este modelo de separación de código e

interfaz ha evolucionado considerablemente. El nuevo modelo de separación

de código recibe el nombre de code-beside y se basa en el concepto de clase

parcial, nuevo en .NET 2.0, que permite que una misma clase esté definida

de forma parcial en múltiples archivos de código. De este modo se puede

definir parte de una clase en un archivo, algunas de sus propiedades en otro,

sus métodos en otro, etc. La principal utilidad de este modelo está enfocada

a herramientas de creación de código, para facilitar la regeneración de código

parcial de una clase y para que varios programadores puedan trabajar al

mismo tiempo en partes diferentes de una misma clase.

En las páginas ASP.NET 2.0, Visual Studio 2005 aprovecha esta característica

para definir parte de la clase de la página Web en el propio archivo .aspx, que

contiene definiciones de controles y eventos, y el código que gobierna su

funcionamiento en un archivo aparte por medio de una clase parcial. Esto secontrola desde los atributos de la directiva Page, de la siguiente forma:

La clase MiClase se define como una clase parcial (palabra clave partial en C# y

Expands en VB.NET) y contiene sólo el código que gobierna el funcionamien-

to de la página. La Figura 8 muestra el ejemplo Figura 6 pero esta vez imple-

mentado con la técnica de code-beside .

Las ventajas de este nuevo modelo de trabajo (por cierto, code-behind no

está soportado por VS.NET 2005, aunque existe un asistente de conversión)

son varias, y cabe destacar una mayor sencillez de código y una mayor sepa-

ración real entre interfaz y lógica de trabajo.

Si se usa la herramienta de desarrollo Visual Studio .NET para implementar la

aplicación, la vinculación entre las páginas ASP.NET y los módulos de código

se efectúa de forma automática y transparente para el programador. Además,

la aplicación se registra automáticamente en el servidor Web por lo que pue-

de ejecutarse directamente. Si para escribir el código no se usa Visual Studio.NET sino un editor de texto cualquiera, antes de poder ejecutar la aplicación

(como la de la Figura 6) debe compilarse el código para producir la corres-

pondiente DLL. Además deberá estar alojada en un subdirectorio llamado bin

dentro del directorio donde se encuentre el archivo .aspx.

En este punto cabe destacar la importancia de la clase Page definida en el

espacio de nombre System.Web.UI. Un objeto de esta clase representa una

página Web cuyo contenido se genera dinámicamente. La clase Page se utiliza

habitualmente como base para derivar nuevas clases de página, de la misma

forma que en Windows Forms se crean los formularios a partir de la clase

base System.Windows.Forms.

<%Page compilewith="MiPagina.aspx.cs" classname="MiEspacioDeNombres.MiClase" %>




Cuando se solicita una página .aspx al servidor Web, ASP.NET compila diná-

micamente el código incrustado en la página generando una clase derivada

de la clase Page. La clase recibe un nombre por defecto que puede alterarse

mediante el atributo ClassName en la línea <% @Page (ver Figura 3). Cuando seusa code-behind o code-beside el proceso es un poco más elaborado puesto

que el atributo Inherits permite tomar como base una clase distinta a Page. En

cualquier caso, la clase sólo se genera y compila la primera vez que se accede

a la página, mientras que en accesos posteriores la clase de página ya genera-

da previamente simplemente se instancia y se usa (ver Figura 9).

Clase

Página

generada

Figura 9. Modelo de ejecución detallado de una aplicación ASP.NET.

Archivo

.aspx

Solicitud

Motor

ASP.NET

Parseador Generar

Respuesta

Solicitud

Instanciar

Respuesta

ClasePágina

Instanciar,ejecutar yrenderizar

Compilador

Clase

code-behindo code-beside

Archivo ASP.NET_UOC_cb.aspx

<%@ Page Language="C#" CodeFile="ASP.NET_UOC_cb.aspx.cs"Inherits="UOC.EjemploASPNET" %>

<html>

<head><title>Ejemplo ASP .NET con code beside</title>

</head><body>

<h1>ASP .NET en la UOC con code beside</h1></body>

</html>

Figura 8. Ejemplo de página ASP.NET con code-beside .

Archivo ASP.NET_UOC_cb.aspx.cs

using System;using System.Web;using System.Web.UI;

namespace UOC {

public partial class EjemploASPNET : System.Web.UI.Page {private void Page_Load (object sender, System.EventArgs e) {

for (int H=1; H<=5; H++)Response.Write("<h" + H + ">Titulo de nivel " + H + "</h" + H + ">");

}}

}




1.7. Arquitectura de ASP.NET: modelo de proveedores

ASP.NET 2.0 proporciona una arquitectura modular y abierta, en la que cual-

quier componente puede substituirse por otro adaptado a las necesidades del

desarrollador. Los elementos fundamentales de la arquitectura pueden resu-

mirse de acuerdo a la Figura 10. Los bloques básicos proporcionan funciona-

lidades que pueden ser útiles para un amplio espectro de aplicaciones. Por

ejemplo, los mecanismos de pertenencia permiten gestionar nombres de

usuario y passwords de forma genérica en cualquier aplicación. La arquitec-

tura basada en proveedores proporciona a los bloques básicos la posibilidad

de usar diversos mecanismos de almacenamiento y recuperación de informa-

ción, como SQL Server, Active Directory, etc. Por su parte, los frameworks de

página emplean los bloques básicos para ofrecer servicios de alto nivel a las

aplicaciones, lo que facilita la creación de portales, por ejemplo. Finalmente

se dispone de un conjunto de controles de servidor, mucho más amplio queen versiones anteriores.

1.7.1. Controles de servidor

ASP.NET 2.0 incorpora un amplio conjunto de controles de servidor para el

acceso a datos, la identificación segura de usuarios, navegación, creación de

menús, visualizaciones en árbol, creación de portales, etc. Además, mejora

la extensibilidad de los controles, proporcionando gran cantidad de clases

base que encapsulan comportamientos típicos. A continuación repasamos

algunas de las familias de nuevos controles:

Figura 10. Arquitectura de ASP.NET 2.0. Visión de desarrollador.




Controles de acceso a datos. El acceso a datos puede llevarse a cabo de for-

ma totalmente declarativa, i.e. sin escribir código. Para ello existen nuevos

controles de fuente de datos para acceder a fuentes diversas, como bases de

datos SQL, objetos de negocio, XML, etc. Igualmente existen nuevos contro-

les para visualizar los datos, como gridview, detailsview, y formview.

Controles de navegación. Controles como treeview, menu y sitemappath, se ba-

san en los servicios de ASP.NET 2.0 para almacenar y recuperar flujos de na-

vegación predefinidos, y así permitir establecer la navegación entre las pági-

nas de un sitio Web de forma estructurada y consistente.

Controles de login. Estos controles proporcionan mecanismos para la auten-

ticación y autorización de usuarios en un sitio Web. Para ello se basan en los

servicios de pertenencia y gestión de roles.

Web parts. Estos controles permiten añadir contenido y layout ricos a un

sitio Web, al tiempo que le proporcionan la capacidad de editarlos directa-

mente desde la propia aplicación.

1.7.2. Frameworks de página

Los frameworks de página proporcionan servicios de alto nivel a las aplica-

ciones. Entre ellos destacan los siguientes:

Páginas maestras. Permiten definir una estructura y elementos de interfaz de

usuario comunes a todo un sitio Web. Así, cabeceras y pies de página, barras

de navegación, etc. pueden definirse en una “página maestra” en la que se

basarán todas las páginas del sitio.

Temas visuales. Permiten personalizar el look-and-feel de las páginas de un

sitio Web. La información de estilo se almacena en un lugar común deno-

minado “tema” y se aplica globalmente a todas las páginas y controles del

sitio. Como la anterior, esta característica reduce la cantidad de código du-

plicado y, por lo tanto, permite mejorar el mantenimiento de la aplicación.

Interfaz de usuario adaptativa. Los servicios de personalización permiten

crear experiencias de usuario personalizadas de una misma aplicación me-

diante la gestión de perfiles, de forma muy sencilla y con muy poco código.

Por otra parte, los servicios de localización proporcionan herramientas e

infraestructura para construir aplicaciones en múltiples idiomas, detectar el

idioma del navegador, etc.

1.7.3. Proveedores

La arquitectura basada en proveedores de ASP.NET 2.0 proporciona soporte

completo de almacenamiento a determinados servicios para la creación de




aplicaciones sofisticadas. Por ejemplo, soporte a mecanismos de pertenencia

(almacenamiento/recuperación de credenciales del tipo nombre de usuario y

palabra clave) y de gestión de roles. O servicios de personalización que per-

miten almacenar/recuperar configuraciones y preferencias de usuario. O un

sistema de navegación que permite la construcción de estructuras de nave-

gación consistentes. Todos estos servicios pueden intercambiarse por otros

implementados por el propio desarrollador o terceros.

1.8. Espacios de nombres de ASP.NET

La Figura 12 sumariza de forma gráfica los principales espacios de nombres

que agrupan la funcionalidad necesaria par la creación de aplicaciones y

servicios Web con ASP.NET. A continuación se describe en más detalle cuál

es el contenido de cada uno de ellos:

System.Web. Proporciona clases e interfaces que posibilitan la comunicación

entre navegadores y servidores Web. Es el espacio de nombres de más alto

nivel de ASP.NET y agrupa a todos los demás.

System.Web.Caching . Proporciona clases para implementar, en el servidor, ca-

ches de recursos frecuentemente usados, ya sean páginas, documentos XML,

sesiones, aplicaciones, etc.

System.Web.Configuration. Proporciona las clases usadas en la configuración de

ASP.NET.

System.Web.Security. Proporciona clases que permiten la implementación de

estrategias de seguridad en las aplicaciones Web.

System.Web.Services. Proporciona las clases que permiten la construcción de

servicios Web XML. Esto es aplicaciones que ofrecen la posibilidad de inter-

cambiar mensajes e interoperar mediante protocolos estándar como HTTP,

XML, XSD, SOAP y WSDL.

System.Web.Services.Description. Proporciona las clases que permiten describir

públicamente un servicio Web XML mediante WSDL.

Figura 11. Arquitectura de ASP.NET 2.0: proveedores.




System.Web.Services.Discovery. Proporciona las clases que permiten a los clientes

de servicios Web localizar los servicios disponibles en un servidor Web.

System.Web.Services.Protocols. Proporciona las clases que definen los protocolos

usados para transmitir datos durante la comunicación entre servicios Web y

sus clientes.

System.Web.UI . Proporciona clases, enumeraciones e interfaces que dan sopor-

te a la creación e interfaces de usuario para Web Forms .

System.Web.UI.HtmlControls. Proporciona las clases que permiten la creación de

controles HTML de servidor en una página Web. Los controles HTML de

servidor se corresponden con elementos estándar de HTML por lo que son

soportados por cualquier navegador. Dichas clases permiten controlar pro-

gramáticamente los elementos HTML de una página.

System.Web.UI.WebControls. Proporciona las clases que permiten la creación de

controles Web de servidor en una página Web. Los controles Web de servi-

dor incluyen formularios y controles habituales como botones y cuadros detexto, así como otros controles más complejos como calendarios. El modelo

de objetos de los controles Web no refleja necesariamente la sintaxis de

HTML.

1.9. ASP.NET y Windows Forms

A excepción de lo que ha sucedido en los sencillos ejemplos vistos hasta

ahora, habitualmente utilizaremos algún entorno de desarrollo que facilite la

construcción de la aplicación. Dichos entornos de desarrollo (como en el

caso de Visual Studio .NET) se encargan, entre otras cosas, de la separaciónentre la lógica de la aplicación y la interfaz de la misma empleando code-

behind , o de simplificar el diseño de las páginas.

System.Web

Configuration SessionState

Security

Figura 12. Espacios de nombres de ASP.NET.

Caching

SSeer r vviicceess UI

HtmlControls

WebControls

Description

Discovery

Protocols




Relacionado con el diseño de las páginas, cabe destacar que el modelo de

desarrollo de aplicaciones Web en ASP.NET sigue los pasos del modelo em-

pleado en Windows Forms para la creación de formularios. ASP.NET (Web

Forms ) simula un formulario compuesto por controles que atienden a distin-

tos tipos de eventos, ofreciendo así al usuario una interfaz en la que el efecto

cliente-servidor de la aplicación Web queda diluido.

Este es uno de los puntos importantes que diferencia ASP.NET de otros sis-

temas para generación de aplicaciones Web como ASP, JSP o PHP, en los que

el programador sí que es consciente del funcionamiento basado en peticio-

nes y respuestas. A diferencia de éstos, en Windows Forms , los eventos aso-

ciados a controles de servidor se generan en la aplicación cliente (el navega-

dor) pero son tratados por el servidor Web dentro del Framework de

ASP.NET. Más concretamente, la información de los eventos capturados enel navegador se transmite al servidor por medio de una solicitud HTTP POST

de forma totalmente transparente. Por su parte, el Framework de ASP.NET

debe interpretar esta información e invocar al método correspondiente que

trata el evento.

Desde el punto de vista del desarrollador, no hay diferencias sustanciales a la

hora de construir una aplicación de Windows Forms y una aplicación Web

ASP.NET. La diferencia fundamental estriba en el conjunto de controles dis-

ponibles, siendo los de Windows Forms mucho más potentes en cuanto a su

complejidad visual y de interacción con el usuario. En ASP.NET también se

dispone de controles habituales en los formularios, como botones, etiquetas,

etc. En este caso sin embargo, existen controles específicos derivados del

hecho de que HTML ya posee un conjunto de controles básicos y por lo tan-

to algunos de los controles de ASP.NET pueden mapearse directamente sobre

ellos. Adicionalmente, ASP.NET ofrece controles específicos orientados a la

Web, así como controles cuya ejecución se realiza en el servidor y no en el

navegador del usuario.




2. Formularios Web (Web Forms)

El objetivo de este apartado es introducir los elementos básicos de ASP.NET

que dan soporte a la construcción de una aplicación para la Web. El concep-

to clave y diferencial respecto a otras aproximaciones, son los llamados con-

troles de servidor. Agrupados en formularios y relacionados mediante un

potente sistema de gestión de eventos, estos controles permiten la construc-

ción de interfaces de usuario muy ricas de una forma relativamente sencilla.

2.1. Interfaces para la Web

Habitualmente se entiende por interfaz de usuario el conjunto de medios porlos que un usuario interactúa con un sistema, una aplicación, etc. La interfaz

proporciona métodos por los que el usuario controla el sistema y métodos

por los que el usuario recibe información del mismo.

Un tipo particular de interfaz lo constituye la interfaz gráfica de usuario

(GUI) que se basa en la manipulación de imágenes gráficas y elementos vi-

suales (widgets ) como ventanas, botones, cuadros de texto, etc. Junto a estos

elementos, un sistema de gestión de eventos se encarga de transmitir las

acciones del usuario a los distintos componentes de la interfaz para que reac-

cionen en consecuencia. El propio sistema operativo (como en el caso deWindows) o un intérprete especializado (como en el caso de Tcl/Tk) se en-

cargan de gestionar el conjunto.

El aprovechamiento de la Web para que, además de permitir la visualización

de documentos, permita también el acceso a aplicaciones remotas mediante

una interfaz HTML, implica algunas peculiaridades que diferencian este tipo

de interfaz de los GUI más tradicionales. El hecho principal es que la inter-

faz HTML no se ejecuta de forma nativa por el propio sistema operativo del

usuario sino en el interior del navegador Web, por lo que conceptos tradi-

cionales de los GUI, como MDI, SDI, cuadros modales, etc. no tienen dema-

siado sentido. El navegador entiende el lenguaje de marcas (HTML, XHTML,

…) que proporciona los elementos básicos para mostrar y solicitar informa-

ción a través de formularios. El procesado de los formularios, sin embargo, se

efectúa en el servidor quien recibe los datos que el navegador ha recogido del

formulario, y se encarga de transmitir los resultados para que los visualice el

navegador.

Los formularios Web (Web Forms ) son el elemento clave de ASP.NET para la

creación de páginas Web programables que sirvan como interfaz de usuariopara las aplicaciones Web. Gracias a la tecnología ASP.NET, el código que se

ejecuta en el servidor (incluida la lógica de la aplicación) genera dinámica-

MDI (Multiple DocumentInterface) se refiere a la inter-faz gráfica de usuario por laque todas las ventanas de unprograma residen en el inte-rior de una ventana que hacelas veces de marco. Este tipo

de interfaz es el más comúnen Windows, por ejemplo.

En una interfaz SDI (SingleDocument Interface) lasventanas de un programa sonindependientes entre sí y lasgestiona el propio gestor deventanas del sistema operati-vo. Este tipo de interfaz es el

más común en Unix, por ejemplo.




mente el contenido de las páginas Web hacia el navegador. El resultado pro-

ducido por una página Web Forms puede contener casi cualquier forma de

los lenguajes transmisibles sobre HTTP, como HTML, XML, WML, JScript y

JavaScript. Así, una página Web Forms genera automáticamente el código

adaptado a las capacidades del navegador cliente. Como resultado de lo an-

terior, una página Web Forms puede mostrar información al usuario en

prácticamente cualquier navegador o dispositivo cliente.

El diseño de formulario Web para aplicaciones en ASP.NET sigue un modelo

muy parecido al de Windows Forms . Es decir, existe el concepto de formula-

rio formado por un conjunto de controles y que atiende a los eventos que

genera el usuario en su interacción. El formulario distribuye cada evento a

los controles, siendo cada control responsable de atender o no al evento. En

respuesta a los eventos, otros controles pueden mostrar información al usua-

rio. Aunque la construcción de los formularios es muy similar a cómo sehace en Windows Forms , el conjunto de controles es diferente, existiendo,

por ejemplo, controles basados en HTML específicamente diseñados para la

Web. Otro aspecto diferencial es la forma de situar los controles en el formu-

lario, siendo mucho más arbitraria su colocación en el caso de los formula-

rios Web, puesto que una página puede adoptar diferentes tamaños depen-

diendo del navegador con el que se visualice, el tamaño de la ventana de

éste, o incluso la resolución de la pantalla en que se ejecute el navegador. Por

ello, la colocación de los componentes visuales en una página no sigue un

posicionamiento absoluto como en Windows Forms .

2.2. Controles de servidor

El código de la Figura 13 muestra un pequeño ejemplo de página ASP. Como

puede verse, el bloque de código se sitúa justo en el lugar de la página en la

que debe aparecer el resultado producido por dicho código. En ASP es impo-

sible separar el código ejecutable del código HTML que da forma a la página.

El resultado es un código difícil de leer y de mantener.

ASP.NET resuelve de forma ordenada el problema de programar el compor-

tamiento dinámico de las páginas Web mediante el uso de los llamados con-

troles de servidor. Éstos proporcionan una forma sencilla de encapsular fun-cionalidades usadas habitualmente y al mismo tiempo ser accesibles y

En una interfaz Web puededejarse que los elementosvisuales fluyan en la página,distribuyéndose según lasdimensiones del navegador, obien puede usarse posiciona-miento absoluto medianteCSS (Cascading Style Sheets).

<html><body bgcolor="green"><center><h2>Ahora son las: </h2><p><%Response.Write(now())%></p>

</center></body>

</html>

Figura 13. Ejemplo de página ASP.




ampliables programáticamente. ASP.NET aporta más de 40 controles de ser-

vidor aunque existe gran cantidad de ellos proporcionados por terceros.

Existen tres clases de controles de servidor:

Controles HTML: básicamente son marcas HTML

Controles Web: controles propios de ASP.NET

Controles de validación: controles propios de ASP.NET para la validación

de datos introducidos por el usuario

Seguidamente se muestran unos breves ejemplos para ilustrar estos tipos de

controles de servidor. En todos los casos se declaran en la página mediante

marcas propias o de HTML que contienen el atributo runat=‖server‖, de forma

que las marcas son entendidas y tratadas por el servidor.

2.2.1. Controles HTML

Fundamentalmente un control HTML de servidor es una marca HTML que se

procesa en el servidor antes de enviar la página al navegador del cliente.

Puesto que los elementos HTML en una página ASP.NET se tratan como sim-

ple texto y no se procesan, para hacerlos programables debe añadírseles el

atributo runat=‖server‖ . Además se suele añadir un atributo id que permite

identificar el control y así poder manipularlo desde el código en tiempo de

ejecución.

Todos los controles HTML de servidor deben hallarse dentro del ámbito de

una marca <form runat="server">. Esto indica que el formulario que los contiene

se procesará en el servidor y que por tanto los controles podrán accederse y

manipularse por el código de script que se ejecute en el servidor.

El código de la Figura 14 muestra una página de ASP.NET que usa un control

HtmlAnchor de servidor para incrustar un hipervínculo en una página Web.

Como se ve, el atributo HRef del control se manipula en tiempo de ejecución

mediante el código de atención al evento Page_Load que se produce cuando se

carga la página .aspx. Se observa también que ahora todo el código ejecutablese ha separado del código HTML.

Los controles HTML son másadecuados para los elementosestáticos de la página.

<html><script runat="server">void Page_Load () {

link1.HRef = "http://www.uoc.edu";}

</script><body><form runat="server">

<a id="link1" runat="server">¡Visita la Web de la UOC!</a>

</form></body>

</html>

Figura 14. Ejemplo de uso de controles HTML de servidor en ASP.NET.




El conjunto de controles HTML de servidor se agrupan bajo el espacio de

nombres System.Web.UI.HtmlControls. A las marcas que no corresponden explíci-

tamente a controles HTML de servidor se les asigna el tipo de control genéri-

co System.Web.UI.HtmlControls.HtmlGenericControl.

2.2.2. Controles Web

Adicionalmente al soporte de controles estándar HTML, ASP.NET permite el

uso de controles semánticamente mucho más ricos. Al igual que los contro-

les HTML de servidor, los controles Web de servidor también requieren del

atributo runat=‖server‖ para indicar que deben ejecutarse en el servidor. La

diferencia estriba en que un control Web de servidor no tiene porque tener

necesariamente una correspondencia con código HTML, y por lo tanto pue-

de encapsular funcionalidades más complejas.

Los controles Web de servidor, agrupados bajo el espacio de nombres Sys-

tem.Web.UI.WebControls, exponen un modelo de objetos que contiene propie-

dades, métodos y eventos, de la misma manera que cualquier otro objeto del

Framework de .NET. Gracias a este modelo de objetos los programas de

ASP.NET pueden interactuar e incluso modificar los controles en tiempo de

ejecución. Veremos más sobre eventos en el apartado “Eventos”.

La sintaxis para declarar un control Web de servidor en una página es la

siguiente: <asp:nombre_control id="algun_id" runat="server" /> , donde se aprecia la

marca asp al inicio de la declaración.

El ejemplo de la Figura 15 muestra la declaración de un botón en un archivo

.aspx . Al margen del identificador y el texto del botón, se declara también

una función de atención al evento OnClick del botón. La función cambia el

texto del botón al presionarlo en tiempo de ejecución.

2.2.3. Controles de validación

El modelo de formularios de ASP.NET proporciona un conjunto de controles

de validación de servidor que pueden emplearse para la validación de los

datos que introduce el usuario a través de otros controles del formulario. El

El motor de ASP.NET se en-carga de traducir los controles Web en marcas de HTML ycódigo ejecutable.

<html><script runat="server">void submit(Source As Object, e As EventArgs) {

boton1.Text="¡Ya has hecho clic!";}


<asp:Button id="boton1" Text="¡Haz clic!" runat="server" OnClick="submit"/></form>

</body></html>

Figura 15. Ejemplo de uso de controles Web de servidor en ASP.NET.




funcionamiento es simple: si los datos no pasan la validación se visualiza un

mensaje de error.

Cada control de validación puede llevar a cabo un tipo específico de com-

probación: que el valor introducido no coincida con un valor determinado,

que el valor introducido esté dentro de un rango especificado, que el texto

introducido coincida con un determinado patrón, etc. Un control muy inte-

resante es el control RequiredFieldValidator que permite forzar que el usuario

introduzca un valor en un determinado campo del formulario.

Por defecto, los controles de validación de una página se invocan cuando se

hace clic sobre un control de tipo Button, ImageButton o LinkButton. Puede in-

habilitarse la validación de un control asignando a false la propiedad CausesVa-

lidation. La sintaxis para declarar un control de validación de servidor es idén-

tica a la empleada para controles Web de servidor.

En el ejemplo de la Figura 16, se declara un control de tipo TextBox, un con-

trol de tipo Button y un control de tipo RangeValidator . La validación se refiere al

valor introducido en el control llamado tbox1 y debe cumplirse que el valor

entero introducido esté dentro del intervalo [1,100]. Si esta condición no se

cumple, el control de validación mostrará el mensaje indicado en el atributo

Text. La Figura 17 muestra la página Web en ejecución, donde puede verse la

validación en acción.

<html><body><form runat="server">

Introduce un número entre 1 y 100:<asp:TextBox id="tbox1" runat="server" /><br /><asp:Button Text="Envía" runat="server" /><br /><asp:RangeValidator ControlToValidate="tbox1"

MinimumValue="1" MaximumValue="100" Type="Integer"EnableClientScript="false" Text="¡El valor debe estar entre 1 y 100!"

runat="server" /></form>

</body></html>

Figura 16. Ejemplo de uso de controles de validación de servidor en ASP.NET.

Figura 17. Ejemplo de uso de controles de validación de servidor en ASP.NET: ejecución.




Es interesante destacar que los controles de validación proporcionan una

doble funcionalidad dependiendo del tipo de navegador en el que se visuali-

zan. Si el navegador es sofisticado, como IE o Firefox, permitirá que la vali-

dación se lleve a cabo eficientemente en el propio navegador mediante el

uso de DHTML y código JavaScript, pero también en el servidor. Si el nave-

gador es muy sencillo, como el de muchos teléfonos móviles, la validación

sólo será posible en el servidor. Lo más interesante es que el modelo de pro-

gramación es idéntico en ambos casos y que toda la responsabilidad recae en

el motor de ASP.NET y en su habilidad para identificar las capacidades del

navegador del cliente.

Finalmente destacar que el programador puede recurrir en tiempo de ejecu-

ción a la propiedad Page.IsValid para determinar si todos los controles de

validación se han evaluado positivamente. Esto proporciona un mecanismo

sencillo para validar un formulario y decidir si debe procederse con la ejecu-ción de un determinado código o no.

2.2.4. Procesamiento de controles

Como ya hemos comentado anteriormente, cuando el servidor Web recibe la

solicitud de servir un archivo .aspx, lo que éste hace en primer lugar es pasar

el archivo en cuestión al motor de ASP.NET para que lo procese. El motor,

que no depende del servidor Web sino de la plataforma de ejecución de apli-

caciones que haya por debajo, debe extraer todas las marcas con el prefijo

asp y substituirlas por los elementos HTML y el código script de cliente ade-

cuados. La substitución no es algo directo como cambiar las apariciones de

cada elemento asp:TextBox por una marca type=‖text‖ de HTML, por ejemplo.

Antes al contrario, se trata de traducir las distintas propiedades y eventos de

cada control Web, que son muy similares a los de los controles correspon-

dientes en Windows Forms , en términos de elementos y atributos HTML,

estilos CSS y código JavaScript.

Para ver cómo trabaja el motor de ASP.NET en lo que respecta a la traducción

de los diversos controles durante el procesamiento de una página, podemos

recurrir a una sencilla prueba. Usando un editor de texto cualquiera creare-

mos una nueva página de ASP.NET y añadiremos un control de tipo CheckBox.

Le modificaremos algunas propiedades como Text, BorderColor o BackColor , y

CSS (Cascading Style Sheets)es un lenguaje para describir la forma de presentar docu-mentos escritos mediantelenguajes de marcas. Típica-

mente se usa para definir elestilo de una página Webescrita en HTML o XHTML.

<html><body><form runat="server">

<asp:CheckBox id="cbox1" runat="server"Text = ―Seleccioname‖ AutoPostBack = "True" BorderStyle = "dotted"BorderColor = "Green" BorderWidth = .5in BackColor = "Yellow">

</asp:CheckBox></form>

</body></html>

Figura 18. Procesamiento de controles: archivo fuente.

daremos el valor true a la propiedad AutoPostBack. La Figura 18 muestra el ar-

chivo .aspx con el código resultante, mientras que la Figura 19 muestra el

aspecto de la página Web en ejecución.

La Figura 20 muestra el código que recibe el navegador en respuesta a la soli-

citud de la página anterior. Como puede observarse el código es muy dife-

rente. En la parte inferior del código puede verse que el control CheckBox ha

generado diversos elementos HTML: un elemento span con los elementos que

afectan al estilo visual, un elemento input que hace que se muestre el botón

de selección, y un elemento label asociado que muestra el título. Al hacer clic

sobre el control se invoca a la función JavaScript que ha generado el motor

de ASP.NET y que se muestra en el código. En ella se comprueba qué nave-

gador visualiza la página y se recupera la referencia al formulario a través de

<html><body>

<form name="_ctl0" method="post" action="ejemplo.aspx" id="_ctl0"><input type="hidden" name="__EVENTTARGET" value="" /><input type="hidden" name="__EVENTARGUMENT" value="" /><input type="hidden" name="__VIEWSTATE" val-ue="dDwxMjc5OTM0MTg2OztsPGNib3gxOz4+YNCs8W+aBHSf8IuKt/nFe4+BMZk=" />

<script language="javascript" type="text/javascript"></script>

<span style="background-color:Yellow;border-color:Green;border-width:0.5in;border-style:Dotted;"><input id="cbox1" type="checkbox" name="cbox1" checked="checked"onclick="__doPostBack('cbox1','')" language="javascript" /><labelfor="cbox1">"Seleccioname"</label></span>

</form></body></html>

Figura 20. Procesamiento de controles: código generado por el motor de ASP.NET.

Figura 19. Procesamiento de controles.: ejecución.




un método u otro para, finalmente, enviar al servidor los datos apropiados

mediante una serie de campos ocultos del formulario (que se muestran en la

parte superior del código).

Como se aprecia en el ejemplo, el motor de ASP.NET genera gran cantidad

de código por nosotros cuando usamos controles Web de servidor. Una bue-

na práctica para evitar generar páginas muy “pesadas” consiste en emplear

controles HTML para construir el contenido estático de las páginas, en el que

no sea necesario personalizar ningún atributo ni tampoco se espere una res-

puesta. Por el contrario, se emplearán controles Web en caso de necesitar

acceder a las propiedades de un elemento visual desde el código que se ejecu-

ta en el servidor, o bien sea necesario obtener un valor introducido por el

control y/o responder a sus eventos.

2.2.5. Los formularios son controles

Ciertamente, en este punto hay poco que decir de los formularios, puesto

que diversos aspectos ya se han mostrado a lo largo de los ejemplos anterio-

res. Sin embargo no queremos que pasen desapercibidos.

Como hemos podido apreciar en los ejemplos anteriores, todos los controles

de servidor deben hallarse dentro del ámbito de un formulario, esto es, en el

ámbito de una marca <form runat="server">. Esto indica que el formulario que

contiene los controles se procesará en el servidor. Por tanto los controles y el

propio formulario (que también es un control) podrán accederse y manipu-

larse por el código de script que se ejecute en el servidor. Es importante des-

tacar que una página .aspx sólo puede contener un formulario de servidor.

La marca form puede ir acompañada de diversos atributos, como action, met-

hod, etc. Si bien, todos son opcionales, en su ausencia ASP.NET se encarga de

asignar algunos de ellos con valores por defecto. Como ejemplo, puede apre-

ciarse la diferencia en los atributos de la marca form en el código de la Figura

20, generado por el motor de ASP.NET para el código de la Figura 18.

2.3. Diseño de interfaces

Hasta el momento todos los ejemplos que hemos revisado han consistido en

escribir directamente el código ASP.NET. Es obvio que para diseñar aplica-

ciones Web de cierta entidad, esta forma de programar no es la más adecua-

da. Además de ser muy propensa a la comisión de errores se requiere del

programador conocimientos de diversas tecnologías relacionadas con la pro-

gramación para la Web. Existen diversas herramientas para el desarrollo de

aplicaciones Web con ASP.NET que facilitan enormemente la tarea, permi-

tiendo a los desarrolladores obviar muchos de los detalles del código quefinalmente se genera. La idea detrás de estas herramientas es conseguir que

los desarrolladores no deban preocuparse demasiado de los detalles de la

Controles HTML en VisualStudio 2005




programación de interfaces para Web, sino que puedan construir la interfaz

de forma lo más similar posible a como lo hacen para las aplicaciones de

escritorio convencionales. Sin embargo hay algunas peculiaridades que de-

ben tenerse en cuenta, algunas de las cuales ya hemos visto por las diferen-

cias existentes en los distintos tipos de controles.

Observando las cajas de herramientas de Visual Studio 2005 (ver figuras al

margen) apreciamos la existencia de controles Web y controles HTML tal

como hemos descrito previamente. Puede apreciarse que curiosamente en

ambas categorías existen controles similares como Button, CheckBox o Table.

Sin embargo, como es de esperar, Visual Studio los trata de forma diferente y

genera un código distinto para ellos. Veámoslo con un ejemplo sencillo.

Creamos una aplicación Web con Visual Studio e insertamos, por ejemplo,

tres controles HTML: un TextField, un CheckBox y un Button. Seguidamente in-

sertemos tres controles Web equivalente: un TextBox, un CheckBox y un Button.En el caso de los controles HTML el código resultante (ver Figura 21) consiste

en tres marcas INPUT de HTML de tipo text, checkbox y button, respectivamente.

Para los controles Web el código generado hace referencia a los controles

correspondientes de ASP.NET, incluyendo un identificador para poder ser

accedidos programáticamente en tiempo de ejecución, etc.

Más rigurosamente, si insertamos en una página ASP.NET un control HTML

y un control Web y comprobamos la lista de propiedades de cada uno de

ellos, observaremos claras diferencias. En un control HTML lo que aparece

como propiedades no son otra cosa que los atributos que les corresponden al

elemento en cuestión según el estándar HTML, i.e. class, name, style, onmouse-out, onfocus, etc. Un control Web de ASP.NET dispone en cambio de propie-

dades como Font, ForeColor , BackColor , Visible, Text, ToolTip, etc. habituales en los

Controles Web en VisualStudio 2005

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

<HEAD><title>WebForm1</title><meta name="GENERATOR" Content="Microsoft Visual Studio .NET 7.1"><meta name="CODE_LANGUAGE" Content="C#"><meta name="vs_defaultClientScript" content="JavaScript"><meta name="vs_targetSchema" content="http://schemas.microsoft.com/intellisense/ie5">

</HEAD><body MS_POSITIONING="GridLayout">

<form name="Form1" method="post" action="WebForm1.aspx" id="Form1"><input type="hidden" name="__VIEWSTATE" value=

"dDwxNjYxNDI0MTU4OztsPENoZWNrQm94MTs+ProHQ8wBNHC5GCs4BkVpx4PIa4YI" /><INPUT type="text"><INPUT type="checkbox"><INPUT type="button" value="Button">

<input name="TextBox1" type="text" id="TextBox1" /><input id="CheckBox1" type="checkbox" name="CheckBox1" /><input type="submit" name="Button1" value="Button" id="Button1" />

</form></body>

</HTML>

Figura 21. Controels HTML vs. Controles Web: archivo fuente.




controles usados en Windows Forms para la construcción de aplicaciones de

escritorio. Se trata por lo tanto de elementos visuales más completos y que

permiten gestionar una interacción más elaborada con el usuario.

La construcción de interfaces ricas de usuario requiere, por tanto, el uso de

un conjunto de controles que comparten características comunes y se aseme-

jan a los controles de Windows Forms . Así como los controles Windows

derivan de la clase Control del espacio de nombres System.Windows.Forms, con los

controles HTML y Web sucede algo similar ya que en su mayor parte derivan

directa o indirectamente de de la clase Control definida en el espacio de nom-

bres System.Web.UI.

Respecto a las características de los controles, la mayoría de ellos, como es el

caso de los distintos tipos de botones, disponen de la propiedad Text para

asignarles un título. Si se trata de un CheckBox se dispone también de la pro-piedad Checked, de tipo booleano. Si es un TextBox, éste puede usarse para

introducir una o más líneas de texto dependiendo de la propiedad TextMode,

empleándose las propiedades Rows y Columns para indicar el formato de la

entrada, si es el caso. A modo de ejemplo, la Figura 22 muestra el panel de

propiedades para dos controles Web.

Además de estas propiedades específicas, que no describiremos en detalle,

para cada tipo de control, existen otras propiedades de carácter genérico queaplican a casi la totalidad de los controles Web.

Figura 22. Propiedades de un control Web en Visual Studio: TextBox y Button.




2.3.1. Propiedades de apariencia visual

Las propiedades que afectan a la apariencia visual permiten establecer aspec-

tos de los controles como las dimensiones, colores, bordes, etc. Algunas de

las propiedades de apariencia más usuales son:

Height y Width: Establecen, respectivamente, la altura y la anchura del con-

trol, mediante diversas unidades de medida absolutas (píxeles, milíme-

tros, pulgadas, …) y relativas (respecto al tamaño de letra por defecto,

etc.). La unidad de medida se indica mediante un sufijo, e.g. 10px para 10

píxeles, 10em para 10 veces el tamaño de la fuente por defecto, etc.

BackColor y ForeColor : Establecen el color de fondo y del texto del control.

Aunque pueden usarse directamente colores reconocidos en HTML o bien

colores RGB, lo más sencillo es usar la paleta de colores del diseñador de

interfaces.BorderColor , BorderStyle y BorderWidth: Permiten configurar el color (de igual

forma que en las propiedades anteriores), estilo (según CSS) y anchura del

borde (usando las unidades de medida descritas anteriormente) de un

control.

Font: Establece el tipo de letra, su tamaño y demás atributos habituales.

Todas estas propiedades estarán especificadas en el documento .aspx alojado

en el servidor Web correspondiente y se aplicarán en la visualización de la

página ASP.NET. Sin embargo, el navegador lo único que recibirá serán ele-

mentos HTML con el atributo style y las propiedades CSS equivalentes.

2.3.2. Propiedades de comportamiento

Otro grupo importante de propiedades generales a todos los controles son las

que permiten especificar su comportamiento, i.e. su visibilidad y accesibili-

dad. De estas propiedades destacan algunas como Enabled, Visible, AccessKey,

TabIndex o ReadOnly.

Las propiedades Enabled y Visible son de tipo booleano, indicando la primera siel control será accesible mediante teclado o ratón, y la segunda si el control

será visible o no. Al igual que el resto de propiedades de un control, éstas

pueden modificarse desde el código de la página en respuesta a cualquier

evento o condición. Debe tenerse en cuenta, sin embargo, que la visualiza-

ción/ocultación de un control oculto/visible puede conllevar una redistribu-

ción del resto de los controles en la página, a no ser que se haya usado el

posicionamiento absoluto.

Algunos controles (botones, cuadros de texto, listas, etc.) son capaces de

tomar para sí el foco de la entrada de datos en la página (teclado, ratón, etc.).Cómo sólo un control en la página puede tener el foco en un momento da-

do, un control pierde el foco en el momento en que otro lo obtiene. Aunque

Style=‖BORDER-RIGHT: 2pxsolid; BORDER-TOP: 2px solid;BORDER-LEFT: 2px solid;BORDER-BOTTOM: 2px solid; WIDTH: 234px; HEIGHT:216px; BACKGROUND-COLOR: #FF0BA6‖

Estilo correspondiente a uncontrol con borde sólido de 2píxeles, anchura de 234píxeles, altura de 216 píxeles y color de fondo expresadoen RGB.




el usuario puede usar el ratón para dar el foco de entrada a un control cual-

quiera de la página, es recomendable facilitar el acceso mediante teclado.

Para ello se usan las propiedades AccessKey y TabIndex. TabIndex contendrá un

número entero superior a cero, tomando automáticamente el foco de la

página recién cargada el control con el menor valor en esta propiedad, y

avanzando el foco al siguiente control en el orden con cada pulsación del

tabulador. Por su parte, la propiedad AccessKey permite asignar a un control

cualquier carácter que combinado con la tecla Alt (o similar) dará el foco de

entrada de datos directamente a dicho control.

2.4. Eventos

Como ya hemos comentado, una página HTML es un documento estático

que, una vez recibido, es visualizado por el navegador sin que haya ninguna

interacción más con el servidor hasta que una nueva página es solicitada. Alo sumo, si la página contiene un formulario, los datos se enviarán al servi-

dor al hacer clic sobre el botón de tipo submit.

Sin embargo, en ASP.NET es necesario poder informar al servidor de que un

control ha desencadenado un evento y que debe ser procesado por las clases

alojadas en el servidor para generar una respuesta. En consecuencia el desa-

rrollo de interfaces Web en ASP.NET, al igual que Windows Forms , presenta

un modelo de programación basado en eventos. Así pues, cuando un control

cambia su estado, por ejemplo cuando un usuario hace clic en un botón, el

botón lanza un evento. A diferencia que en Windows Forms , el evento gene-

rado por la interfaz de usuario requiere de una solicitud al servidor Web para

que lo procese.

A diferencia de lo que ocurre en ASP, ASP.NET proporciona orientación a

eventos real. En ASP una página se procesa de forma secuencial, i.e. las líneas

de HTML o código ASP se procesan una tras otra. Las acciones de usuario

comportan el envío de la página al servidor, por lo que éste debe reconstruir

la página, tras lo cual debe procesarla nuevamente de forma secuencial. En

consecuencia la aplicación no muestra propiamente un comportamiento

orientado a eventos. Al contrario, si se desea dicho comportamiento debeprogramarse explícitamente manteniendo el estado al más bajo nivel, etc.

Todo ello limita la riqueza de la interfaz de usuario al tiempo que complica

enormemente el código de la aplicación.

2.4.1. Generalidades

Los controles de servidor ASP.NET exponen y lanzan eventos que pueden

usarse para construir interfaces de usuario ricas. Esto puede hacerse de forma

sencilla mediante la asociación de un método a un evento de un control. En

la asociación se usa el nombre de atributo de un evento para indicar el nom-bre del evento y el valor del atributo para indicar el nombre de un método

(event handler ) al que invocar cuando dicho evento se produzca. Por ejem-

La generación de eventos en

las interfaces Web de ASP.NETrequiere del envío de unasolicitud al servidor.




plo, la Figura 23 muestra cómo asociar un evento Click a un botón para cam-

biar el valor de la propiedad Text en un TextBox en tiempo de ejecución. La

Figura 24 muestra el aspecto visual de la página.

Se llama a un método de control de eventos sólo cuando ocurre un evento

específico de un control determinado, lo que permite evitar tener un método

global en el formulario que controle todos los eventos de todos los controles.

Además, debido a que la arquitectura de eventos de los formularios está ba-

sada en delegados, los métodos de control de eventos tienen seguridad de

tipos de datos. Esto permite que el compilador pueda detectar la falta de

coincidencia en la signatura del método durante la compilación.

Dos clases dan soporte a cada evento. Por una parte la clase de delegado

EventHandler, utilizada para registrar el método de control del evento. Y por

otra parte la clase EventArgs que contiene datos acerca del evento lanzado.

La signatura de un EventHandler consiste en que el primer argumento contiene

una referencia al objeto que lanzó el evento (emisor) y en que el segundo

argumento contiene datos acerca del evento (una instancia de EventArgs). Por

ejemplo, el evento Click de un control de tipo Button utiliza el siguiente

método controlador:

El modelo de atención a loseventos de los formularios sebasa en el uso de métodosdelegados.

En programación orientada aobjeto es habitual identificar un método mediante susignatura. Esta consiste en elnombre del método, el núme-ro y tipo de sus parámetros, yel tipo del resultado queretorna.

public delegate void EventHandler(object sender, EventArgs e);

<html><script language="C#" runat="server">

void EnterBtn_Click(Object Src, EventArgs E) {Mensaje.Text = "Bienvenido a ASP.NET " + HttpUtility.HtmlEncode(Nombre.Text);

}</script><body><form runat="server">

Introduce tu nombre:<asp:textbox id="Nombre" runat="server"/><asp:button text="Ok" Onclick="EnterBtn_Click" runat="server"/><p><asp:label id="Mensaje" runat="server"/>

</form></body>

</html>

Figura 23. Ejemplo de gestión de un evento.

Figura 24. Ejemplo de gestión de un evento: ejecución.




Como resultado, cualquier método de control de eventos del evento Click

debe tener la siguiente signatura:

La signatura de la clase EventHandler dicta la forma de la signatura del método

de control del evento. Así, si en la programación de la lógica de la aplicación

se usa un lenguaje fuertemente tipado, e.g. C#, se producirá un error de

tiempo de compilación si la signatura del método de control del evento no

coincide con la signatura del método delegado.

Existen varios eventos que utilizan clases EventHandler e EventArgs genéricas. Sin

embargo, algunos eventos necesitan información adicional que es específica

del tipo del evento provocado. Por ejemplo, los eventos relacionados con el

movimiento del ratón incluyen información acerca de la posición del punte-ro y de los botones del ratón. Estos eventos definen sus propias clases que

deben heredarse de las clases EventHandler y EventArgs. Por ejemplo, el evento

MouseDown utiliza las clases MouseEventHandler y MouseEventArgs.

Un evento puede suceder tanto antes como después de que se produzcan

cambios en tipos de estado de los controles o la página, lo que afecta a su

nomenclatura. Un evento provocado antes de que se produzca un cambio de

estado suele llevar como sufijo "ing". Un evento provocado después de que se

produzca un cambio de estado suele usar el sufijo "ed". Por ejemplo, el even-

to SessionEnding se provoca antes de que se produzca un cambio de estado, y el

evento SessionEnded se provoca después de que se produzca un cambio de

estado. Si un cambio de estado provoca sólo un evento, ese evento normal-

mente no tendrá ningún sufijo. Por ejemplo, el evento Click.

2.4.2. Eventos en páginas Web

Al margen de lo comentado en el apartado anterior, que no difiere del tra-

tamiento de eventos en Windows Forms , ASP.NET ofrece eventos y propie-

dades específicos relacionados con aspecto propios de las aplicaciones Web.Trataremos la carga de páginas y el lanzamiento controlado de eventos.

Algunos eventos, como los deratón, necesitan clases desoporte específicas, eso sí,derivadas de las clases genéri-cas EventHandler y EventArgs


et1.Text="La fecha y hora actual es: " + System.DateTime.Now.ToString();}


<h3><asp:label id="et1" runat="server" /></h3>

</form></body>

</html>

Figura 25. Ejemplo de uso de Page_Load.

<access> void <name>(object sender, EventArgs evArgs)




Evento Page_Load. Como sugiere su nombre, este evento se lanza cuando se

carga una página. Cuando eso sucede, ASP.NET invoca automáticamente al

método Page_Load(). La Figura 25 muestra un ejemplo en el que el texto de un

control de tipo Label se define en el momento de cargar la página.

Propiedad Page.IsPostBack . El método Page_Load() se ejecuta cada vez que se

carga la página en cuestión. Si lo que queremos es que el código de Pa-

ge_Load() se ejecute sólo la primera vez que se carga la página, debemos con-

sultar el valor de la propiedad booleana Page.IsPostBack. Si la propiedad tiene

valor falso, la página se está cargando por primera vez, pero si la propiedad

es cierta, la página está siendo cargada de nuevo, como cuando se han con-

firmado los datos del formulario, por ejemplo. El código de la Figura 26

muestra un ejemplo en el que se comprueba el valor de la propiedad Pa-

ge.IsPostBack en el método Page_Load(), de forma que la fecha y hora mostradas

en la página no cambian cuando se pulsa el botón de envío.

Propiedad AutoPostBack. Todo control de ASP.NET que puede generar un

evento dispone de la propiedad booleana AutoPostBack. Ésta indica si el control

debe producir una nueva solicitud al servidor para cada evento que el con-

trol genere. Por defecto el valor de la propiedad es falso, lo que indica que si

por ejemplo tenemos un control CheckBox y asociamos código al evento Chec-

kedChanged, éste en realidad no tendrá lugar cuando el usuario cambie la se-

lección en el CheckBox, sino sólo al enviar el formulario al servidor. Si asig-

namos el valor cierto a la propiedad AutoPostBack haremos que ASP.NET añada

a la página el código JavaScript necesario para detectar el evento y hacer la

solicitud al servidor en el momento en que se produzca el evento.

La existencia de esta propiedad tiene su origen en el hecho de que una apli-

cación Web ejecuta la interfaz de usuario en el navegador del cliente, mien-

tras que la lógica de la aplicación se ejecuta en un servidor remoto con el que

el navegador se comunica a través de un medio relativamente lento como es


if (!Page.IsPostBack)et1.Text="La fecha y hora actual es: " + System.DateTime.Now.ToString();

}void submit (Object s, EventArgs e) {

et2.Text = "Hola!";

}</script><body><form runat="server">

<h3><asp:label id="et1" runat="server" /></h3><h3><asp:label id="et2" runat="server" /></h3><asp:button text="Envío" onclick="submit" runat="server" />

</form></body>

</html>

Figura 26. Ejemplo de uso de Page.IsPostBack.




una red. Así pues el envío continuado de solicitudes, por ejemplo en cada

cambio de selección en una lista, provocarían un funcionamiento de la apli-

cación y un tráfico excesivamente pesados.

2.5. Acceso al flujo de HTML

La última forma de interfaz para las aplicaciones consiste en la utilización

directa del flujo de información HTML, en cualquiera de los dos sentidos.

En diversos de los ejemplos vistos hasta el momento hemos utilizado táci-

tamente la propiedad Response de la clase Page, y concretamente el método

Write(), para introducir contenido en el documento que se envía a través del

flujo HTML en respuesta a las solicitudes del cliente. Response se complemen-

ta con la propiedad Request, que representa la solicitud hecha por el cliente,

es decir el flujo HTML desde el navegador del cliente hacia el servidor. Am-bas propiedades, instancias respectivas de las clases HttpResponse y HttpRequest,

proporcionan acceso al flujo de HTML a través de sus métodos.

Mediante el método Write() de Response, no sólo es posible introducir un string

de código HTML en el flujo de respuesta, sino que también puede introducir-

se directamente la información almacenada en un archivo usando el método

WriteFile(). Igualmente es posible introducir datos binarios en el documento de

respuesta mediante el método BinaryWrite(), que admite como parámetro un

array de bytes con cualquier contenido. La Figura 27 muestra ejemplos en C#de ambos procedimientos.

Uso de Response.WriteFile()

String NomArchivo;FileInfo Info;long PosInicio = 0, Longitud;

NomArchivo = "c:\\temp\\archivo.txt";

Info = new FileInfo(NomArchivo);Longitud = Info.Length;Response.WriteFile(NomArchivo, PosInicio, Longitud);

Uso de Response.BinaryWrite()

FileStream Archivo;long Longitud;

Archivo = new FileStream("archive.bin", FileMode.Open);Longitud = Archivo.Length;

byte[] Buffer = new byte[(int) Longitud]; Archivo.Read(Buffer, 0, ( int) Longitud);

Archivo.Close();

Response.Write("<b>Contenido del archivo: </b>");Response.BinaryWrite(Buffer);

Figura 27. Escritura directa en el flujo HTML.




También es posible usar Response para acceder directamente al objeto que

representa flujo de salida mediante las propiedades Output (en modo texto) y

OutputStream (en modo binario), o redireccionar al cliente a una página distin-

ta mediante el método Redirect(), entre otras cosas.

Por su parte, la propiedad Request dispone de propiedades que permiten recu-

perar diversa información procedente del navegador cliente: la cadena de

consulta (QueryString), los formularios (Form), los archivos adjuntos a la solici-

tud (Files), etc. Además, de forma similar a lo que sucede con Response, es po-

sible acceder directamente al flujo HTML de entrada mediante la propiedad

InputStream, o usar métodos como BinaryRead() y SaveAs() para leer datos de la

solicitud o guardar dicha información en una archivo, por ejemplo.




3. Primera aplicación ASP.NET

El objetivo de este breve apartado es proporcionar cierta familiaridad práctica

con la construcción de la interfaz de usuario de una aplicación Web de

ASP.NET, mediante Visual Studio. La aplicación simula un sistema sencillo

de compra de pizzas a través de Internet. En primer lugar crearemos un pro-

yecto de Visual Studio para el desarrollo de una aplicación Web. Seguida-

mente diseñaremos la interfaz de usuario de la aplicación mediante la caja de

herramientas del diseñador de formularios Web de Visual Studio. Finalmente

dotaremos de comportamiento a los controles del formulario gestionando

determinados eventos. Cabe destacar que las diferentes actividades que apa-

recerán el los capítulos sucesivos, harán referencia a la aplicación resultantede este apartado, por lo que es muy recomendable completarlo antes de se-

guir con el resto de apartados.

3.1. Introducción

Tal como se ha comentado, la aplicación que vamos a desarrollar se enmarca

en el contexto de un sencillo sistema de compra de pizzas a través de Inter-

net. Concretamente construiremos una página .aspx en la que se determinará

el precio de la pizza a partir de las preferencias del cliente. En definitiva se

tratará simplemente de diseñar un formulario Web utilizando diversos con-troles y dotándolos de comportamiento. El proceso de construcción de la

aplicación será guiado por sucesivos pasos a modo de tutorial.

Cabe resaltar que el término aplicación se usa en este punto de forma un

tanto ambiciosa puesto que el concepto de aplicación en ASP.NET incluye

muchos más elementos de los que aquí se van a tratar (ver apartado

“Aplicaciones Web”). Por otra parte hacer notar que aunque la aplicación

resultante de este apartado es una sencilla página Web, se espera dar pie a la

experimentación con los diversos controles que pueden usarse en un formu-

lario Web, sus propiedades visuales, así como la gestión de sus eventos.

En línea con lo anterior, cabe destacar que en ningún caso esta aplicación

pretende ser una aplicación "real". Por una parte su funcionalidad es muy

reducida y no pretende ser representativa de la complejidad que puede llegar

a tener una aplicación ASP.NET. Por otra, su diseño e implementación se ha

realizado teniendo en cuenta los pocos conocimientos vistos hasta este pun-

to. Por lo que la aplicación no emplea mecanismos que se verán más adelan-

te y que toda aplicación ASP.NET bien diseñada debería utilizar, como por

ejemplo validación, gestión del estado, etc.




3.2. Creación del proyecto

En los pasos siguientes crearemos un proyecto de aplicación Web que deno-

minaremos PizzaPricer y programaremos en C#.

1. Ejecutamos Visual Studio, si no está ya en ejecución.

2. Para crear un nuevo proyecto hacemos clic en el menú Archivo, en la

opción Nuevo y seleccionamos Sitio Web.

3. En la lista Tipo de proyecto, seleccionamos Proyectos C#.

4. En la lista de Plantillas, seleccionamos Sitio Web ASP.NET.

5. En el campo Ubicación escribimos el directorio donde se alojará la apli-

cación (no usaremos IIS). La Figura 28 muestra el cuadro de diálogo resul-

tante.

6. Clicamos Aceptar y el IDE ofrece un aspecto como el de la Figura 29.

Figura 28. Diálogo de creación de un proyecto de aplicación Web en Visual Studio.

Figura 29. IDE de Visual Studio para la creación de aplicaciones Web.




Si hubiésemos decidido usar IIS para alojar la aplicación, como resultado de

los pasos anteriores se hubiese creado un directorio virtual en el servidor

correspondiente a la URL http://localhost/PizzaPricer . En dicho directorio, loca-

lizado físicamente en C:\inetpub\wwwroot\PizzaPricer\, se alojan no sólo los

archivos de código sino todos los archivos que precisa Visual Studio para la

programación y depurado de la aplicación (ver Figura 30).

3.3. Diseño de la interfaz

En este punto construimos una sencilla interfaz de usuario en la que podrá

indicarse el tamaño de la pizza mediante RadioButtons, escogerse los ingredien-

tes mediante CheckBoxes y, al clicarse un botón, visualizar el precio resultante.

7. En el panel Explorador de soluciones, clicamos con el botón derecho

sobre el archivo Default.aspx, seleccionamos Cambiar nombre, cambiamos

el nombre por PizzaPricer.aspx y presionamos ENTER.

8. En el panel Cuadro de herramientas, a la izquierda del IDE, selecciona-

mos un control Web de tipo Label y lo arrastramos sobre el formulario, de-jando el control en la parte superior del mismo.

9. Clicamos sobre el nuevo control para ver sus propiedades y en la sección

Apaciencia, cambiamos el valor de la propiedad Text por la cadena Elige el

tamaño de la pizza: .

10. En la sección Varios, cambiamos el valor de (ID) por SizeLabel .

11. En el diseño del formulario Web, nos situamos tras la etiqueta introduci-

da y presionamos ENTER para saltar de línea.

12. En el panel Cuadro de herramientas seleccionamos un control tipo Radio-

ButtonList y lo arrastramos sobre el formulario.

13. Clicamos sobre el nuevo control para ver sus propiedades y en la secciónVarios, cambiamos el valor de (ID) por PizzaSizes . En la propiedad Items de

Figura 30. Directorio virtual del proyecto PizzaPricer.




la misma sección Varios clicamos sobre el botón . Aparecerá el editor

de la colección ListItem.

14. Clicamos el botón Agregar y añadimos las parejas de Miem-

bros/Propiedades siguientes:

Pequeña 5.95Mediana 7.95

Grande 9.95

15. Finalmente clicamos Aceptar.

16. En el panel Cuadro de herramientas, seleccionamos un control tipo Label

y lo arrastramos sobre el formulario.

17. Clicamos sobre el nuevo control para ver sus propiedades y en la sección

Apariencia, cambiamos el valor de la propiedad Text por Elige los com-

plementos: . Asimismo, en la sección Varios, cambiamos el valor de (ID)

por ToppingsLabel .

18. En el diseñador del formulario nos situamos tras la etiqueta introducida y

presionamos ENTER para saltar de línea.

19. En el panel Cuadro de herramientas seleccionamos un control tipo

CheckBoxList y lo arrastramos sobre el formulario.

20. Cambiamos el valor de (ID) por ToppingsList . En la propiedad Items de la

misma sección Varios clicamos sobre el botón . Aparecerá el editor de

la colección ListItem. Clicamos en el botón Agregar y añadimos las pare-

jas de Miembros/Propiedades siguientes:

Pimiento 0.50

Chorizo 0.50Carne 0.75

Olivas 0.25

Figura 31. Aspecto de Visual Studio al completar el diseño de la interfaz.




21. Finalmente clicamos Aceptar.

22. En el panel Cuadro de herramientas seleccionamos un control tipo Label

y lo arrastramos sobre el formulario. Cambiamos el valor de la propiedad

Text por Precio: y cambiamos el valor de (ID) por PriceLabel .

23. En el diseño del formulario nos situamos tras la etiqueta recién introdu-

cida y presionamos la barra espaciadora para separar esta etiqueta de la

que introduciremos a continuación.

24. En el panel Cuadro de herramientas seleccionamos un control tipo Label

y lo arrastramos sobre el formulario. Borramos el valor de la propiedad

Text para que sea vacío y cambiamos el valor de (ID) por PriceResults .

25. En el diseño del formulario presionamos ENTER para saltar de línea y

añadimos un control tipo Button. Cambiamos el valor de la propiedad Text

por Calcular precio y cambiamos el valor de (ID) por CalculatePrice .

26. En este momento el IDE de Visual Studio debería mostrar un aspecto

como el de la Figura 31 en el que se aprecia el diseño del formulario Weben el centro.

Con los pasos anteriores se ha completado el diseño de la interfaz de usuario

consistente en un único formulario Web. El código C# correspondiente es

autogenerado por el IDE de Visual Studio y puede verse presionando la tecla

F7 o mediante la opción Código del menú Ver. Igualmente, presionando

SHIFT-F7 puede verse el código HTML autogenerado por el diseñador.

3.4. Comportamiento de la interfaz

El siguiente paso consiste en dotar de comportamiento a la interfaz de usua-

rio de forma que cuando en el navegador cliente se presione el botón Calcu-

lar precio , la etiqueta PriceResults muestre el precio resultante. En el formula-

rio que acabamos de diseñar, esto consistirá simplemente en asociar un

método delegado al evento Click del citado botón.

27. De vuelta al diseño del formulario (ver Figura 31) seleccionamos el botón

CalculatePrice y en el panel de Propiedades hacemos clic en el botón, lo que da acceso a la lista de métodos asociados a eventos para el

control seleccionado.

28. En la acción correspondiente al evento Click escribimos el nombre del

método, CalculatePrice_Click, que a continuación programaremos. Al presio-

nar ENTER el IDE cambia al modo de escritura de código. En la ventana

que se abre escribiremos el código de la Figura 32 para el método recién

creado.




3.5. Pruebas y depuración

Una vez el código asociado a la interfaz está listo, ya podemos compilar la

solución y probarla.

29. Para compilar el código seleccionamos la opción Generar Sitio Web del

menú Generar.

30. Para ejecutar la aplicación hacemos clic con el botón derecho sobre el

archivo PizzaPricer.aspx en el panel Explorador de soluciones, selecciona-

mos la opción Ver con… y, seguidamente, la opción Explorador integra-

do. Visual Studio mostrará un aspecto similar al de la Figura 33.

31. La aplicación también puede ejecutarse en el navegador predeterminado

del sistema, para su depuración desde Visual Studio. Esto puede hacerse

seleccionando la opción Iniciar del menú Depurar, presionando F5 ohaciendo clic sobre el botón del IDE (ver Figura 34). La depuración

Figura 33. Ejecución de PizzaPricer en Visual Studio.

protected void CalculatePrice_Click(object sender, EventArgs e){

double Total;

Total = Convert.ToDouble(PizzaSizes.SelectedItem.Value);

foreach (ListItem Item in ToppingsList.Items){

if (Item.Selected)Total += Convert.ToDouble(Item.Value);

}

PriceResults.Text = Total.ToString("0.00") + " €";}

Figura 32. Método CalculatePrice_Click.




puede detenerse en cualquier momento seleccionando la opción Detener

depuración del menú Depurar o clicando sobre el botón .

Finalmente, si se ha usado IIS para alojar la aplicación durante el desarrollo,

ésta también puede ejecutarse directamente en el navegador preferido del

desarrollador (ver Figura 35). Si se accede desde el propio ordenador donde

se está desarrollando la aplicación esto puede hacerse accediendo a la URLhttp://localhost/PizzaPricer/PizzaPricer.aspx. Si se está accediendo desde otro

ordenador de la misma red donde se está programando la aplicación bastará

indicar la URL con la dirección IP (e.g.

http://192.168.0.33/PizzaPricer/PizzaPricer.aspx) o el nombre del ordenador de

desarrollo (http://miordenador/PizzaPricer/PizzaPricer.aspx).

Figura 34. Ejecución de PizzaPricer en Mozilla Firefox lanzado desde Visual Studio.

Figura 35. Ejecución de PizzaPricer en Mozilla Firefox.




3.6. Observaciones

Como ya hemos comentado anteriormente, la aplicación que se ha cons-

truido en este apartado dista mucho de ser considerada una aplicación Web

propiamente, puesto que no plantea casi ninguna de la problemática habi-

tuales en este tipo de aplicaciones.

En primer lugar se trata de una aplicación constituida por una sola página

Web, para acceder a la cuál no es preciso ningún tipo de autenticación pre-

via. Habitualmente una aplicación Web, por sencilla que sea, consta de di-

versas páginas enlazadas entre sí a las que se accede tras la identificación del

usuario en otra página inicial (ver apartado “Autenticación y autorización”),

usando mecanismos de autenticación diversos: los propios de la aplicación,

los del servidor Web, un directorio activo, etc. El uso de diversas páginas enuna aplicación plantea además la problemática de cómo mantener los datos

de la aplicación cuando el usuario cambia de una página a otra, problemática

derivada del desacoplamiento entre cliente y servidor del protocolo HTTP

(ver apartado “Aplicaciones Web”).

Por otra parte, no hay tampoco ningún tipo de validación de los datos (ver

apartado “Validación de datos”) lo que puede provocar que la aplicación no

sea robusta a los errores de usuario, por ejemplo.

Estos y otros aspectos se tratan a lo largo de los siguientes apartados. En ellos

aparecen actividades que permitirán ir completando algunos de los aspectos

citados, sobre la aplicación base que hemos construido en este apartado. En

consecuencia es recomedable no proseguir hasta haber completado con éxito

todos los pasos del tutorial.




4. Procesamiento de formularios

El objetivo de este apartado es entrar en mayor detalle en el procesamiento

de una página Web ASP.NET. Para ello analizaremos en primer lugar las di-

versas etapas por las que pasa un formulario Web Forms mientras es proce-

sado, i.e. el llamado round trip . Seguidamente revisaremos la forma en que

ASP.NET procesa los formularios, sean de HTML o de Web Forms , viendo

cómo es posible acceder y validar los datos introducidos en un formulario.

Finalmente veremos el enlace de datos, un aspecto muy interesante que

permitirá enriquecer los formularios con datos externos procedentes de fuen-

tes diversas.

4.1. Ciclo de vida de una página Web Forms

El procesamiento de una página Web Forms es similar al de cualquier proce-

so Web que se ejecuta en el servidor, i.e. la información se transmite sobre

HTTP, no hay mantenimiento del estado, etc. Sin embargo, ASP.NET se en-

carga de diversos servicios de soporte a las aplicaciones Web, que lo hacen

diferente. Por ejemplo, el motor de ASP.NET captura la información enviada

junto a los formularios y la hace accesible a través de propiedades de objetos.

Comprender la secuencia de eventos que tienen lugar durante el procesa-miento de una página Web Forms puede ayudar a desarrollar aplicaciones

Web de forma más efectiva. Antes, sin embargo, revisaremos algunas carac-

terísticas fundamentales del funcionamiento de Web Forms .

4.1.1. Round trip

Cuando el navegador presenta un formulario al usuario, éste interacciona

con él y finalmente lo envía de nuevo al servidor ( post back ). Además, pues-

to que todo procesamiento en el que intervienen componentes del servidor

debe ejecutarse en el propio servidor, cada vez que se requiere dicho proce-

samiento el formulario debe enviarse al servidor, que éste lo procese y final-

mente lo devuelva de nuevo al navegador. Esta secuencia de eventos es co-

nocida habitualmente como Round trip (ver Figura 36).

En Web Forms la mayoría de acciones de usuario, como hacer clic en un

botón, dan como resultado un round trip . Por esa razón, los controles de

servidor sólo exponen eventos de tipo clic, i.e. eventos que requieren de una

acción explícita del usuario. Por razones obvias, los controles de servidor no

exponen eventos que se producen con mucha frecuencia, como onmouseover ,para evitar round trips que penalizarían el rendimiento de la aplicación.

En Web Forms también puedecrearse código de script ejecu-table en el navegador cliente.

Esto es útil para la validaciónde datos introducidos por elusuario en el formulario, por ejemplo. Este tipo de códigoscript no interactúa con com-ponentes de servidor.




Puesto que las páginas se reconstruyen con cada round trip , el servidor no

necesita mantener la información de la página una vez que ha finalizado su

procesamiento y la ha enviado al navegador. Es decir, el servidor no mantie-

ne el estado y la próxima vez que se solicite la página ésta será reprocesada

de nuevo. Al liberarse los recursos del servidor tras cada solicitud, una aplica-

ción Web puede escalarse a un gran número de usuarios simultáneos.

En una aplicación Web tradicional, la única información de un formulario

que el servidor almacena es la información que introducida por el usuario enlos diversos controles de la página, puesto que dicha información se envía al

servidor cuanto se le devuelve el formulario. Cualquier otra información,

como valores de variables o de propiedades, se descarta. ASP.NET palia las

limitaciones derivadas de todo lo anterior de diversas formas:

Almacena las propiedades de la página y de los controles entre round

trips . Esto se conoce habitualmente como almacenar el view state de los

controles.

Proporciona mecanismos de gestión del estado, de forma que el progra-

mador pueda conservar el valor de las variables y otra información propia

de la aplicación o la sesión entre round trips .

Permite detectar cuando un formulario es solicitado por primera vez o

cuando no ( post back ) y programar comportamientos diferentes en cada

caso, si es necesario.

4.1.2. Etapas de procesamiento

A lo largo de cada etapa del procesamiento de un formulario pueden lanzarse

eventos y por lo tanto pueden ejecutarse métodos de atención a los mismos.Estos métodos proporcionan “puntos de entrada” que permiten que la pág i-

na pueda manipularse desde el código.

El servidor puede configurarsepara que utilice una caché depáginas con el fin de mejorar el rendimiento. Sin embargo,es preferible pensar que elservidor descarta las páginasuna vez ha acabado de proce-sarlas.

Figura 36. Ciclo de vida de una página Web Form (Round trip ).




A continuación se resumen las etapas más comunes del procesamiento, los

eventos que se producen en cada una de ellas, así como los usos habituales

de dichos eventos. Las etapas se repiten cada vez que la página se solicita o se

produce un round trip .

Es importante destacar que en el procesamiento de páginas Web Forms exis-

ten más etapas que las anteriores. Sin embargo, dichas etapas se usan princi-

palmente para que los propios controles se inicialicen y visualicen. Por tanto

el programador raramente necesita acceder a ellas. Excepción hecha del caso

en el que el programador esté desarrollando sus propios controles de servidor

(ver apartado “Controles personalizados”).

Inicialización del entorno de ejecución de la página . Se lanza el evento

Page_Init y se restaura el valor del view state de la página. Durante este evento

el entorno de ejecución de la página restaura las propiedades y los datos delos controles.

Inicialización del código de usuario. Se lanza el evento Page_Load. Mediante

la propiedad Page.IsPostBack puede saberse si es la primera vez que se carga la

página o se trata de un post back . Si la página se carga por primera vez se

realiza el enlace de datos, si lo hay. Si se trata de un post back se restauran

los valores en los controles y se actualizan las propiedades que lo requieran.

Validación. Se invoca al método Validate() de los controles de validación pre-

sentes en la página. Esta etapa no es accesible para el programador. El resul-

tado de la validación puede consultarse en la siguiente etapa mediante un

método de atención a eventos. Veremos más sobre validación de datos en el

apartado “Validación de datos”.

Atención a eventos. Si la página se invocó en respuesta a un evento del for-

mulario, el método de atención a dicho evento se invoca en esta etapa. Es

importante destacar que los eventos no se lanzan en ningún orden en parti-

cular, salvo los eventos de controles con la propiedad AutoPostBack a cierto,

que se lanzan antes que el resto. En esta etapa el programador típicamenterealiza alguna de las siguientes tareas:

Si la página contiene controles de validación de servidor, se comprueba la

propiedad IsValid de la página y de los controles individuales para actuar en

consecuencia.

Si se está manteniendo explícitamente el estado de algunas variables, este es

el momento de salvar sus valores.

Salvar el estado de los controles que se hayan añadido dinámicamente en

esta etapa.

Limpieza. Se lanza el evento Page_Unload puesto que se ha completado laconstrucción de la página par enviarla al navegador cliente y, en consecuen-

cia, el servidor ya puede descartarla. El programador puede aprovechar esta




etapa para: cerrar archivos abiertos, cerrar conexiones con bases de datos,

descartar objetos, etc. Es muy importante que recursos como los citados se

liberen explícitamente en esta etapa y no se espere a que el procedimiento de

recolección de basura de la memoria lo haga. En un servidor que deba sopor-

tar cierta carga, no hacerlo puede afectar seriamente al rendimiento.

4.2. Formularios HTML y Web Forms

Un formulario HTML es un área de una página Web delimitada por las mar-

cas <form> y </form>, en la que pueden introducirse elementos HTML para

solicitar datos (e.g. input, select, textarea, …). Aunque una misma página puede

contener diversos formularios HTML, no es habitual tener más de uno. El

elemento form de HTML admite principalmente dos atributos: action, que

determina a qué URL se enviará la información del formulario, y method que

indica el método usado en la solicitud. En el caso de ASP.NET action apuntaráa la página .aspx encargada de procesar los datos del formulario, mientras que

method es generalmente post, de forma que los datos se envían incrustados en

el cuerpo de la solicitud HTTP y no como parámetros en la URL.

El motor de ASP.NET puede procesar cualquier formulario HTML, incluso en

el caso en que el formulario no forme parte de una página .aspx. La Figura 37

muestra el código de un formulario HTML sencillo al que hemos llamado

Ejemplo.html. En él cabe destacar el atributo action por el que se indica el desti-

no de los datos, i.e. la página Ejemplo_Procesado.aspx (ver Figura 38). Para el

envío de los datos no se utiliza ninguna característica específica del sistema

operativo, ni del navegador, ni de ASP.NET, sino simplemente HTTP y HTML

estándar. De hecho, el navegador no tiene conocimiento del contenido de

los datos en ningún momento, sino que su función consiste únicamente en

enviarlos según el método indicado en el formulario y esperar la respuesta

del servidor.

Aunque, como veremos posteriormente, puede accederse a los datos de un

formulario de manera muy sencilla usando Web Forms , el siguiente meca-

nismo de “bajo nivel” nos permitirá también procesar datos de cualquierformulario HTML. Para ello usaremos una propiedad de la clase Page llamada

Request (un objeto de la clase HttpRequest) que permite acceder directamente a

El estándar HTTP define me-canismos para el envío dedatos desde formulariosHTML. Por lo tanto esta posi-bilidad no es exclusiva de ASP.NET.

ASP.NET puede procesar cualquier formulario HTML.

<html><body>

<h1>Forumulario de registro</h1><form action="Ejemplo_procesado.aspx" method="post">

<p> Nombre: <input id="Nombre" type="text" /> </p><p> Apellidos: <input id="Apellidos" type="text" /> </p><p> Teléfono: <input id="Telefono" type="text" /> </p><p> <input type="submit" value="Registrar" /> </p>

</form></body>

</html>

Figura 37. Procesado de formularios con ASP.NET: formulario HTML.




la solicitud hecha por el cliente. En particular accederemos a algunas de sus

propiedades como RequestType, QueryString o Form.

Si desconocemos el origen de la solicitud podemos usar la propiedad Request-

Type para saber cómo se ha enviado el formulario, es decir, si se ha usado el

método GET o el método POST de HTTP. En el primer caso los datos pueden

recuperarse accediendo a la propiedad QueryString, mientras que en el segundo

caso usaremos la propiedad Form.

Una cadena de consulta (query string ) es una cadena de caracteres con in-

formación añadida al final de la URL de una página. Por ejemplo en la si-

guiente URL la cadena comienza tras el interrogante. Así pues la cadena con-

tiene tres pares atributo-valor.

La propiedad QueryString permite acceder a la cadena de consulta adjunta a la

URL de la solicitud, en la que habrá tantas parejas atributo-valor como con-

troles en el formulario.

Por su parte la propiedad Form es una colección en la que cada elemento

tiene como índice el nombre de un control del formulario y como valor el

contenido de dicho control. Así, si en el formulario existiese un cuadro de

texto llamado Telefono, podríamos acceder al valor introducido por el usuario

en el formulario de la siguiente forma:

Una forma alternativa e independiente del método usado para la solicitud

consiste en usar la colección Params, que permite acceder además a las cookies

y a las variables del servidor, de la siguiente forma:

La Figura 38 muestra el código de la página Ejemplo_Procesado.aspxque enumera

todos los parámetros enviados por el formulario.

http://www.contoso.com/listwidgets.aspx?type=basic&price=500&madeof=steel

Request.Form[―Telefono‖]

Request.Params[―Telefono‖]

<%@ Page language="c#" %><html>

<script runat="server">void Page_Load(Object sender, EventArgs e) {

foreach(string Elem in Request.Form)Response.Write("<br>" + Elem + " : " + Request.Form[Elem] + "</br>");

}

</script></html>

Figura 38. Procesado de formularios con ASP.NET: procesado.




Tal como hemos visto, ASP.NET ofrece mecanismos suficientes para el proce-

sado de formularios HTML estándar. Sin embargo, lo realmente interesante

es usar los Web Forms y los controles Web de servidor. En tal caso, serán los

propios controles, quienes al ejecutarse en el servidor, serán capaces de man-

tener su estado entre solicitudes y de almacenar los valores introducidos por

el usuario y exponerlos al programador de forma sencilla. El código de la

Figura 39 muestra la forma de crear con Web Forms el mismo formulario que

en la Figura 37. En este caso, sin embargo, podemos acceder directamente a

los valores de los controles mediante sus propiedades. Por ejemplo, al escribirNombre.Text obtenemos el texto introducido en el cuadro de texto Nombre. La

Figura 40 muestra el resultado de la ejecución. El resultado es el mismo tanto

si se emplea un formulario HTML como si se emplea un formulario Web

Forms.

<html><script runat="server">void Page_Load(Object sender, EventArgs e) {

if (!Page.IsPostBack) return;Response.Write("<br> Nombre : " + Nombre.Text + "</br>");

Response.Write("<br> Apellidos : " + Apellidos.Text + "</br>");Response.Write("<br> Telefono : " + Telefono.Text + "</br>");

}</script><body>

<h1>Formulario de registro</h1><form runat=server>

<p> Nombre: <asp:TextBox id="Nombre" runat=server /> </p><p> Apellidos: <asp:TextBox id="Apellidos" runat=server /> </p><p> Teléfono: <asp:TextBox id="Telefono" runat=server /> </p><p> <asp:Button id="BotonRegistro" Text="Registrar" runat=server /> </p>

</form></body>

</html>

Figura 39. Procesado de formularios ASP.NET: Web Forms.

Figura 40. Procesado de formularios ASP.NET: ejecución.




4.3. Validación de datos

Cualquier aplicación, sea para la Web o no, necesita comprobar que los datos

introducidos por el usuario cumplen determinados criterios de validez que

permitirán que la aplicación se ejecute adecuadamente. En una aplicación

Web, las comprobaciones se ejecutarían en el servidor una vez que este

hubiese recibido los datos del formulario. En tal caso, ante un error en los

datos, éste se indicaría al usuario mediante un reenvío de la página, quedan-

do el servidor a la espera de la corrección, y así sucesivamente. Es evidente,

que si el conjunto de datos a verificar fuese grande, el número de solicitudes

y reenvíos podría comprometer considerablemente el rendimiento de la

aplicación.

La mayoría de validaciones de datos no son excesivamente complejas o no

requieren de acceso a otra información fuera del formulario. Así, para mini-mizar la citada bajada de rendimiento, es habitual que la propia interfaz de

usuario incorpore lógica (normalmente JavaScript) que permita la realización

de ciertas validaciones en el propio navegador cliente, antes de enviar los

datos al servidor. Aunque siempre es posible escribir código de validación “a

mano”, lo más indicado es recurrir a los controles de validación que propor-

ciona ASP.NET, de forma que la validación se lleve a cabo automáticamente.

Todos los controles de validación de una página ASP.NET forman parte au-

tomáticamente de una colección de tipo ValidatorCollection en el objeto Page,

que es accesible mediante la propiedad de sólo lectura Validators. La validación

se desencadena al invocarse el método Validate() de la clase Page, bien explíci-

tamente o bien indirectamente a través de algún control del formulario con

la propiedad CausesValidation con valor true. Esta propiedad se encuentra en

controles como Button, ImageButton y LinkButton con valor por defecto true, lo

que significa que al hacer clic en cualquier botón del formulario se validarán

los datos y sólo se enviarán los datos al servidor si la validación es satisfacto-

ria. En todo caso, el método Validate() recorre la lista Validators y ejecuta la vali-

dación indicada por cada control. Si alguna validación falla la propiedad

IsValid de Page toma el valor false lo que permite al programador diseñar accio-nes específicas en reacción a las situaciones de error.

Como veremos, existen controles para tipos concretos de validación, como

la comprobación de intervalos o la coincidencia con un patrón, además de

RequiredFieldValidator , que permite detectar situaciones en las que un usuario

haya omitido un campo de entrada obligatorio. Adicionalmente se puede

adjuntar más de un control de validación para un mismo control de entrada

de datos. Por ejemplo, se puede especificar que es obligatorio introducir un

dato y que éste debe pertenecer a un intervalo específico de valores.

Los controles de validación sólo funcionan con un subconjunto de controles

de servidor HTML y Web. Para cada control, una propiedad específica con-

Controles de validación en

Visual Studio 2005




tiene el valor que se va a validar. La siguiente tabla enumera los controles de

entrada que pueden validarse y la propiedad sobre la que actúa la validación:

Control Propiedad de validación

HtmlInputText Value HtmlTextArea Value

HtmlSelect Value

HtmlInputFile Value

TextBox Text

ListBox SelectedItem.Value

DropDownList SelectedItem.Value

RadioButtonList SelectedItem.Value

4.3.1. Tipos de controles de validación

La forma más sencilla de validación son los campos requeridos, es decir la

verificación de que un determinado control no quede vacío. Si el usuario

introduce algún valor en un campo, éste es válido. Si todos los campos del

formulario son válidos, la página es válida. En un control de validación de

tipo RequiredFieldValidator es imprescindible establecer dos propiedades: Control-

ToValidate en la que se indica a qué control afecta la validación; y ErrorMessage

en la que se especifica el mensaje que debe mostrarse en la página si el usua-

rio intenta enviar el formulario sin introducir un valor en el campo validado.

Si añadimos el código de la Figura 41 al formulario de la Figura 39 consegui-

remos que el usuario no pueda enviar el formulario si no especifica un valor

en el campo Teléfono.

El motor de ASP.NET substituye la marca asp:RequiredFieldValidator por instruc-

ciones JavaScript y atributos que se añaden al formulario y al botón que

desencadena la validación. La Figura 42 muestra parte del código de la pági-

na que recibe el navegador, donde se observa cómo se usa el evento onsubmit

para invocar una función JavaScript antes de realizar el envío de los datos alservidor. Además la marca se ha substituido por una marca span de HTML,

inicialmente oculta, en la que se mostrará el texto de error en caso necesario.

<html>… <body>… <form runat=server>

…

<asp:RequiredFieldValidator id="Validator3" ControlToValidate="Telefono"runat="server" ErrorMessage="Debe introducir un número de teléfono" />…

</form></body>

</html>

Figura 41. RequiredFieldValidator para el ejemplo de la Figura 39.




Al margen de este tipo de validación sencilla, también hay controles de vali-

dación para tipos de validación específicos, como la comprobación de inter-

valos o la coincidencia con patrones. A continuación resumimos los diversos

tipos de validación:

<html><body><h1>Formulario de registro</h1><form name="Form1" method="post" action="Ejemplo.aspx"

language="javascript" onsubmit="if (!ValidatorOnSubmit()) return false;" id="Form1">

<input type="hidden" name="_VIEWSTATE"value="dDwtMTE5ODk3NjE1MTs7PlT1fO6A9Nmlf9lBjO6D3Svdtvf2" />

<script language="javascript" type="text/javascript"src="/aspnet_client/system_web/1_1_4322/WebUIValidation.js"></script>

…

<p> Teléfono: <input name="Telefono" type="text" id="Telefono" /><span id="Validator3" controltovalidate="Telefono"

errormessage="Debe introducir un número de teléfono"evaluationfunction="RequiredFieldValidatorEvaluateIsValid" initialvalue=""style="color:Red;visibility:hidden;">Debe introducir un número de teléfono</span>

</p>

<p> <input type="submit" name="BotonRegistro" value="Registrar"onclick="if (typeof(Page_ClientValidate) == 'function') Page_ClientValidate(); "language="javascript" id="BotonRegistro" />

</p>


var Page_Validators = new Array(document.all["Validator1"],document.all["Validator2"], document.all["Validator3"]);

// --></script>


var Page_ValidationActive = false;

if (typeof(clientInformation) != "undefined" &&clientInformation.appName.indexOf("Explorer") != -1) {if (typeof(Page_ValidationVer) == "undefined")

alert("Unable to find script library'/aspnet_client/system_web/1_1_4322/WebUIValidation.js'. Try placing thisfile manually, or reinstall by running 'aspnet_regiis -c'.");

else if (Page_ValidationVer != "125")alert("This page uses an incorrect version of WebUIValidation.js. The page expects

version 125. The script library is " + Page_ValidationVer + ".");else ValidatorOnLoad();

}

function ValidatorOnSubmit() {if (Page_ValidationActive) {

return ValidatorCommonOnSubmit();}return true;

}// --></script>

</form></body>

</html>

Figura 42. RequiredFieldValidator: página que recibe el navegador.




RequiredFieldValidator: Permite asegurar que el usuario no omite la entrada de

un dato en un control.

CompareValidator : Compara una entrada de usuario con un valor constante

o un valor de propiedad de otro control mediante un operador de compa-

ración (menor que, igual a, mayor qué, etc.).

RangeValidator : Comprueba que una entrada de usuario se encuentra entre

los límites superior e inferior especificados. Se pueden comprobar los in-

tervalos entre pares de números, caracteres alfabéticos o fechas. Los lími-

tes se pueden expresar como constantes.

RegularExpressionValidator : Comprueba que la entrada coincide con un patrón

definido por una expresión regular. Este tipo de validación permite com-

probar secuencias de caracteres previsibles, como las de los códigos posta-

les, las direcciones de correo electrónico, etc.

CustomValidator : Comprueba la entrada del usuario mediante lógica de vali-

dación especificada por el programador. Este tipo de validación permitecomprobar los valores generados en tiempo de ejecución.

ValidationSummary: Muestra los errores de validación en forma de resumen

para todos los validadores de la página.

4.3.2. Validación en el cliente

Los controles de validación que hemos citado anteriormente siempre reali-zan la validación mediante código ejecutado en el servidor. No obstante, si el

usuario trabaja con un navegador que admite DHTML, los controles de vali-

dación también pueden realizar validaciones mediante código script ejecuta-

ble por el navegador. Cuando se hace validación en el cliente, los errores se

detectan antes de enviar el formulario al servidor. Si alguna de las validacio-

nes no se supera, el envío del formulario al servidor se interrumpe y en su

lugar se muestra la propiedad Text del validador correspondiente. Los valores

de los campos se revalidan en cuanto el campo que contiene el error pierde

el foco, proporcionando una experiencia de validación interactiva al usuario.

Es importante destacar que el motor de Web Forms siempre realiza la valida-

ción en el servidor, incluso cuando ya se ha realizado en el cliente. De esta

forma, se evita que los usuarios puedan omitir la validación mediante la

suplantación de otro usuario o de una transacción previamente aprobada.

La validación en el cliente es el comportamiento por defecto. Si el cliente lo

permite, la validación de alto nivel se realiza automáticamente. Para deshabi-

litar la validación en el cliente, basta con establecer la propiedad ClientTarget

de la página en "Downlevel" ("Uplevel" fuerza la validación en el cliente).

Todos los controles de valida-ción derivan de la clase Base- Validator definida en el espa-cio de nombresSystem.Web.UI.WebControls.

Se recomienda realizar la actividad 1 antes de continuar.




4.3.3. Visualización de errores de validación

Tal como hemos visto en los ejemplos anteriores, si falla un control de vali-

dación puede mostrarse un mensaje de error en el lugar ocupado por el con-

trol en la página. Por otra parte, también pueden mostrarse varios errores (o

todos) agrupados en cualquier lugar de la página mediante un control Valida-

tionSummary. El control ValidationSummary recoge los mensajes de error de todos

los controles de validación de la página y los visualiza si la propiedad IsValid

de la página es false.

La Figura 43 muestra el código resultante al añadir un control ValidationSumma-

ry al ejemplo. Para evitar que el resto de los validadores también muestren el

mensaje de error de forma redundante, se ha modificado su propiedad Text

para que, en caso de no validación, únicamente muestren un asterisco. La

Figura 44 muestra el resultado de la ejecución.

<html><body>… <form runat="server">

… <p> Teléfono: <asp:TextBox id="Telefono" runat="server" />

<asp:RequiredFieldValidator id="Validator3" runat="server"ErrorMessage="Debe introducir un número de teléfono"ControlToValidate="Telefono" Text="*" />

</p>

… <asp:ValidationSummary id="ValidationSummary1" runat="server" Height="72px" Width="288px"></asp:ValidationSummary>

… </form>

</body></html>

Figura 43. Uso de ValidationSummary para el ejemplo de la Figura 39.

Figura 44. RequiredFieldValidator y ValidationSummary en acción.




4.3.4. Validación relacional y de rangos

Además de forzar que un control de entrada de datos contenga un valor,

también es posible comprobar si el valor introducido guarda algún tipo de

relación con un valor de referencia (CompareValidator ) o si el valor está dentro

de un rango de valores predeterminados (RangeValidator ).

El operador de comparación para un CompareValidator se indica mediante la

propiedad Operator de éste, cuyos valores pueden ser: Equal, NotEqual, LessThan,

LessThanEqual, GreaterThan, GreaterThanEqual y DataTypeCheck. El valor de referencia

para los primeros seis operadores se especifica directamente en la propiedad

ValueToCompare del validador, o bien indirectamente mediante el valor alma-

cenado en el control indicado por la propiedad ControlToCompare . Finalmente,

el operador DataTypeCheck es muy interesante puesto que permite validar si el

dato introducido es de un tipo de datos concreto, el especificado en la pro-piedad Type del validador. La propiedad Type indica si el valor debe ser un

número entero, un número real, una fecha, etc.

Por otra parte, el intervalo de un RangeValidator se especifica mediante las pro-

piedades MinimumValue y MaximumValue. El intervalo indica qué valores puede

tomar el control indicado por la propiedad ControlToValidate del validador. El

código de la Figura 45 añade al ejemplo la comprobación de que el teléfono

introducido sea un número entero.

4.3.5. Expresiones regulares

Es frecuente que la validación de datos requiera de comprobaciones más

complejas que la simple comparación con un valor o un rango de referencia.

Aunque siempre puede recurrirse a una validación totalmente personalizada

(ver siguiente apartado), a menudo puede caracterizarse el conjunto de valo-

res válidos para un campo mediante una expresión regular.

En ASP.NET el control de servidor RegularExpressionValidator permite comprobar

la correspondencia de una secuencia de caracteres respecto a una expresión

regular: como las de los números de la seguridad social, las direcciones de

correo electrónico, los números de teléfono, los códigos postales, etc. Regula-

Una expresión regular, amenudo llamada tambiénpatrón, es una expresión quedescribe un conjunto decadenas de caracteres sinenumerar sus elementos. Por ejemplo, el grupo formadopor las cadenas Handel,Händel y Haendel se puededescribir mediante el patrón"H(|ä|ae?)ndel". Algunoslenguajes de programacióncomo Perl tienen un ampliosoporte a la manipulación deexpresiones regulares.


… <asp:CompareValidator id="CompareValidator1" ControlToValidate="Telefono"

ErrorMessage="El teléfono debe ser un número" Operator="DataTypeCheck"Type="Integer" runat="server" />

… </form>

</body></html>

Figura 45. Uso de CompareValidator para el ejemplo de la Figura 39.




rExpressionValidator utiliza dos propiedades clave para realizar la validación:

ControlToValidate, que contiene el valor que hay que validar; y ValidationExpression

que contiene el patrón con el que el valor debe coincidir. El patrón debe

seguir las normas de las expresiones regulares de JavaScript, similares a las

del espacio de nombres System.Text.RegularExpressions, o a las del lenguaje de

programación Perl.

El código de la Figura 46 añade al ejemplo la comprobación de que el núme-

ro de teléfono introducido siga el patrón +34-934317015 en el que se especi-

fica el código del país seguido del número de teléfono.

Aunque permite la edición manual de expresiones regulares, Visual Studio

incorpora también una lista de expresiones predefinidas (ver Figura 47).

4.3.6. Validación personalizada

En última instancia cabe la posibilidad de escribir una función de validación

que lleve a cabo cualquier tipo de validación, por compleja que sea, y que los

controles de validación anteriores no puedan llevar a cabo. Dicha función

deberá vincularse al control correspondiente del formulario mediante el

control CustomValidator y su propiedad ControlToValidate. La función debe pre-

sentar la siguiente signatura: function myvalidator(source, arguments), donde source

es el objeto CustomValidator del cliente y arguments es un objeto con dos propie-

dades, Value e IsValid. La propiedad Value es el valor que se validará y la propie-

<html><body>…

<form runat="server">… <asp:RegularExpressionValidator id="RegularExpressionValidator1" runat="server"

ErrorMessage="Número de teléfono no válido" ControlToValidate="Telefono" ValidationExpression="\+(\d{1}|\d{2})-\d{9}" />

… </form>

</body></html>

Figura 46. Uso de RegularExpressionValidator para el ejemplo de la Figura 39.

Figura 47. Asistente de expresiones regulares en Visual Studio .NET.




dad IsValid es el booleano utilizado para establecer el resultado devuelto de la

validación.

Si se desea que la validación suceda en el servidor para así poder programarla

en cualquier lenguaje que estemos usando junto a ASP.NET, deberá asignar elmétodo delegado a la propiedad OnServerValidate. La Figura 48 muestra el códi-

go resultante para el control CustomValidator . En este caso, la validación consis-

te en comprobar si el nombre de usuario coincide con “Paco” y se ha imple-

mentado mediante code-behind en C#. El resultado de la validación se

notifica a la página mediante el valor de la propiedad IsValid. Puesto que la

validación sucede en el servidor, ésta no tiene lugar hasta que se produce el

envío del formulario al servidor y, por tanto, todas las validaciones realiza-

bles por el navegador cliente ya hayan tenido lugar. Asimismo los posibles

mensajes de error de la validación no se harán visibles hasta que se complete

el round trip .

Por otra parte, si lo que se desea es que la validación suceda completamente

en el navegador del cliente, deberemos programar la función de validación

usando un lenguaje de script como Javascript, JScript o VBScript. El nombre

de la función de validación personalizada debe identificarse en la propiedad

ClientValidationFunction. La Figura 49 muestra un ejemplo de validación en el

cliente mediante una función escrita en Javascript.

Para concluir este punto cabe destacar que ASP.NET permite combinar am-

bos tipos de validación. Es decir, es posible asignar una función de valida-

ción ejecutable en el cliente mediante la propiedad ClientValidationFunction y

Parte de archivo .aspx


… <asp:CustomValidator id="CustomValidator1" runat="server"

ControlToValidate="Nombre"OnServerValidate="CustomValidator1_ServerValidate"ErrorMessage="Tu no eres Paco!" EnableClientScript="False">*

</asp:CustomValidator>…

</form></body>

</html>

Parte del archive .aspx.cs que contiene la function de validación

public void CustomValidator1_ServerValidate(object source,System.Web.UI.WebControls.ServerValidateEventArgs args)

{args.IsValid=!((args.Value!="") && (args.Value!="Paco"));

}

Figura 48. Uso de CustomValidator en el servidor para el ejemplo de la Figura 39.




una función de validación ejecutable en servidor mediante la propiedad

OnServerValidate al mismo tiempo. Si ambas propiedades tienen funciones

asignadas y la propiedad EnableClientScript tiene valor true, ASP.NET y el nave-

gador cliente negociarán el tipo de validación, dando preferencia la valida-

ción en el navegador.

4.4. Enlace a datos (Data Binding)

ASP.NET proporciona una sintaxis declarativa de enlace a datos que permite

al programador enlazar no sólo con orígenes de datos, sino también con

propiedades simples, colecciones, expresiones e incluso con resultados dellamadas a métodos. La siguiente tabla muestra algunos ejemplos:

Propiedad simple Cliente: <%# custID %>

Colección Pedidos: <asp:ListBox id="List1" datasource='<%# myArray %>'runat="server">

Expresión Contacto: <%# ( cliente.Nombre + " " + cliente.Apellido ) %>

Resultado de método Balance: <%# ObtenerBalance(custID) %>

El enlace a datos de ASP.NET se evalúa cuando se invoca al método DataBind(). Éste es un método de Page y de todos los controles de servidor. Cuando se

llama a DataBind() en un control, la llamada se produce en cascada a todos los

<html> <script language="javascript">

function ClientValidation(source, arguments){

if ((arguments.Value!="") && (arguments.Value!="Paco"))arguments.IsValid = false;

elsearguments.IsValid = true;

}

</script><body>… <form runat="server">

… <asp:CustomValidator runat="server" ControlToValidate="Nombre"

ErrorMessage="Tu no eres Paco!" id="CustomValidator1"EnableClientScript="True" ClientValidationFunction="ClientValidation">*

</asp:CustomValidator>…

</form></body>

</html>

Figura 49. Uso de CustomValidator en el cliente para el ejemplo de la Figura 39.

Se recomienda realizar la actividad 2 y la actividad 3 antes de con-

tinuar.




controles relacionados con dicho control. Así por ejemplo DataList1.DataBind()

invoca al método DataBind() en cada control de las plantillas de DataList. Por

otra parte, al invocar a DataBind() en Page (Page.DataBind() o simplemente Data-

Bind()) todas las expresiones de enlace a datos de la página se evalúan. Data-

Bind() suele invocarse desde el evento Page_Load.

Una expresión de enlace a datos puede usarse casi en cualquier parte de la

sección declarativa de una página .aspx. Los anteriores ejemplos de propiedad

simple, expresión y método muestran texto al usuario cuando se evalúan. En

estos casos, la expresión de enlace a datos debe evaluar a un valor de tipo

String. En el ejemplo de la colección, la expresión de enlace a datos evalúa a

un valor de tipo válido para la propiedad DataSource de la clase ListBox.

4.4.1. Enlaces a datos habituales

El enlace a datos de ASP.NET permite el enlace con variables públicas, pro-

piedades de Page y propiedades de otros controles de la página. El ejemplo de

la Figura 50 muestra cómo enlazar con una variable pública y una propiedad

simple de la página. Debe observarse que estos valores se inicializan antes de

llamar a DataBind().

Los controles de servidor que utilizan algún tipo de lista, como DataGrid, List-

Box y HTMLSelect, utilizan una colección como origen de datos. Lo más habi-

tual es el enlace de estos controles con objetos de las clases ArrayList, Hashtable,

DataView y DataReader . La Figura 51 muestra un ejemplo de enlace entre un

control DropDownList y una colección de tipo ArrayList. La Figura 52 muestra el

resultado de la ejecución del ejemplo.

<html>

<script language="C#" runat="server">void Page_Load(Object sender, EventArgs e) {Page.DataBind();

}

string IDCliente{get { return ("CLI145"); }

}

int NumPedidos{get { return (15); }

}</script><body>

<form runat=server ID="Form1">

Cliente: <b><%# IDCliente %></b><br>Número de pedidos: <b><%# NumPedidos %></b></form>

</body></html>

Figura 50. Enlace de datos con propiedades simples.




Finalmente destacar que a menudo se desea manipular los datos antes de

enlazar con la página o con un control. El ejemplo de la Figura 53 muestra

también cómo enlazar con una expresión y con el valor devuelto por un

método.


void Page_Load(Object Sender, EventArgs E) {if (!Page.IsPostBack) { ArrayList values = new ArrayList();values.Add ("Paella"); values.Add ("Sopa");values.Add ("Solomillo"); values.Add ("Lenguado");DropDown1.DataSource = values;DropDown1.DataBind();

}}

void SubmitBtn_Click(Object sender, EventArgs e) {Label2.Text = "Has elegido: " + DropDown1.SelectedItem.Text;

}</script><body>

<form runat="server" id="Form1"><asp:Label id="Label1" runat="server" Text="Elige tu plato:" />

<p><asp:DropDownList id="DropDown1" runat="server" /><asp:button Text="Submit" OnClick="SubmitBtn_Click" runat="server"

id="Button1" /></p><p>

<asp:Label id="Label2" runat="server" /></p>

</form></body>

</html>

Figura 51. Enlace de datos con una colección de tipo ArrayList.

Figura 52. Enlace de datos con una colección de tipo ArrayList: ejecución.





4.4.2. Visual Studio

Visual Studio proporciona diversos controles específicos para facilitar el acce-

so a fuentes de datos y para realizar enlace a datos de una forma bastante

automática e intuitiva mediante asistentes. Destaca por ejemplo el control

GridView para mostrar datos en forma de hoja de cálculo, completamente

adaptable de las necesidades del desarrollador (ver Figura 54). En la URL

http://www.asp.net/QuickStart/aspnet/doc/data/databases.aspx puede encontrarse

un tutorial muy práctico sobre cómo usar el control GridView.

Controles de datos en VisualStudio 2005


void Page_Load(Object Src, EventArgs E) {if (!Page.IsPostBack) { ArrayList values = new ArrayList();

values.Add (0);values.Add (1);values.Add (2);values.Add (3);values.Add (4);values.Add (5);values.Add (6);DataList1.DataSource = values;DataList1.DataBind();

}}

String ParOImpar(int num) {return ( (num%2==0) ? "par" : "impar" );

}

</script><body><form runat=server ID="Form1">

<asp:DataList id="DataList1" runat="server" BorderWidth="2" GridLines="Both"CellPadding="4" >

<ItemTemplate>El número <%# Container.DataItem %>es <%# ParOImpar((int) Container.DataItem) %>

</ItemTemplate></asp:Datalist>

</form></body>

</html>

Figura 53. Enlace de datos con una colección de tipo ArrayList y con un método.

Figura 54. Aspecto de un GridView en tiempo de diseño.




5. Aplicaciones Web

El objetivo de este apartado es profundizar en el concepto de aplicación Web

de ASP.NET así como los mecanismos para su gestión. Se entiende por apli-

cación el conjunto de páginas HTML, formularios Web y sus recursos asocia-

dos, es decir, todo aquello que se encuentre alojado en el directorio virtual

del servidor Web correspondiente. Para lograr el objetivo analizaremos, en

primer lugar, el concepto de aplicación Web desde el punto de vista de

ASP.NET, repasando los principales objetos implicados, los distintos estados

por los que pasa una aplicación a lo largo de su ciclo de vida, etc. A conti-

nuación estudiaremos el archivo Global.asax mediante el cuál es posible alma-

cenar información, definir métodos de control de eventos, etc. de formageneral a toda la aplicación. A continuación estudiaremos en detalle los me-

canismos que proporciona una aplicación para solventar un problema clási-

co en las aplicaciones Web, la gestión del estado, bien sea entre solicitudes,

sesiones, o a nivel de toda la aplicación. Finalmente se estudiará el sistema

de configuración de las aplicaciones ASP.NET, analizando el contenido de los

archivos de configuración Web.config y su uso desde programa.

5.1. Aplicaciones Web ASP.NET

Una aplicación Web ASP.NET se define como el conjunto de todas las pági-nas HTML, páginas .aspx, archivos XML, código ejecutable, etc. que pueden

invocarse o ejecutarse dentro del ámbito de un determinado directorio vir-

tual en un servidor de aplicaciones Web.

Cada aplicación de un servidor Web se ejecuta de forma segura dentro de un

dominio único de aplicación ( AppDomain) del entorno de ejecución de .NET.

Esto garantiza, el aislamiento de clases (no se producen conflictos de nom-

bres o versiones), el uso seguro de recursos (se impide el acceso a determina-

dos equipos o recursos de red) y el aislamiento de variables estáticas, entre

otras cosas.

El concepto de aplicación se expone al programador mediante el objeto Appli-

cation (ver apartado “Gestión del estado”). Puede usarse este objeto, por

ejemplo, para almacenar otros objetos con visibilidad global a toda la aplica-

ción, es decir, accesibles por todas las páginas y formularios que la compo-

nen. Por otra parte, la creación de un archivo Global.asax (ver apartado “El

archivo Global.asax”) en la raíz del directorio virtual de la aplicación, permi-

tirá, entre otras cosas, la definición de diversos métodos controladores de

eventos, por ejemplo para los eventos de inicio y finalización de una aplica-ción.

Los dominios de aplicación,representados por objetos dela clase AppDomain, propor-cionan al entorno de ejecu-ción de .NET aislamiento yfronteras de seguridad para laejecución del código dedistintas aplicaciones simulta-neamente.




A lo largo del tiempo en que una aplicación Web está en ejecución, ésta debe

poder gestionar diversas conexiones concurrentes de uno o múltiples usua-

rios. Esta flexibilidad, debida al desacoplamiento entre el navegador cliente

de la aplicación y el servidor, presenta algunas problemáticas cuando se trata

de mantener datos globales a toda la aplicación. Por ejemplo un histórico

con datos de clientes en una tienda virtual. Es más, aún en una misma se-

sión para un usuario se plantea el problema del mantenimiento del estado

entre solicitudes consecutivas. Para comprender mejor los mecanismos que

ASP.NET ofrece al programador para tomar el control en dichas situaciones,

examinaremos seguidamente el ciclo de vida de una aplicación.

5.1.1. Ciclo de vida

ASP.NET mantiene un conjunto de instancias de la clase HttpApplication a lo

largo del ciclo de vida de una aplicación Web. ASP.NET asigna automática-mente una de estas instancias para procesar cada solicitud HTTP entrante

recibida por la aplicación. La instancia concreta de la clase HttpApplication

asignada a la solicitud es responsable del procesamiento de la solicitud a lo

largo de todo su período de duración y sólo se puede reutilizar después de

que la solicitud se haya completado. Esto significa, entre otras cosas, que el

código de usuario incluido en una instancia HttpApplication no necesita ser

reentrante, y que las variables miembros de una instancia pueden usarse para

almacenar datos a lo largo de una petición.

La puesta en marcha y el procesamiento de las distintas solicitudes que se

suceden en una aplicación de ASP.NET sigue las etapas descritas a continua-

ción (ver Figura 55):

Se dice que un programa esreentrante si está diseñado deforma que una sola copia delprograma en memoria puedacompartirse por múltiplesusuarios y/o diferentes proce-sos. Una de las claves paraconstruir programas reentran-tes es que las variables localesse almacenen áreas de memo-ria distintas para cada usuarioo proceso. La programaciónreentrante es clave en siste-mas multitarea y multiusuariocomo las aplicaciones Web.

Figura 55. Ciclo de vida de una aplicación ASP.NET.




En el momento en que el servidor Web recibe la primera solicitud desti-

nada a una aplicación, el motor de ASP.NET crea el ámbito de aplicación,

i.e. un objeto AppDomain , específico para la aplicación. Antes de la primera

solicitud no se ejecuta ningún código ASP.NET relacionado con dicha

aplicación.

En el interior del objeto AppDomain se crea un conjunto de instancias de la

clase HttpApplication. Uno de estos objetos será destinado a procesar la pri-

mera solicitud recién llegada, liberándose una vez la solicitud se comple-

te. A partir de este momento cada nueva solicitud es procesada comple-

tamente por una sola instancia de la clase HttpApplication.

Antes de que el objeto HttpApplication atienda la primera solicitud ASP.NET

lanza el evento OnStart que normalmente es atendido por el método con-

trolador de eventos Application_Start(), accesible por ejemplo desde el archi-vo Global.asax.

El objeto HttpApplication que está procesando la solicitud crea e inicializa los

módulos HTTP necesarios para atender la solicitud. Los módulos se inicia-

lizan, invocando a su respectivo método Init(), en el orden en que apare-

cen en el archivo Web.config (ver apartado “Configuración de la aplica-

ción”), almacenado en la raíz del directorio virtual. Seguidamente se

invoca al método Init() del propio objeto HttpApplication que está procesando

la solicitud. Este método es un método virtual al que puede hacerse un

override en el archivo Global.asax. A diferencia del método controlador de

eventos Application_Start(), el método Init() se invoca una vez por cada ins-

tancia de la clase HttpApplication , es decir, por cada solicitud a la aplicación.

Cuando se completa una solicitud se invoca al método Dispose del objeto

HttpApplication que estaba procesando la solicitud. Al igual que el método

Init(), el método Dispose() de HttpApplication se invoca por cada instancia, de

forma que un mismo objeto HttpApplication puede utilizarse varias veces a

lo largo de la ejecución de la (misma) aplicación.

Antes de que ASP.NET finalice el AppDomain , la clase HttpApplication lanza el

evento OnEnd que normalmente es atendido por el método controlador de

eventos Application_End(), accesible por ejemplo desde el archivo Global.asax.

Este evento puede usarse, entre otras cosas, para liberar recursos que se

hayan generado a lo largo de la ejecución de la aplicación.

5.2. El archivo Global.asax

En el apartado anterior se ha mencionado repetidamente el archivo Glo-

bal.asax que, como ya hemos comentado, reside en la raíz del directorio vir-tual de la aplicación. Este archivo, también conocido como el archivo de

aplicación de ASP.NET, es de gran importancia para la gestión del estado

Un módulo HTTP es un filtrocapaz de pre y postprocesar las solicitudes HTTP en supaso por el motor de gestióndel protocolo HTTP. Por ejemplo, diversos servicios de ASP.NET, como los mecanis-mos de seguridad y de ges-tión del estado de una sesión,están implementados me-diante módulos HTTP.En ASP.NET los módulos HTTPson clases que implementanla interface Sys-tem.Web.IHttpModule .




puesto que en él puede especificarse código de atención a los eventos de

nivel de aplicación provocados por ASP.NET o los módulos HTTP.

Global.asax se analiza y compila en tiempo de ejecución, generándose dinámi-

camente una clase derivada de HttpApplication en la que pueden redefinirse los

métodos de atención a eventos tales como: Application_OnStart, Applica-

tion_OnEnd, Session_OnStart, Session_OnEnd, etc. La clase resultante se genera la

primera vez que se solicita una URL perteneciente al espacio de nombres de

la aplicación correspondiente. Seguidamente se muestra la forma en que

puede definirse un método de atención al evento de inicio de la aplicación:

Si el código de atención a los eventos necesita importar espacios de nombres

adicionales, se puede utilizar la directiva @ Import de la misma forma que en

una página .aspx:

El archivo Global.asax es opcional, por lo que si no se define, ASP.NET asume

que no se van a definir métodos de atención a los eventos del nivel de apli-cación o sesión. El archivo está protegido de accesos directos desde el nave-

gador del cliente, de forma que no puede descargarse ni verse su código.

Los cambios en el archivo Global.asax pueden hacerse aún cuando la aplica-

ción esté ejecutándose. Cuando ASP.NET detecta los cambios en el archivo,

espera a que se completen todas las solicitudes, envía el evento Applica-

tion_OnEnd y reinicia el dominio de la aplicación. Esto conlleva cerrar todas

las sesiones activas y que el estado de la sesión se pierda. Completada esta

fase, cuando llega la siguiente solicitud, ASP.NET recompila el archivo Glo-

bal.asax y lanza de nuevo el evento Application_OnStart.

El ejemplo de la Figura 56 ilustra el período de vida de los objetos Application,

Session y Request. La primera vez que se abre la página, se provoca el evento

Start para la aplicación y la sesión, con lo que se ejecutan los métodos Applica-

tion_Start() y Session_Start(), respectivamente. Los eventos BeginRequest y EndRe-

quest se provocan en cada solicitud. Cuando la página se actualiza, sólo apa-

recen mensajes de BeginRequest, EndRequest y el método Page_Load. Al abandonar

la sesión actual (haciendo clic en el botón "Finalizar esta sesión"), se crea una

nueva sesión y se provoca de nuevo el evento Session_Start. La Figura 57 mues-

tra un instante de la ejecución del ejemplo.

<script language="C#" runat="server">

void Application_Start(object sender, EventArgs e) {// Código que se ejecutará al iniciarse la aplicación

}

</script>

<%@ Import Namespace="System.Text" %>





Archivo Ejemplo.aspx<html>

<script language="C#" runat="server">void Page_Load(Object sender, EventArgs e) {

Response.Write("Dentro de Page.Load()...<br>");

}void Session_Click(Object sender, EventArgs e) {

Session.Abandon();Response.Redirect("Ejemplo.aspx");

}

void Error_Click(Object sender, EventArgs e) {throw new Exception();

}</script><body><form runat="server" ID="Form1">

<input type="submit" Value="Recargar la página" runat="server" ID="Submit1"NAME="Submit1"/>

<input type="submit" OnServerClick="Session_Click" Value="Finalizar sesión"runat="server" ID="Submit2" NAME="Submit2"/><input type="submit" OnServerClick="Error_Click" Value="Generar un error"

runat="server" ID="Submit3" NAME="Submit3"/><p><hr>

</form></body>

</html>

Archivo Global.asax.cs…

void Session_Start(Object sender, EventArgs E) {Response.Write("Empieza la sesión...<br>");

}

void Application_BeginRequest(Object sender, EventArgs E) {Response.Write("<h3>Usando el archivo Global.asax</h3>");Response.Write("Empieza la solicitud...<br>");

}

void Application_EndRequest(Object sender, EventArgs E) {Response.Write("Acaba la solicitud...<br>");

}

void Application_Error(Object sender, EventArgs E) {Context.ClearError();Response.Write("Se ha producido un error …<br>");

}…

Figura 56. Ejemplo de uso del archivo Global.asax.

Figura 57. Ejemplo de uso del archivo Global.asax: ejecución.




5.3. Gestión del estado

Se entiende por estado de una aplicación cualquier dato que afecta al com-

portamiento global de la misma. Algunos ejemplos paradigmáticos incluyen

los catálogos de productos y los carritos de compra en las tiendas virtuales,

las opciones de usuario o los contadores de visitas, entre otros.

Aunque el concepto de estado es sencillo, su gestión no lo es tanto, debido

fundamentalmente al desacoplamiento entre solicitudes consecutivas al ser-

vidor. Es más, tratar de gestionar el estado de una aplicación Web va, por así

decirlo, en contra de los principios fundamentales de diseño de la propia

Web. Por principio, la Web y el protocolo HTTP proporcionan un medio

escalable para el intercambio de información. Al añadir información de esta-

do la escalabilidad se reduce considerablemente puesto que las páginas mos-

tradas a un usuario serán diferentes a las páginas mostradas a otro y, por lotanto, no podrán reutilizarse o almacenarse en una cache . Al margen de lo

anterior, gestionar el estado es parte fundamental de muchas aplicaciones

Web. En aplicaciones como las tiendas on-line o los portales de intranet,

tanto la funcionalidad básica como la experiencia de usuario dependen en

buena medida de la capacidad de la aplicación de almacenar datos sobre

cada usuario, ya sean los artículos que un cliente lleva en el carrito de la

compra, los días de vacaciones solicitados por un empleado, etc.

ASP.NET proporciona mecanismos sencillos de gestión del estado tanto a

nivel de la aplicación global, como a nivel de la sesión de un usuario concre-

to. Por ejemplo, el problema de la pérdida de datos del formulario en el

round trip desaparece automáticamente al disponerse de un mecanismo

denominado view state . Adicionalmente a los mecanismos predefinidos, que

generalmente se asocian a toda la página y/o a los controles que contiene,

ASP.NET también facilita que el programador pueda almacenar datos especí-

ficos de la aplicación, tanto en el servidor como en el propio navegador.

5.3.1. Mecanismos basados en el navegador

Los siguientes mecanismos describen maneras gestionar el estado basadas en

el almacenamiento de información en la propia página o en el navegador del

cliente. Ninguno de estos mecanismos recurre al servidor para almacenar

información entre round trips .

Campos ocultos. ASP.NET permite usar campos ocultos del estándar de

HTML. Estos campos no se visualizan en el navegador, sin embargo sí que es

posible asignar valores a sus propiedades, como sucede con cualquier otro

control.

Para usar explícitamente un campo oculto, se dispone del control HtmlInput-

Hidden. La propiedad value de este control permite almacenar un solo valor.

Aviso de seguridad. Un usua-rio malicioso podría ver ymodificar el contenido de uncampo oculto con relativafacilidad. En consecuencia no

se recomienda usar camposocultos para almacenar in-formación sensible.




Cuando se envía una página al servidor, el valor de los campos ocultos se

envía junto con los valores del resto de controles. Así, un campo oculto pue-

de usarse para almacenar cualquier información específica de la página.

Finalmente remarcar que para poder usar campos ocultos el mecanismo de

envío de la página debe ser necesariamente de tipo POST.

ViewState. Los controles de ASP.NET disponen de una propiedad denomina-

da EnableViewState que determina si deben o no mantener su estado entre soli-

citudes al servidor. Por defecto esta propiedad tiene valor True, por lo que

mediante este mecanismo todo control de servidor mantiene su estado a lo

largo de los round trips .

La propiedad ViewState de los controles y la propia página proporciona unobjeto de diccionario que permite almacenar valores a lo largo de múltiples

solicitudes de una misma página al servidor. Este es el método que usa la

página entre round trips para almacenar tanto sus propiedades como las de

los controles que contiene. Así, cuando se procesa una página, su estado

actual y el de sus controles se codifica en un string que se almacena en la

propia página como un campo oculto denominado _VIEWSTATE. Cuando la

página se solicita nuevamente al servidor la página analiza dicho string y

restaura los valores de las propiedades de los objetos en la página. La Figura

42 muestra un ejemplo del uso del campo oculto _VIEWSTATE por parte del

formulario para almacenar su propio estado.

Cookies. Una cookie es una pequeña cantidad de datos almacenados en un

archivo en el ordenador del cliente o en la memoria de la sesión del navega-

dor del cliente. Una cookie contiene información específica de una página

enviada por el propio servidor. La permanencia de una cookie en el ordena-

dor del cliente puede ser temporal, i.e. con fecha de caducidad, o persistente.

Los navegadores limitan el tamaño de las cookies a un máximo de 4096

bytes lo que condiciona la cantidad de información que puede almacenarse

mediante este sistema.

Una cookie puede usarse para almacenar información sobre el navegador, la

sesión o la aplicación. Así, cuando el cliente solicita una página, el navega-

dor envía al servidor la información de la cookie junto a la propia de la soli-

citud. Posteriormente el servidor puede extraer el valor de la cookie .

Un uso típico de la cookies es el de almacenar un token (a menudo encripta-

do) que indica que el usuario ya se ha autenticado en la aplicación por lo

que no es necesario volver a solicitarle sus datos en la próxima solicitud.

Otro uso típico es el de almacenar datos sobre preferencias del usuario en suinteracción con la aplicación.

ViewState proporciona undiccionario de información deestado mediante el que alma-cenar y recuperar el view statede un control de servidor a lolargo de múltiples solicitudesal servidor.

Aviso de seguridad. El nave-gador sólo puede enviar lacookie al servidor que la creóoriginalmente. Sin embargo,

un usuario malicioso podríaapropiarse de una cookie yleer su contenido. Así pues noes recomendable almacenar información sensible (e.g. un password ) en una cookie . Ensu lugar es preferible almace-nar una clave que permita alservidor recuperar dichainformación sensible.




Query strings. Mecanismo sencillo, aunque limitado, de almacenar cierta

información de estado. Por ejemplo, permiten pasar información de una

página a otra, como el código de un producto mientras se compra en una

tienda virtual. La limitación suele hallarse en la longitud del string ya que

muchos navegadores no admiten URLs de más de 255 caracteres.

Aviso de seguridad. La infor-mación almacenada en unaquery string es visible en laURL que muestra el navega-dor por lo que no se reco-

mienda usar este mecanismopara almacenar informaciónsensible.

<html><body><h1>Formulario de registro</h1><form name="Form1" method="post" action="Ejemplo.aspx"

language="javascript" onsubmit="if (!ValidatorOnSubmit()) return false;" id="Form1">

<input type="hidden" name="_VIEWSTATE"value="dDwtMTE5ODk3NjE1MTs7PlT1fO6A9Nmlf9lBjO6D3Svdtvf2" />

<script language="javascript" type="text/javascript"src="/aspnet_client/system_web/1_1_4322/WebUIValidation.js"></script>

…

<p> Teléfono: <input name="Telefono" type="text" id="Telefono" /><span id="Validator3" controltovalidate="Telefono"

errormessage="Debe introducir un número de teléfono"evaluationfunction="RequiredFieldValidatorEvaluateIsValid" initialvalue=""style="color:Red;visibility:hidden;">Debe introducir un número de teléfono

</span></p>

<p> <input type="submit" name="BotonRegistro" value="Registrar"onclick="if (typeof(Page_ClientValidate) == 'function') Page_ClientValidate(); "language="javascript" id="BotonRegistro" />

</p>


var Page_Validators = new Array(document.all["Validator1"],document.all["Validator2"], document.all["Validator3"]);

// --></script>


var Page_ValidationActive = false;if (typeof(clientInformation) != "undefined" &&clientInformation.appName.indexOf("Explorer") != -1) {

if (typeof(Page_ValidationVer) == "undefined")alert("Unable to find script library

'/aspnet_client/system_web/1_1_4322/WebUIValidation.js'. Try placing thisfile manually, or reinstall by running 'aspnet_regiis -c'.");

else if (Page_ValidationVer != "125")alert("This page uses an incorrect version of WebUIValidation.js. The page expects

version 125. The script library is " + Page_ValidationVer + ".");else ValidatorOnLoad();

}

function ValidatorOnSubmit() {

if (Page_ValidationActive) {return ValidatorCommonOnSubmit();}return true;

}// --></script>

</form></body>

Figura 58. Ejemplo de uso de _VIEWSTATE.




5.3.2. Mecanismos basados en el servidor

ASP.NET ofrece mecanismos basados en el servidor para la gestión del estado

tanto a nivel del conjunto de la aplicación, como a nivel de una sesión de

usuario concreta.

Estado de la aplicación. ASP.NET proporciona un mecanismo de almacena-

miento global accesible desde todas las páginas de una aplicación Web. Me-

diante él es posible almacenar información que necesita mantenerse entre

round trips , entre solicitudes a distintas páginas y entre las distintas sesiones

simultáneas. El acceso concurrente al almacén de datos de estado global de la

aplicación se puede controlar mediante un sencillo mecanismo de sincroni-

zación. Además, los datos están protegidos de forma que no sean accesibles

desde otras aplicaciones ASP.NET ejecutándose en el mismo servidor.

La primera vez que el navegador solicita una URL del directorio virtual de

una aplicación ASP.NET se crea una instancia de la clase HttpApplicationState . El

objeto creado, único para toda la aplicación, permanece accesible a lo largo

de su ciclo de vida a través de la propiedad Application de diversos objetos,

incluido el objeto Page.

El empleo adecuado de variables de estado de aplicación puede ayudar a

mejorar significativamente el rendimiento de una aplicación Web. Por ejem-

plo, al procesar una página que deba mostrar gran cantidad de información

calculada, podrían cargarse los datos y realizarse los cálculos, de forma que

almacenados como datos globales permitan que sucesivas solicitudes se re-

suelvan de forma mucho más eficiente. Si el volumen de datos a almacenar

es considerable, pueden usarse otros mecanismos como el de cache (fuera del

alcance de este temario).

Estado de la sesión. El concepto de estado de sesión es similar al de estado

de aplicación, a excepción de que se circunscribe únicamente a una sesión

concreta de un navegador. Es decir, cada usuario-navegador que accede a la

aplicación tiene su propio estado de sesión independiente. Es más, si unusuario deja la aplicación y se reconecta más tarde, su estado de sesión será

diferente. Este concepto es necesario para poder implementar de forma eficaz

soluciones como “carritos de la compra” en tiendas virtuales, por ejemplo.

ASP.NET proporciona la infraestructura necesaria para: identificar y clasificar

en el servidor las solicitudes efectuadas desde un mismo navegador, como

pertenecientes a una misma sesión; generar códigos de sesión aleatorios en

forma de un string identificador de 120 bits que se comunica a lo largo de

las solicitudes mediante una cookie o la propia URL; almacenar datos a lo

largo de una sesión; generar eventos de inicio (Session_OnStart) y finalizaciónde sesión (Session_OnEnd) en los que el programador puede añadir funcionali-




dad específica de sesión; así como liberar los datos de sesión si el navegador

correspondiente no genera solicitudes durante cierto periodo de tiempo.

El estado de la sesión se gestiona mediante una instancia de la clase HttpSes-

sionState, única para cada sesión, y que es accesible a través de la propiedad

Session de diversos objetos, incluido el objeto Page. Mediante este objeto es

posible almacenar variables que necesiten mantenerse tanto entre round

trips como entre solicitudes a distintas páginas de la aplicación.

Uso de bases de datos. Es muy habitual usar bases de datos cuando la infor-

mación de estado es muy abundante. Combinado con el uso de cookies y la

identificación única de sesión, la base de datos puede almacenar datos de

forma persistente e independiente de posibles reinicios en el servidor.

5.4. Gestión del estado en la práctica

Aunque algunos de los mecanismos que hemos descrito en el punto anterior

son usados de forma implícita por ASP.NET para implementar algunas de sus

funcionalidades básicas, dichos mecanismos también pueden usarse por el

desarrollador para almacenar datos de estado si es necesario. A continuación

veremos algunos sencillos ejemplos de cómo usar los mecanismos más co-

munes para ello. Antes, sin embargo, la siguiente tabla resume brevemente

las características de dichos mecanismos:

Mecanismo Ámbito Ventajas Desventajas

ViewState A lo largo de

un round

trip.

Independiente de la

configuración del servi-

dor.

Sólo funciona si el método

de envío es POST.

El estado se envía y devuelve

con cada solicitud.

Cookie Por cliente. Independiente de la

configuración del servi-

dor.

El estado se almacena enel cliente.

Los datos permanecen

más allá de la sesión.

El estado se envía y devuelve

con cada solicitud.

Limitado a 4KB.

El navegador puede no so-

portar cookies o tenerlas

deshabilitadas.

Session Por cliente. Puede compartirse en una

granja de servidores.

Requiere cookies o similar

para gestionar la asociación

de los datos con el cliente.

Application Global a la

aplicación.

El estado se comparte

entre todos los navegado-

res.

Abusar puede limitar la esca-

labilidad.

No puede compartirse en unagranja de servidores.




5.4.1. Uso del ViewState

ASP.NET proporciona la noción de “estado de la presentación” de cada con-

trol en el servidor. Un control puede guardar su estado interno entre solici-

tudes mediante la propiedad ViewState de una instancia de la clase StateBag. La

clase StateBag proporciona una interfaz de tipo diccionario para almacenar

objetos asociados a una clave de tipo string .

Aunque generalmente un formulario Web no necesitará manipular el ViewSta-

te directamente, esto sí será necesario si queremos almacenar valores de esta-

do o desarrollar controles propios. El acceso a ViewState se realiza de la misma

forma que a cualquier otro objeto de diccionario:

El ejemplo de la Figura 60 muestra cómo usar ViewState para almacenar el

índice del Panel que debe visualizarse en cada momento. La Figura 59 muestra

los dos paneles citados, en dos momentos de la ejecución de la aplicación.En cada round trip provocado por el clic en un botón, se consulta el valor

del índice para saber qué Panel no debe visualizarse, y se actualiza el índice

// Añadimos el valor ―miValor‖ en una variable a la que llamaremos ―miIdentificador‖ ViewState["miIdentificador"] = miValor;

// Consulta del valor asociado a ―miIdentificador‖ Response.Write(ViewState["miIdentificador "]);

Figura 59. Ejemplo de uso de ViewState para almacenar valores de estado: ejecución.




para saber qué Panel se va a visualizar a continuación. Como los valores de los

objetos de diccionario son de tipo string debe usarse conversión de tipos

para almacenar valores de otros tipos, como el índice entero del ejemplo.


void Page_Load(Object Src, EventArgs E ) {if (!IsPostBack) ViewState["PanelIndex"] = 0;

}

void Next_Click(Object Src, EventArgs E ) {String PrevPanelId = "Panel" + ViewState["PanelIndex"].ToString(); ViewState["PanelIndex"] = (int)ViewState["PanelIndex"] + 1;String PanelId = "Panel" + ViewState["PanelIndex"].ToString();

Panel p = (Panel)FindControl(PanelId);p.Visible=true;p = (Panel)FindControl(PrevPanelId);

p.Visible=false;}

void Prev_Click(Object Src, EventArgs E ) {String PanelId = "Panel" + ViewState["PanelIndex"].ToString(); ViewState["PanelIndex"] = (int)ViewState["PanelIndex"] - 1;String PrevPanelId = "Panel" + ViewState["PanelIndex"].ToString();

Panel p = (Panel)FindControl(PanelId);p.Visible=false;p = (Panel)FindControl(PrevPanelId);p.Visible=true;

}

void Finish_Click(Object Src, EventArgs E ) {

String PanelId = "Panel" + ViewState["PanelIndex"].ToString();Panel p = (Panel)FindControl(PanelId);p.Visible=false;

MyLabel.Text += "<b>Hemos recibido la siguiente información: </b><p>";MyLabel.Text += "Nombre: " + FirstName.Value + "<br>";MyLabel.Text += "Apellido: " + LastName.Value + "<br>";MyLabel.Text += "Dirección: " + Address.Value + "<br>";MyLabel.Text += "Ciudad: " + City.Value + "<br>";MyLabel.Text += "Código postal: " + Zip.Value + "<br>";

}</script><body>

<form runat="server" ID="Form1"><ASP:Panel id="Panel0" Visible="true" runat="server">

<P><B>Rellena los campos y selecciona Siguiente para continuar:</B></P><P>Nombre: <INPUT id="FirstName" type="text" size="45" runat="server"></P><P>Apellido: <INPUT id="LastName" type="text" size="45" runat="server"></P><P><INPUT id="Submit1" type="submit" value=" Siguiente >> "

name="Submit1" runat="server" OnServerClick="Next_Click"></P></ASP:Panel><ASP:Panel id="Panel1" Visible="false" runat="server">

<P><B>Rellena los campos y selecciona FInalizar para acabar:</B></P><P>Dirección: <INPUT id="Address" type="text" size="45" runat="server"></P><P>Ciudad: <INPUT id="City" type="text" size="45" runat="server"></P><P>Código postal: <INPUT id="Zip" type="text" size="45" runat="server"></P><P><INPUT id="Submit2" type="submit" value=" << Atrás " name="Submit2"

runat="server" OnServerClick="Prev_Click"></P><P><INPUT id="Submit3" type="submit" value=" Finalizar " name="Submit3"

runat="server" OnServerClick="Finish_Click"></P>

</ASP:Panel><asp:Label id="MyLabel" EnableViewState="false" runat="server" /></form></body>

</html>

Figura 60. Ejemplo de uso de ViewState para almacenar valores de estado.




5.4.2. Uso de cookies

Como ya hemos comentado uno de los métodos para almacenar valores de

estado en ASP.NET se basa en el empleo de cookies . Esto aplica tanto al esta-

do dentro de la misma sesión como al estado entre sesiones.

En el ejemplo de la Figura 62, cuando se almacenan los datos en el cliente, el

método Page_Load del archivo Ejemplo.aspx comprueba si el cliente ha envia-

do una cookie . Si no se ha enviado ninguna, se crea una cookie nueva, se

inicializa y se guarda en el cliente, almacenando el valor del color de fondo

de las páginas. La Figura 61 muestra diversos momentos de la ejecución de la

aplicación correspondientes a una misma sesión.

El comportamiento del ejemplo puede comprobarse abriendo la página Ejem-

plo.aspx y modificando las preferencias. Si abrimos la misma página en otraventana del navegador, esta ventana debe reflejar las nuevas preferencias. Si

se cierran todas las ventanas del navegador y se abre de nuevo la página

Ejemplo.aspx, la cookie temporal debería eliminarse y con ella deberían restau-

rarse las preferencias por defecto.

Figura 61. Ejemplo de uso de cookies para almacenar valores de estado: ejecución.




Para conservar una cookie entre sesiones es necesario establecer el valor de la

propiedad Expires de la clase HttpCookie en una fecha futura. En el ejemplo

anterior bastaría añadir el siguiente fragmento de código en el método Sub-

mit_Click() de la página customize.aspx:

Para comprobar el funcionamiento basta cerrar todas las ventanas del nave-

gador tras haber cambiado las preferencias del color de fondo y comprobar,

al abrir una nueva ventana, que las preferencias se mantienen.

5.4.3. Uso del objeto Application

Puesto que el objeto Application proporciona acceso a un repositorio de infor-

mación global, su uso indiscriminado puede limitar severamente la escalabi-

lidad de una aplicación, especialmente si se emplea para almacenar datos

que la aplicación deba actualizar.

La Figura 63 muestra un ejemplo típico de uso del estado a nivel de aplica-

ción. Tan pronto como se pone en marcha la aplicación, el método Applica-

tion_Start() de atención al evento correspondiente, carga ciertos datos de una

base de datos y los almacena en un DataSet. Los subsiguientes accesos a la

aplicación no necesitarán cargar los datos nuevamente desde la base de da-

tos, sino que accederán a ellos mediante el objeto Application, consultado en el

ejemplo desde el método Page_Load().

El objeto Application está provisto de un mecanismo de acceso concurrente

según el cual pueden realizarse múltiples lecturas simultáneas pero sólo es

posible realizar una escritura cada vez. Este mecanismo, a diferencia de loque sucedía en ASP, lo gestiona automáticamente ASP.NET otorgando permi-

sos de lectura o escritura para añadir elementos, de forma conveniente. En

// Carga de los datos en el método Application_Start() definido en global.asaxvoid Application_Start(object src, EventArgs e){

DataSet ds = new DataSet();// Cargamos datos en el DataSet mediante ADO.NET, por ejemplo

// Almacenamos una referencia al DataSet en Application Application["FuenteDeDatos"] = ds;

}

// En aquellas páginas de la aplicación que necesiten los datos del Dat aSetprivate void Page_Load(object src, EventArgs e){

DataSet ds = (DataSet)(Application["FuenteDeDatos "]);// Por ejemplo para visualizar en un DataGrid los datos precargadosMyDataGrid.DataSource = ds;...

}

Figura 63. Ejemplo de uso del objeto Application.

cookie.Expires = DateTime.MaxValue; // Nunca caduca




caso de que exista la posibilidad de actualizaciones concurrentes de una por-

ción del estado, es responsabilidad del programador garantizar el acceso or-

denado y evitar así las condiciones de carrera. Para gestionar los accesos de

escritura de forma explícita es necesario invocar a los métodos Lock() y Un-

Lock() de Application, para bloquear y desbloquear el acceso al objeto respecti-

vamente. La Figura 64 muestra un ejemplo de esta situación en el que, cada

vez que se accede a la página, se usa el string que identifica el tipo de nave-

gador (Request.Browser.Browser ) como índice del objeto Application de forma que

se contabiliza el número de accesos realizados con cada navegador particular.

Seguidamente se muestran las estadísticas hasta el momento.

5.4.4. Uso del objeto Session

El ejemplo de la Figura 65 ilustra el uso del estado de una sesión para alma-

cenar preferencias de usuario volátiles, de forma similar a lo que se mostró

en el ejemplo de la Figura 62 mediante cookies . En este caso, sin embargo, seemplea el objeto Session y el evento de inicio de sesión para asignar el valor

por defecto al fondo de las páginas en el método Session_Start(), que aquí defi-

nimos en el archivo Global.asax. Por otra parte, en la página de personaliza-

ción (customize.aspx), se modifica el valor de la preferencia del usuario en el

método Submit_Click() con la información seleccionada por el usuario.

Para comprobar que el valor seleccionado se almacena realmente con ámbito

de sesión, es preciso abrir dos veces la página del Ejemplo.aspx, cambiar un

valor en la primera ventana del explorador y actualizarlo en la segunda. La

segunda ventana reflejará los cambios, ya que las dos instancias de explora-

dor comparten un objeto Session común.

Una condición de carreraconsiste es una situación enun sistema según la cuál surespuesta depende del ordenen el que sucedan ciertos

eventos, lo que constituye unpotencial error en dicharespuesta. El término provinede la electrónica, con la ideade dos señales eléctricascompitiendo por llegar antesal final de un camino conduc-tor y así influenciar en alrespuesta antes que la otraseñal.

<script runat='server'>private void Page_Load(object sender, System.EventArgs e){

// Bloqueo del objeto Application Application.Lock();

// Actualizamos un valor del objeto Applicationif (Application[Request.Browser.Browser] != null) Application[Request.Browser.Browser] = (int)Application[Request.Browser.Browser] + 1;else Application[Request.Browser.Browser] = 1;

// Desbloqueo del objeto Application Application.UnLock();

// Imprime los valores almacenados en el objeto Applicationfor (int i=0; i<Application.Count; i++)Response.Output.Write("<p>{0} : {1} hits</p>", Application.GetKey(i), Application[i]);

}</script>

Figura 64. Ejemplo de uso los mecanismos de sincronización para el objeto Application.





Es posible configurar las características del estado de una sesión en la sección

<sessionState> de un archivo web.config (ver apartado “Configuración de la apli-

cación”). Por ejemplo, para doblar el tiempo de espera de inactividad de la

sesión, predeterminado a 20 minutos, se puede agregar el código siguiente al

archivo web.config:


<script language="C#" runat="server">protected String GetBC() {

return Session["BackColor"].ToString();

}</script><body style="background-color:<%=GetBC()%>"><b><a href="customize.aspx">Personalizar la página</a></b><p>Texto de ejemplo<br>

</body></html>

Archivo customize.aspx<html>


if (!IsPostBack){ ViewState["Referer"] = Request.Headers["Referer"];BackColor.Value = (String)Session["BackColor"];

}}

void Submit_Click(Object sender, EventArgs E) {Session["BackColor"] = BackColor.Value;if ( ViewState["Referer"] != null ) Response.Redirect(ViewState["Referer"].ToString());

}

void Cancel_Click(Object sender, EventArgs E) {if ( ViewState["Referer"] != null ) Response.Redirect(ViewState["Referer"].ToString());

}

protected String GetBC() {return Session["BackColor"].ToString();

}

</script><body style="background-color:<%=GetBC()%>"><form runat="server" ID="Form1"><b>Selecciona tus preferencias: </b><p>Color de fondo:</p><p>

<select id="BackColor" runat="server" NAME="BackColor"><option >beige</option> <option>yellow</option><option>blue</option> <option>lightblue</option>

</select></p>

<input type="submit" OnServerClick="Cancel_Click" Value="Cancelar" runat="server"ID="Submit1"/>

<input type="submit" OnServerClick="Submit_Click" Value="Enviar" runat="server"ID="Submit2"/>


Archivo Global.asax.cs…

protected void Session_Start(Object sender, EventArgs e) {Session["BackColor"] = "beige";

}…

Figura 65. Ejemplo de uso del objeto Session.




De forma predeterminada, ASP.NET almacenará el estado de la sesión en el

mismo proceso que atiende la solicitud. Si no hay cookies disponibles, sepuede hacer un seguimiento de una sesión agregando un identificador de

sesión a la dirección URL. Esto puede habilitarse de la manera siguiente:

5.4.5. Buenas prácticas

A continuación se resumen algunas buenas prácticas aplicables a la gestión

del estado de una aplicación, en cualquiera de las vertientes comentadas a

los largo de los apartados anteriores:

Utilizaremos variables de estado de la aplicación para almacenar datos

que se modifiquen con poca frecuencia pero que se consulten a menudo

y cuyo ámbito de validez sea global a toda la aplicación.

Utilizaremos variables de estado de la sesión para almacenar datos especí-ficos de una sesión o de un usuario. Los datos se almacenan completa-

mente en el servidor. Utilizaremos estas variables para datos de corta du-

ración, datos importantes o grandes cantidades de datos.

Almacenaremos pequeñas cantidades de datos volátiles en una cookie no

persistente. Los datos se almacenarán en el cliente, se enviarán al servidor

en cada solicitud y caducarán cuando finalice la ejecución en el cliente.

Almacenaremos pequeñas cantidades de datos no volátiles en una cookie

persistente. Los datos se almacenarán en el cliente hasta que caduquen yse enviarán al servidor en cada solicitud.

Almacenaremos en el estado de la presentación ( ViewState) pequeñas can-

tidades de datos específicos de una solicitud. Los datos se envían desde el

servidor al cliente y viceversa.

5.5. Configuración de la aplicación

Cualquier servidor de aplicaciones Web debe poseer un sistema de configu-

ración de las aplicaciones que sea potente y flexible. Potente para permitir al

programador parametrizar la aplicación sin tener que almacenar los valores

<sessionState timeout=‖40‖ />

<sessionState cookieless=‖true‖ />





de configuración dentro del código, y flexible para que el administrador

pueda modificar dichos valores de forma sencilla. ASP.NET cumple ambos

requisitos, ofreciendo una infraestructura de configuración jerárquica que

permite definir datos de configuración extensibles y utilizarlos a lo largo de

una aplicación Web, un sitio Web o un servidor. Algunos parámetros de

configuración típicos en una aplicación Web incluyen por ejemplo: strings

de conexión a las bases de datos, mensajes de error, parámetros culturales

como el idioma, etc.

Seguidamente se resumen algunas de las características del sistema de confi-

guración de ASP.NET:

ASP.NET almacena los valores de configuración junto con el resto del

contenido de la aplicación dentro de una única jerarquía de directorios.

Usuarios y administradores sólo necesitan copiar un único árbol de direc-torios para instalar una aplicación ASP.NET en un servidor.

Los datos de configuración se almacenan en archivos XML accesibles

mediante cualquier editor de texto, analizador XML o lenguaje de script

para interpretar y actualizar la configuración.

La infraestructura de configuración es extensible, lo que permite a pro-

gramadores terceros almacenar sus propios valores de configuración, de-

finir el mecanismo de persistencia de esos valores, participar de forma in-

teligente en su procesamiento y controlar el modelo de objetos resultante

a través del cual esos valores se exponen a la aplicación.

ASP.NET detecta automáticamente los cambios en los archivos de confi-

guración y los aplica sin que sea necesario reiniciar el servidor Web para

que surtan efecto.

5.5.1. Archivos de configuración

Los archivos de configuración de ASP.NET son archivos XML (cada uno conel nombre Web.config) que pueden aparecer en cualquier directorio del servi-

dor de aplicaciones. Cada archivo Web.config aplica valores de configuración

al directorio en el que se encuentra ubicado y a todos sus subdirectorios. Los

valores de los subdirectorios pueden reemplazar los valores especificados en

sus directorios principales. Por su parte, el archivo de configuración raíz

(C:\WINDOWS\Microsoft.NET\Framework\<version>\CONFIG\machine.config) propor-

ciona valores de configuración predeterminados para todo el servidor. Por

ejemplo, los valores de configuración para la URL

http://servidor/aplicacion/dir/pagina.aspx se calcularían aplicando los valores de

los archivos Web.config en el siguiente orden:




La presencia de un archivo Web.config dentro de un determinado directorio o

de la raíz de la aplicación es totalmente opcional. Si no existe un archivo

Web.config , todos los valores de configuración para el directorio se heredan

automáticamente del directorio principal. Por otra parte, si existe un archivo

Web.config en el directorio raíz del sitio, por ejemplo, " inetpub\wwwroot", sus

valores de configuración se utilizarán para todas las aplicaciones de ese sitio.

Durante la ejecución, ASP.NET utiliza los archivos de configuración para

calcular jerárquicamente los valores de configuración para cada solicitud de

una URL determinada. Dichos valores se calculan sólo una vez y después se

guardan en caché a lo largo de las solicitudes subsiguientes. ASP.NET moni-

toriza los cambios en los archivos de configuración e invalida la caché si

cualquiera de ellos se modifica.

Finalmente cabe destacar que ASP.NET configura IIS para impedir el acceso

directo desde un navegador a los archivos Web.config y así garantizar que sus

valores no se hacen públicos.

5.5.2. Sintaxis de Web.config

Aunque basada en XML, la sintaxis (y la semántica asociada) de los archivos

de configuración de ASP.NET es materia de estudio en sí misma. Puesto que

analizarla en detalle sería tedioso y seguramente poco práctico, hemos prefe-

rido acercarnos a ella a través del análisis de un ejemplo de archivo Web.config que generado por defecto por Visual Studio para cierto proyecto de aplica-

ción Web ASP.NET (ver Figura 66).

Como puede apreciarse, la etiqueta <configuration> sólo tiene una etiqueta

anidada (<system.web>) formando un grupo de secciones de configuración.

Algunas de las secciones de configuración típicamente incluidas en un gru-

po son: compilation, customErrors, authentication , authorization, etc. El funcionamien-

to es sencillo: basta detallar las particularidades de la configuración en la

sección correspondiente. Por ejemplo, si se quiere usar un modo de autenti-

cación diferente al indicado, basta indicarlo en la sección authentication .

Configuración base del servidor:

C:\WINDOWS\Microsoft.NET\Framework\ v1.1.4322\CONFIG\machine.config

Sobrescrita por la configuración del sitio (o la aplicación de la raíz de IIS):C:\inetpub\wwwroot\Web.config

Sobrescrita por la configuración de la aplicación:D:\ aplicacion \Web.config

Sobrescrita por la configuración del subdirectorio:D:\aplicacion\dir\Web.config




Al margen de la configuración estándar de system.web, puede definirse tam-

bién la configuración específica de la aplicación, como los strings de co-

nexión a las bases de datos, mediante la etiqueta <appSettings>. Así pues, el

archivo Web.config tendrá típicamente la siguiente estructura:

En el grupo de secciones system.web se especifican opciones que antes de la

aparición de ASP.NET se especificaban directamente sobre IIS. Si bien este

grupo admite una gran cantidad de etiquetas de configuración, habitualmen-

te se emplean sólo unas pocas, que describimos a continuación.

<authentication> En esta sección se indica el tipo de autenticación a usar para

acceder a la aplicación. El valor ―None‖ indica que cualquier usuario puede

acceder a ella, mientras que "Windows", "Forms" o "Passport" indican el tipo de

autenticación requerida, si es el caso.

<authorization> Permite dar o denegar el acceso a la aplicación a determinados

usuarios o perfiles. El módulo de autenticación de ASP.NET procesa las sec-

ciones de configuración según el orden en que aparecen en el archivo, por lo

que, en el ejemplo, cualquier usuario con el perfil Administrators o Users podrá

acceder a la aplicación mientras que al resto les será denegado el acceso.

<?xml version="1.0" encoding="utf-8" ?><configuration>

<system.web><compilation defaultLanguage="c#" debug="true" /><customErrors mode="RemoteOnly" />

<authentication mode="Windows" /><authorization>

<allow users="*" /></authorization><trace

enabled="false" requestLimit="10" pageOutput="false"traceMode="SortByTime" localOnly="true"

/><sessionState

mode="InProc"stateConnectionString="tcpip=127.0.0.1:42424"sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"cookieless="false"timeout="20"

/>

<globalization requestEncoding="utf-8" responseEncoding="utf-8" /></system.web>

</configuration>

Figura 66. Archivo Web.config de Visual Studio.

<configuration>

<system.web><!— sections--></system.web><appSettings>

<!— sections --></appSettings ></configuration>




<compilation> Aquí pueden especificarse todas las opciones de compilación, sibien las más empleadas son las opciones de depuración (true o false) y el len-

guaje de programación empleado (―vb‖, ―c#‖, etc.).

<customErrors> Permite ofrecer a los usuarios páginas de error con mensajes “a

medida”. En el modo RemoteOnly sólo los usuarios remotos verán los citados

mensajes mientras que los usuarios en el propio servidor verán los detallados

y técnicos mensajes de ASP.NET. En el modo Off todos los usuarios verán los

mensajes de ASP.NET. Mediante el atributo defaultRedirect pueden indicarse

URLs absolutas (e.g. http://midominio.com/error404.html) o relativas a la ubica-

ción del archivo Web.config (e.g. ../error404.html) para redireccionar la aplica-ción en caso de error.

<globalization> Permite indicar el juego de caracteres que se va a usar para en-

viar datos a los navegadores (e.g. UTF-8), así como indicar la forma en que el

servidor debe interpretar los strings dependientes de la cultura, como losnúmeros o las fechas.

<httpRuntime> En esta sección pueden especificarse diversas opciones de tiem-

po de ejecución de la aplicación, como por ejemplo appRequestQueueLimit o

executionTimeout. La primera indica el número máximo de solicitudes que el

servidor puede atender en momentos de mucho tráfico. La segunda indica el

tiempo máximo que el servidor puede dedicar a procesar a una solicitud.

<sessionState> Esta sección permite indicar dónde se va a almacenar el estado

de la sesión. El lugar por defecto es el propio proceso de ASP.NET.

<trace> El log de seguimiento de la aplicación se encuentra en el archivo tra-

ce.axd del directorio raíz de la aplicación. En esta sección puede indicarse laforma en que se va a mostrar la información de dicho archivo. Por ejemplo,

establecer el atributo localOnly a "false" permite acceder a la información de

<authorization><allow roles="Administrators, Users" /><deny users="*" />

</authorization>

<htt Runtime a Re uestQueueLimit="100" executionTimeout="600" />

<customErrors mode="RemoteOnly" defaultRedirect="/error.html"><error statusCode="403" redirect="/accesodenegado.html" /><error statusCode="404" redirect="/paginanoencontrada.html" />

</customErrors>

<globalization requestEncoding="utf-8" responseEncoding="utf-8" culture="es-ES" />

<sessionState mode="InProc" />




seguimiento desde cualquier navegador (local o remoto), establecer el atribu-

to pageOutput a "true" indica al servidor que debe añadir la información de

seguimiento al final de cada página, etc.

Al margen de las opciones referentes al sitio Web que acabamos de ver, el

grupo de secciones appSettings permite, entre otras cosas, que el programador

pueda almacenar constantes globales a toda la aplicación a las que necesita

acceder desde múltiples páginas. Un ejemplo típico son los strings de co-

nexión a las bases de datos.

5.5.3. Acceso a la configuración

Es posible acceder a las opciones de configuración públicas desde el código

de una aplicación ASP.NET mediante los métodos estáticos intrínsecos que

ASP.NET expone. Por ejemplo, para leer el valor del atributo cookieless de la

sección <sessionState>, puede utilizarse la línea de código siguiente:

Por otra parte, el acceso a las opciones específicas de la aplicación almacena-

das en la sección de nivel superior <appSettings> de los archivos Web.config

puede obtenerse a través de la colección estática de strings ConfigurationSet-

tings.AppSettings . Por ejemplo:

<trace enabled="true" localOnl ="true" a eOut ut="false" />

bool nocookies = Session.IsCookieless;

Strin s lConnectionStrin = Confi urationSettin s.A Settin s["s lConn"];

<appSettings><add key="sqlConn" value="Server=miPc;Database=miBaseDeDatos" /><add key="smtpServer" value="smtp.midominio.com" />

</appSettings>





6. Seguridad

Este apartado introduce diversos conceptos relacionados con la seguridad en

las aplicaciones Web de ASP.NET. En primer lugar se tratan los mecanismos

básicos de autenticación y autorización de usuarios y perfiles en una aplica-

ción, aspectos ya presentes desde el origen de ASP.NET. A continuación se

tratan diversos aspectos de seguridad incorporados en ASP.NET 2.0: como el

conjunto de nuevos controles de autenticación; las herramientas para la

configuración de la seguridad de un sitio Web, o algunos detalles de la API

de pertenencia para administrar el acceso a las páginas y simplificar el alma-

cenamiento de la información de los usuarios.

6.1. Autenticación y autorización

Una parte importante de muchas aplicaciones Web radica en la capacidad de

identificar a los usuarios y de controlar su acceso a los recursos. Se conoce

como autenticación al acto de determinar la identidad del solicitante. Por lo

general, el usuario deberá presentar sus credenciales, como su nombre de

usuario y contraseña, para ser autenticado. Una vez que el usuario ha sido

autenticado, deberá determinarse si puede tener acceso a un recurso específi-

co. Este proceso se conoce como autorización.

ASP.NET e IIS colaboran para proporcionar servicios básicos de autenticación

y autorización a las aplicaciones. Además, ASP.NET es compatible con el

servicio de autenticación Microsoft Passport, el cual proporciona servicios

simples de firma y servicios de gestión de perfiles de usuario. ASP.NET tam-

bién proporciona un servicio para aplicaciones que necesitan utilizar auten-

ticación basada en formularios. La autenticación basada en formularios utili-

za cookies para autenticar a los usuarios, y permite a la aplicación realizar su

propia verificación de credenciales.

Es importante insistir en el hecho de que los servicios de autenticación de

ASP.NET dependen de los servicios de autenticación suministrados por IIS.

Por ejemplo, para poder utilizar una autenticación básica en una aplicación,

debe configurarse el uso de la autenticación básica para la aplicación me-

diante el Administrador de servicios de Internet de IIS.

ASP.NET proporciona dos tipos de servicios de autorización: comprobaciones

de ACLs para determinar si la cuenta de usuario autenticada tiene o no acce-

so a los recursos; y, autorización de URL, la cual autoriza una identidad para

partes del espacio Web.

Microsoft Passport permiteutilizar una dirección decorreo electrónico y una solacontraseña para iniciar sesiónen cualquier sitio o servicio Web colaborador de PassportNetwork.




Para ilustrar la diferencia considere un escenario en el que una aplicación

está configurada para permitir acceso anónimo mediante la cuenta de usua-

rio IUSR_MIORDENADOR. En el caso de autorización vía ACL, cuando una solici-

tud de una página ASP.NET (como "/default.aspx") recibe autorización, se reali-

za una comprobación de los ACL del archivo correspondiente (por ejemplo,

"c:\inetpub\wwwroot\default.aspx" ) para ver si la cuenta de usuario IUSR_ MIORDE-

NADOR tiene permiso para leer el archivo. Si lo tiene, entonces se autoriza el

acceso automáticamente.

Para autorización de URL, se comprueba el usuario anónimo con los datos de

configuración obtenidos de los archivos Web.config para la aplicación (ver

apartado “Configuración de la aplicación”). Si se permite el acceso a la direc-

ción URL solicitada, la solicitud se autoriza. En el ejemplo, ASP.NET com-

prueba si el usuario anónimo dispone de acceso a /default.aspx, es decir, la

comprobación se realiza sobre la propia URL, no sobre el archivo en el que elservidor Web resuelve la URL en última instancia.

Ésta puede parecer una diferencia sutil, pero permite a las aplicaciones utili-

zar esquemas de autenticación como los basados en formularios o la autenti-

cación de Microsoft Passport, en los cuales los usuarios no se corresponden

con un equipo o una cuenta de dominio concretos. También permite la au-

torización de recursos virtuales, para los cuales no existe un archivo físico

subyacente al recurso. Por ejemplo, una aplicación podría optar por asignar

todas las solicitudes de archivos que terminan en .stk a un controlador que

proporciona cotizaciones de valores según ciertas variables presentes en la

cadena de consulta. En ese caso, no existe un archivo .stk con el que hacer las

comprobaciones ACL; por lo tanto, se utilizaría la autorización de URL para

controlar el acceso al recurso virtual.

La autorización de archivo se realiza siempre con la cuenta autenticada su-

ministrada por IIS. Si se permite el acceso anónimo, esta cuenta es la cuenta

anónima configurada. Las listas ACL de archivos se configuran para un de-

terminado archivo o directorio mediante la ficha Seguridad de la página de

propiedades del Explorador. La autorización de URL se configura como partede una aplicación ASP.NET Framework (ver apartado “Autorización”).

Como hemos visto anteriormente, para activar un servicio de autenticación

de ASP.NET debe configurarse el elemento <authentication> en el archivo

Web.config correspondiente. Este elemento puede tener uno de los valores

siguientes: ―None‖ si no se activa ningún servicio de autenticación de

ASP.NET, aunque los servicios de autenticación de IIS pueden estar aún pre-

sentes; ― Windows‖, para dejar que sea el sistema operativo del servidor quien

realice la autenticación; ―Forms‖, de forma que los servicios de autenticación

de ASP.NET administran las cookies y desvían a los usuarios no autenticadosa una página de inicio de sesión; y ―Passport‖, de manera que los servicios de

El mecanismo de ACL ( Access Control List ) permite deter-minar los permisos de accesoa un objeto del sistema de-pendiendo de aspectos preci-sos del proceso que hace la

solicitud.




autenticación de ASP.NET proporcionan un envoltorio para los servicios

suministrados por el SDK de Passport, el cual debe instalarse en el servidor.

6.1.1. Autenticación basada en Windows

Cuando se utiliza la autenticación basada en Windows, ASP.NET asocia un

objeto de la clase WindowsPrincipal a la solicitud en curso, de forma que la auto-

rización de dirección URL utiliza dicho objeto para las comprobaciones. Por

otra parte, la aplicación también puede utilizar dicho objeto programática-

mente para determinar si la identidad solicitante pertenece a un determina-

do perfil de usuario.

La clase WindowsPrincipal determina el perfil del usuario a partir de la pertenen-

cia a un grupo de NT. Si la aplicación desea gestionar sus propios perfiles de

usuario puede hacerlo mediante el control del evento WindowsAuthentica-

tion_OnAuthenticate en su archivo Global.asax y la asociación a la solicitud de su

propia clase que implemente System.Security.Principal.IPrincipal , como muestra el

ejemplo de la Figura 67.

Finalmente, la Figura 68 muestra cómo obtener acceso al nombre de unusuario ya autenticado. Como se observa, éste está disponible como

User.Identity.Name . La Figura 69 muestra la página en ejecución.

6.1.2. Autenticación basada en formularios

El servicio de autenticación basada en formularios de ASP.NET permite a las

aplicaciones ofrecer su propia interfaz de inicio de sesión y hacer su propia

verificación de credenciales. ASP.NET permite autenticar usuarios y desviar a

los usuarios no autenticados hacia la página de inicio de sesión, además de

realizar todas las tareas de administración de cookies .

If (User.IsInRole("Administrators")) {CodigoAEjecutar();

}

// Creación de una clase que implemente IPrincipalpublic class MiPrincipal : IPrincipal {// Implementa los perfiles propios de la aplicación

}

// En el archivo Global.asax:public void WindowsAuthentication_OnAuthenticate(Object Source, Win-dowsAuthenticationEventArgs e) {

// Se asocia la clase que implementa IPrincipal a la solicitud// Puesto que IIS ya ha realizado la autenticación, se usa la identidad que IIS proporcionae.User = new MiPrincipal(e.Identity);

}

Figura 67. Derivando de IPrincipal.




Para que una aplicación pueda utilizar autenticación basada en formularios,

se debe configurar el elemento <authentication> del archivo Web.config con la

opción Forms y denegar el acceso a los usuarios anónimos:

El administrador de la aplicación puede usar este tipo de autenticación para

configurar el nombre de la cookie a usar, el tipo de protección, la URL de la

página de inicio de sesión, el tiempo de validez de la cookie y la ruta de acce-

so a la cookie suministrada. La siguiente tabla muestra los atributos válidos

para el elemento <Forms>, que es un subelemento del elemento <authentication> :


<body><table Width="600" rules="all" bordercolor="Black"><tr>

<td>Usuario:</td> <td><asp:label id=AuthUser runat=server/></tr><tr>

<td>Tipo de autenticación:</td> <td><asp:label id=AuthType runat=server/></tr>

</table></body>

</html>

En el archivo Ejemplo.aspx.csvoid Page_Load(Object Src, EventArgs E ) {

AuthUser.Text = User.Identity.Name; AuthType.Text = User.Identity.AuthenticationType;

}

En el archivo Web.config<configuration><system.web><authentication mode="Windows" />

</system.web></configuration>

Figura 68. Ejemplo de uso de la autenticación basada en Windows.

<configuration><system.web><authentication mode="Forms"/><authorization> <deny users="?" /> </authorization>


Figura 69. Ejemplo de uso de la autenticación basada en Windows: ejecución.




Atributo Descripción loginUrl URL (local o remota) de inicio de sesión a la que se desvían los

usuarios no autenticados.

name Nombre de la cookie que se va a usar para la autenticación. Sivarias aplicaciones van a usar autenticación basada en formulariosen un mismo servidor, cada aplicación deberá configurar unacookie única.

timeout Tiempo (en minutos) tras el cual la cookie caduca. El valor prede-terminado es 30 .

path Ruta de acceso que se utiliza para la cookie suministrada.

protection Método utilizado para proteger los datos de las cookies :

All: Utiliza validación y cifrado de datos para proteger la cookie . Siestá disponible se usa TripleDES. Opción predeterminada.

None: Se usa con sitios que utilizan cookies sólo para personaliza-ción y que tienen requisitos de seguridad menores.

Encryption: Permite cifrar la cookie mediante DES o TripleDES, perono se realiza validación de datos. Este tipo de cookie puede sufrirataques en lo que se refiere a la selección de texto sin formato.

Validation: La cookie no está cifrada, pero se valida para comprobarque no ha sido modificada durante la transmisión.

Una vez configurada la aplicación debe proporcionarse una página de inicio

de sesión. Cuando se ejecuta el ejemplo de la Figura 70 se solicita la página

Default.aspx. Las solicitudes no autenticadas se desvían a la página de inicio desesión Login.aspx, la cual presenta un formulario sencillo que pide una direc-

ción de correo electrónico ([email protected]) y una contraseña (pwd). Tras vali-

dar las credenciales se realiza la llamada a RedirectFromLoginPage , de forma que

se redirige al usuario hacia la URL original solicitada. La Figura 71 muestra

las diversas páginas durante la ejecución.

Las cookies de autenticación pueden ser temporales o permanentes. Las coo-

kies temporales tienen la duración de la sesión actual del navegador. Por otra

parte, el navegador se encarga de almacenar y gestionar las cookies perma-

nentes.

DES (Data Encryption Stan- dard) es un método de cifra-do de información diseñadopor IBM en 1975. Considera-

do inseguro por fuerza brutadesde 1994, ha sido substi-tuido mayoritariamente por TripleDES, la aplicación con-secutiva de tres cifrados detipo DES.

<authentication mode="Forms"><forms name=".ASPXCOOKIEDEMO" loginUrl="login.aspx" protection="all"

timeout="30" path="/"></forms>

</authentication>




Archivo Default.aspx<%@ Import Namespace="System.Web.Security " %><html>

<script language="C#" runat="server">void Signout_Click (Object sender, EventArgs E) {

FormsAuthentication.SignOut();Response.Redirect("Login.aspx");}

</script><body><form runat="server" id="Form2">

<h3><asp:label id="Bienvenido" runat="server" /></h3><asp:button text="Cerrar sesión" OnClick="Signout_Click" runat="server" id="Button1" />

</form></body>

</html>

En el archivo Default.aspx.csvoid Page_Load(Object Src, EventArgs E ) {

Bienvenido.Text = "Hola, " + User.Identity.Name;

}Archivo Login.aspx<%@ Import Namespace="System.Web.Security " %><html>

<script language="C#" runat=server>void Login_Click (Object sender, EventArgs E) {

// Autenticación del usuario "[email protected]"-"pwd"if ((UserEmail.Value == "[email protected]") && (UserPass.Value == "pwd"))

FormsAuthentication.RedirectFromLoginPage(UserEmail.Value, false);else

Msg.Text = "Credenciales no válidas, inténtelo de nuevo";}

</script><body>

<form runat=server ID="Form1"><h3>Inicio de sesión</h3><table>

<tr><td>Dirección de e-mail:</td><td><input id="UserEmail" type="text" runat=server/></td><td><ASP:RequiredFieldValidator ControlToValidate="UserEmail" Display="Static"

ErrorMessage="*" runat=server ID="Requiredfieldvalidator1"/></td></tr><tr><td>Contraseña:</td><td><input id="UserPass" type=password runat=server/></td><td><ASP:RequiredFieldValidator ControlToValidate="UserPass" Display="Static"

ErrorMessage="*" runat=server ID="Requiredfieldvalidator2"/></td></tr>

</table><asp:button text="Inicio de sesión" OnClick="Login_Click" runat=server ID="Button1"/><p> <asp:Label id="Msg" ForeColor="red" runat=server />

</form></body>

</html>

En el archivo Web.config<authentication mode="Forms">

<forms name=".ASPXUSERDEMO" loginUrl="Login.aspx" protection="All" timeout="60" /></authentication><authorization>

<deny users="?" /></authorization>

Figura 70. Ejemplo de uso de la autenticación basada en formularios.




6.1.3. Autorización

Como ya se ha visto en el apartado “Configuración de la aplicación”,

ASP.NET puede configurarse mediante Web.config para controlar el acceso de

los clientes a determinadas URL. Esto puede hacerse selectivamente para

cada método HTTP que se utilice en la solicitud (GET o POST) y, también, para

permitir o denegar el acceso a grupos de usuarios o perfiles. El siguiente

fragmento de archivo Web.config configura el permiso de acceso (directiva

allow) a los usuarios [email protected] y Juan, a todos los usuarios que pertenez-

can al perfil Admins y a cualquier usuario autenticado (―*‖) que acceda me-

diante método GET. El mismo fragmento también deniega el acceso (directivadeny) al resto de usuarios sean anónimos (―?‖) o no (―*‖).


Figura 71. Ejemplo de uso de la autenticación basada en formularios: ejecución.




Los nombres de usuario especiales (―?‖ y ―*‖) se utilizan comúnmente en

aplicaciones que usan autenticación basada en formularios para denegar el

acceso a los usuarios no autenticados.

Finalmente, cabe hacer notar que el archivo Web.config predeterminado de

nivel superior para un determinado equipo permite el acceso a todos los

usuarios. Así pues, a menos que una aplicación se configure de forma contra-

ria (y suponiendo que el usuario reciba autenticación y pase la comproba-

ción de ACL para el acceso a los archivos), el acceso se concede.

6.2. Seguridad y el modelo de proveedores

Una de las características de la seguridad en ASP.NET 2.0 es su simplicidad de

uso, derivada de la adopción del modelo de proveedores (ver el apartado

“Arquitectura de ASP.NET: modelo de proveedores”). Por ejemplo, se puede

comenzar a registrar y autenticar a los usuarios comparando la información

de una base de datos inmediatamente después de habilitar la autenticación

por formularios, sin necesidad de generar tablas de base de datos ni de escri-bir ningún código.

El modelo de proveedores proporciona un método estándar para conectar los

componentes encargados de implementar los distintos servicios de una apli-

cación. En el caso concreto de la seguridad se emplean dos tipos de provee-

dores: el proveedor de pertenencia a grupo y el proveedor de roles. El pro-

veedor de pertenencia a grupo se utiliza para almacenar nombres de usuario

y contraseñas, mientras que el proveedor de roles se emplea para almacenar

roles de usuario.

ASP.NET 2.0 se ofrece con dos proveedores de pertenencia a grupo: el prede-

terminado AccessMembershipProvider y un proveedor SqlMembershipProvider . El

proveedor AccessMembershipProvider almacena los nombres de usuario y las con-

traseñas en una base de datos de Microsoft Access. Esta base de datos se crea

automáticamente en la carpeta Data de la aplicación. Es más, si la base de

datos de Access se eliminase accidentalmente, se volvería a crear automáti-

camente la próxima vez que se intentara la conexión a la base de datos. Si se

desea almacenar información de pertenencia a grupo en una base de datos

de Microsoft SQL Server, se puede configurar la aplicación para que utilice el

proveedor SqlMembershipProvider sin necesidad de volver a escribir el código de

la aplicación.

<authorization><allow users="[email protected], Juan "/><allow roles="Admins" /><allow VERB="GET" users="*" /><deny users="?‖ /><deny users="*" />

</authorization>




También se puede crear un proveedor de pertenencia a grupo personalizado.

Por ejemplo, se podría desear almacenar la información de pertenencia a

grupo en un archivo XML, una base de datos de FoxPro o de Oracle, o inclu-

so implementar un proveedor de pertenencia a grupo que recuperara la in-

formación mediante un servicio Web. Si la intención es crear un proveedor

de pertenencia a grupo propio, se deberán implementar todos los métodos y

propiedades de la clase abstracta MembershipProvider .

6.2.1. Uso de SqlMembershipProvider

Utilizar una base de datos de Access resulta adecuado cuando se está desarro-

llando una aplicación Web destinada a un grupo reducido de usuarios. Si se

precisa crear una aplicación más robusta lo recomendable es almacenar los

nombres de usuario y las contraseñas en una base de datos escalable como

Microsoft SQL Server.

Para almacenar la información de pertenencia a grupo en una base de datos

de Microsoft SQL Server es necesario modificar el proveedor de pertenencia a

grupo predeterminado de la aplicación. Una posibilidad es usar la configura-

ción de la aplicación. Por ejemplo, el siguiente archivo Web.Config establece

AspNetSqlProvider como el proveedor de pertenencia a grupo predeterminado:

Si no se desea recurrir al archivo Web.Config se pueden cambiar los proveedo-

res con la herramienta de administración de sitios Web (ver apartado

“Herramienta de configuración de la seguridad”) o con el complemento de

ASP.NET Microsoft Management Console (MMC) para IIS (ver Figura 72).

Ambas herramientas ofrecen una interfaz descriptiva para la especificación

del proveedor de pertenencia a grupo.

A diferencia del proveedor de Microsoft Access, antes de utilizar el proveedor

de SQL será preciso crear las tablas de base de datos y los procedimientos

almacenados necesarios. Los objetos de la base de datos de SQL Server se

pueden crear automáticamente ejecutando la herramienta aspnet_regsql desde

la línea de comandos (ver Figura 73). Esta herramienta crea de forma prede-

terminada una nueva base de datos llamada aspnetdb en la instancia local de

SQL Server. Después de crear la nueva base de datos, será necesario compro-

bar que la aplicación ASP.NET puede obtener acceso a ella. De forma prede-

terminada se utiliza una seguridad integrada, por lo que será preciso asegu-

rarse de que la cuenta de ASP.NET (NT AUTHORITY\NETWORK SERVICE en el casode Windows Server 2003 o ASPNET en el caso de Windows 2000 o XP) dispo-

ne de los permisos necesarios para obtener acceso a la base de datos aspnetdb.

<configuration><system.web>

<membership defaultProvider="AspNetSqlProvider" />





6.2.2. Configuración del proveedor de pertenencia a grupo

Pueden emplearse los atributos del proveedor de pertenencia a grupo paracontrolar la forma en la que la información de pertenencia a grupo se alma-

cena y recupera de la base de datos. Los valores de los atributos se pueden

Figura 73. Configuración de SqlMembershipProvider con aspnet_regsql.

Figura 72. Configuración de proveedores en IIS.




modificar en el archivo Web.config. Tanto AccessMembershipProvider como

SqlMembershipProvider admiten varios atributos de proveedor específicos:

Atributo Descripción

applicationName Si se precisa alojar varias aplicaciones en el mismoservidor Web, se puede utilizar esta propiedad paraaislar a los usuarios asociados con las distintas aplica-ciones.

connectionStringName Nombre de la cadena de conexión a la base de datos

definida en la sección connectionStrings del archivo

Web.config .

description Descripción de la definición del proveedor. enablePasswordReset Si vale true, los usuarios pueden restablecer sus con-

traseñas y utilizar una generada de forma aleatoria. enablePasswordRetrieval Si vale true, las contraseñas de los usuarios se pueden

recuperar del proveedor de pertenencia a grupo.

passwordFormat Tiene tres valores posibles: Clear , Encrypted y Hashed. Si

las contraseñas tienen el valor hashed, las contraseñas

originales no se pueden recuperar del proveedor de

pertenencia a grupo.

requiresQuestionAndAns-

wer

Si vale true, el usuario debe responder a una preguntapara poder restablecer o recuperar su contraseña.

requiresUniqueEmail Si vale true, se debe asociar una dirección de correo

electrónico exclusiva con cada usuario.

Por ejemplo, el atributo passwordFormat determina cómo se almacenan las

contraseñas en la base de datos: como texto sin cifrar (Clear ), cifradas (Encryp-

ted) o valores hash de contraseñas (Hashed). La última opción es la más segura

ya que permite almacenar valores hash en la base de datos en lugar de las

contraseñas reales. Así si la seguridad de la aplicación resulta comprometida,

un usuario malintencionado no podrá robar las contraseñas auténticas.

6.3. Herramienta de configuración de la seguridad

La herramienta de administración de sitios Web que incluye ASP.NET 2.0

permite configurar una aplicación desde una interfaz Web (ver Figura 74). Al

margen de otros aspectos no relacionados con la seguridad, permite crear y

administrar usuarios y roles así como controlar el acceso a las carpetas y las

páginas de una aplicación Web.

La interfaz de administración Web es accesible de diversas formas. Si se desea

crear una aplicación Web con Visual Studio, se puede abrir la herramienta

seleccionando ASP.NET Configuration en el menú Website. Si lo que sedesea es desarrollar una aplicación Web fuera de Visual Studio, se puede

tener acceso a la herramienta directamente solicitando la página especial




WebAdmin.axd. Por ejemplo, si la aplicación se encuentra en un directorio

virtual llamado MiAppWeb en el equipo local, se puede abrir la herramienta de

administración de sitios Web para la aplicación especificando la URL

http://localhost/MiAppWeb/WebAdmin.axd en el navegador.

La herramienta se compone de una serie de páginas ASP.NET que utilizan loscontroles de Login estándard (ver siguiente apartado). Estas páginas se ubican

en la carpeta inetpub\wwwroot\aspnet_webadmin. Si por cualquier motivo los

archivos se eliminaran accidentalmente del servidor, podrían reinstalarse

automáticamente ejecutando la herramienta aspnet_regiis. aspnet_regiis también

puede usarse para controlar el acceso a la herramienta de administración de

sitios Web, por ejemplo restringiendo el acceso sólo desde el servidor local.

6.4. Controles de Login

ASP.NET 2.0 proporciona diversos controles relacionados con la seguridad

que se conocen en su conjunto como controles de Login. Mediante estos con-

troles pueden crearse páginas estándar de registro, de inicio de sesión y de

recuperación de contraseñas sin necesidad de escribir código. También se

emplean para mostrar información diferente a los usuarios dependiendo de

sus roles y de su estado de autenticación. Por ejemplo, el control LoginView

podría usarse para mostrar una información a los miembros con rol de ad-

ministrador y otra distinta a los miembros con rol de invitado.

Por otra parte, estos controles aprovechan toda la funcionalidad del modelode proveedores. Así, si se ha configurado la aplicación para que utilice Ac-

cessMembershipProvider , los controles de Login realizarán automáticamente una

Controles de login en VisualStudio 2005

Figura 74. Herramienta de administración de sitios Web.




consulta a la base de datos de Access para recuperar la información de la

pertenencia a grupo. Si se habilita SqlMembershipProvider , los controles utili-

zarán la base de datos de SQL Server configurada.

Antes de tratar cada uno de los controles disponibles, debe tenerse en cuenta

que para poder usarlos es preciso habilitar la autenticación por formularios

para la aplicación. Esto puede hacerse tanto desde el archivo Web.config como

desde la herramienta de administración de sitios Web vista anteriormente.

6.4.1. Control Login

El control Login permite crear una página estándar de inicio de sesión agre-

gando una simple etiqueta a una página. Por ejemplo:

El control Login genera automáticamente una interfaz de inicio de sesión

estándar (ver Figura 75) compuesta por cuadros de texto de nombre de usua-

rio y contraseña, una casilla de verificación para recordar al usuario la

próxima vez que inicie sesión y un botón para enviar la información. Al

enviar el nombre de usuario y la contraseña, el proveedor de pertenencia a

grupo valida las credenciales automáticamente.

La lista de propiedades del control Login es muy amplia. La mayoría permiten

personalizar la interfaz, pero además se pueden configurar propiedades como

CreateUserUrl y PasswordRecoveryUrl para crear vínculos a una página de registro y

una página de recuperación de contraseñas, respectivamente. Otra propiedad

muy utilizada es VisibleWhenLoggedIn, que permite ocultar automáticamente el

control Login cuando el usuario ya se ha autenticado. Por ejemplo, si se desea

incluir el control Login en cada página de la aplicación, con la propiedad

VisibleWhenLoggedIn se podrá ocultar automáticamente el control en cuento el

usuario se haya autenticado.

6.4.2. Control CreateUserWizard

CreateUserWizard permite crear una página estándard de registro de usuarios en

la aplicación agregando una etiqueta tan simple como:

<asp:Login ID="Login1" Runat="server" />

Figura 75. Control Login en tiempo de diseño.




La apariencia exacta del control dependerá de la configuración del proveedor

de pertenencia a grupo de la aplicación. Por ejemplo, los cuadros de texto dela pregunta y la respuesta para recuperar la contraseña sólo aparecen cuando

el atributo requiresQuestionAndAnswer es true. Por ejemplo, la interfaz de la Figura

76 corresponde al proveedor de pertenencia a grupo predeterminado AspNe-

tAccessProvider .

Una de las cosas más interesantes que permite hacer el control CreateUserWi-

zard es enviar automáticamente un mensaje de correo electrónico de registro

después de que el usuario ha completado todos los pasos del registro. Por

ejemplo, se puede enviar al usuario un mensaje con su nombre de usuario y

la contraseña. También se puede configurar el mensaje enviado mediante la

propiedad MailDefinition del control. El siguiente fragmento de código, por

ejemplo, hará que el control CreateUserWizard envie el contenido del archivo

EmailDeRegistro.txt como cuerpo del mensaje de correo electrónico de registro

siempre que alguien complete el asistente de registro (CreateUserWizard emplea

el servidor de correo electrónico especificado en la sección <smtpMail> de Web.config):

Dentro del archivo EmailDeRegistro.txt pueden emplearse expresiones especiales,

como <% UserName %> y <% Password %>, para sustituir el nombre de usuario yla contraseña del nuevo usuario registrado.

Figura 76. Control CreateUserWizard en tiempo de diseño.

<asp:CreateUserWizard ID="CreateUserWizard1" Runat="server" />

<asp:CreateUserWizard ID="CreateUserWizard1" Runat="server"><MailDefinition

BodyFileName="EmailDeRegistro.txt"From="[email protected]"Subject="Gracias por registrarte!">

</MailDefinition></asp:CreateUserWizard>




La funcionalidad de correo electrónico del control CreateUserWizard también

puede usarse para implementar procedimientos de registro más complicados,

como aquellos en los que es preciso validar la dirección de correo electrónico

del usuario antes de permitirle el acceso a la aplicación Web. Si se habilita la

propiedad AutoGeneratePassword del control CreateUserWizard, el control generará

de forma aleatoria una contraseña para el usuario, que puede enviársele me-

diante la funcionalidad de correo electrónico. Si el usuario posteriormente la

utiliza para autenticarse en la aplicación, se confirmará que el usuario ha

facilitado una dirección de correo electrónico válida.

6.4.3. Control PasswordRecovery

El control PasswordRecovery permite que los usuarios de la aplicación puedan

solicitar un mensaje de correo electrónico de recordatorio de su contraseña

(ver Figura 77). Al igual que en el control CreateUserWizard, las propiedades delmensaje de correo electrónico enviado al usuario se definen mediante la

propiedad MailDefinition. Por ejemplo, la etiqueta siguiente agrega un control

PasswordRecovery a una página Web que envía un mensaje de correo electróni-

co desde la cuenta de correo electrónico [email protected] :

El control PasswordRecovery se comporta de forma distinta dependiendo de la

configuración del proveedor de pertenencia a grupo predeterminado. Si el

atributo enablePasswordRetrieval es true y el atributo passwordFormat no es Hashed, se

envía la contraseña de texto sin cifrar en el mensaje de correo electrónico.

En cualquier otra combinación de valores de atributos, la contraseña se res-

tablece en una secuencia aleatoria de caracteres que se envía al usuario.

6.4.4. Control ChangePassword

El control ChangePassword permite a los usuarios cambiar sus contraseñas. El

control crea cuadros de texto en los que se puede facilitar la contraseña ori-ginal y la nueva (ver Figura 78).

Figura 77. Control PasswordRecovery en tiempo de diseño.

<asp:PasswordRecovery ID="PasswordRecovery1" Runat="server"><MailDefinition

From="[email protected]"Subject="Recordatorio de contraseña">

</MailDefinition></asp:PasswordRecovery>




Al igual que los controles CreateUserWizard y PasswordRecovery, ChangePassword

también incluye una propiedad MailDefinition. Cuando se asignan valores a la

propiedad MailDefinition, el control ChangePassword envía automáticamente un

mensaje de correo electrónico al usuario cuando se cambia correctamente

una contraseña. La etiqueta siguiente declara una instancia del control Chan-

gePassword y define la propiedad MailDefinition.

La propiedad BodyFileName incluye la ruta a un archivo de texto que contiene

el cuerpo del mensaje de correo electrónico que se envía al usuario. En elarchivo se pueden utilizar expresiones especiales como <% UserName %> y <%

Password %> para mostrar el nombre de usuario y la contraseña.

6.4.5. Controles LoginName y LoginStatus

Los controles LoginName y LoginStatus permiten mostrar información sobre el

estado actual de la autenticación de un usuario. Después de que un usuario

ha iniciado sesión en la aplicación, el control LoginName muestra su nombre

de usuario registrado. Si no se emplea autenticación por formularios el con-

trol LoginName no muestra nada. Puede declararse un control LoginName de lasiguiente manera:

Por su parte, LoginStatus permite que el usuario inicie o cierre sesión en la

aplicación. El control muestra uno de dos vínculos: si el usuario no se ha

autenticado, se muestra un vínculo a la página Login.aspx; si ya se ha autenti-

cado, se muestra un vínculo que le permite cerrar sesión. El control LoginStatus

se declara simplemente como:

Figura 78. Control ChangePassword en tiempo de diseño.

<asp:ChangePassword ID="ChangePassword1" Runat="server"><MailDefinition

BodyFileName="~/EmailCambioPassword.txt"From="[email protected]"Subject="Tu contraseña se ha actualizado">

</MailDefinition></asp:ChangePassword>

<asp:LoginName ID="LoginName1" Runat="server" />

<asp:LoginStatus ID="LoginStatus1" Runat="server" />




6.4.6. Control LoginView

El control LoginView permite mostrar contenido distinto dependiendo del rol

concreto del usuario. Por ejemplo, muchos sitios Web muestran información

distinta en su página principal en función de si el usuario es nuevo o ya está

registrado. Los nuevos usuarios pueden ver una descripción general del sitio

Web, mientras que los ya registrados pueden ver la información que se ha

creado específicamente para ellos.

El siguiente código muestra cómo se puede utilizar LoginView para mostrar

contenido distinto a un usuario anónimo y a un usuario autenticado. El

usuario anónimo verá el contenido incluido en la plantilla AnonymousTemplate,

mientras que el autenticado verá el contenido incluido en la plantilla Logge-

dInTemplate:

Si se habilitan los roles predeterminados para una aplicación Web, puede

usarse LoginView para mostrar contenido específico a miembros de determina-

do rol. El siguiente código muestra un ejemplo en el que cierto contenido

sólo es visible a los miembros del rol Administrators:

Así, los miembros del rol Administrators podrán ver cualquier contenido que

incluya la plantilla <ContentTemplate> asociada con el grupo de roles Administra-

dors. Un miembro del rol Administrators, sin embargo, no podrá ver el conteni-

do declarado en la plantilla LoggedInTemplate o en la plantilla Anonymous. Sólo

es posible ver el contenido de una plantilla en un momento determinado,incluso cuando más de una aplica al usuario en cuestión.

<asp:LoginView ID="LoginView1" Runat="server"><LoggedInTemplate>

Hola de Nuevo <asp:LoginName ID="LoginName1" Runat="server" /></LoggedInTemplate><AnonymousTemplate>

Bienvenido nuestra Web! Si fueses un usuario registrado,ahora mismo podrías estar disfrutando de grandes contenidos!

</AnonymousTemplate></asp:LoginView>

<asp:LoginView ID="LoginView1" Runat="server"><RoleGroups>

<asp:RoleGroup Roles="Administrators"><ContentTemplate>

Contenido para administradores!</ContentTemplate>

</asp:RoleGroup></RoleGroups><LoggedInTemplate>

Hola de Nuevo <asp:LoginName ID="LoginName1" Runat="server" /></LoggedInTemplate><AnonymousTemplate>

Bienvenido nuestra Web! Si fueses un usuario registrado,ahora mismo podrías estar disfrutando de grandes contenidos!

</AnonymousTemplate></asp:LoginView>




6.5. API de pertenencia a grupo

Aunque los controles de Login y la herramienta de administración de sitios

Web proporcionan funcionalidad suficiente para cubrir un amplio rango de

situaciones, en ocasiones es necesario disponer de mayor en control sobre la

seguridad. Es tales casos puede recurrirse directamente a la API de pertenen-

cia a grupo, que se expone al programador mediante la clase Membership. La

clase incluye métodos para la creación de usuarios, la gestión de contraseñas,

etc. Dichos métodos son precisamente los que usan los controles de Login

para interactuar con el proveedor de pertenencia a grupo correspondiente.

La siguiente tabla resume la funcionalidad de algunos de los métodos más

relevantes de la clase Membership:

Método Descripción CreateUser Permite crear nuevos usuarios. DeleteUser Permite eliminar usuarios existentes.

FindUsersByEmail Permite recuperar una colección de usuarios que coin-ciden con cierta dirección de correo electrónico.

FindUsersByName Permite recuperar una colección de usuarios que coin-ciden con cierto nombre de usuario.

GeneratePassword Permite generar una contraseña aleatoria.

GetAllUsers Permite recuperar todos los usuarios almacenados en

el proveedor de pertenencia a grupo.GetNumberOfUsersOnli-

ne

Devuelve el número de usuarios que han obtenidoacceso en un momento concreto a la aplicación.

GetUser Permite recuperar la información de pertenencia agrupo asociada con el usuario actual o con un usuarioque utiliza un nombre de usuario dado.

GetUsernameByEmail Permite recuperar el nombre del usuario que tienecierta dirección de correo electrónico.

UpdateUser Permite actualizar la información de un usuario.

ValidateUser Permite autenticar a un usuario con los datos del pro-

veedor de pertenencia a grupo.

Por ejemplo, es posible crear un usuario “Pedro” con la contraseña “12345”

de la siguiente forma:

Varios de los métodos de la tabla anterior, como GetAllUsers y FindUsersByName,

devuelven colecciones de objetos de la clase MembershipUser . Dicha clase re-

presenta información sobre un usuario concreto y contiene las siguientespropiedades y métodos:

Membership.CreateUser( "Pedro", "12345" );




Propiedad Descripción Comment Comentario asociado al usuario. CreationDate Fecha en la que se creó el usuario.

Email Dirección de correo electrónico del usuario. IsApproved Indica si se ha aprobado o no al usuario.

IsOnline Indica si el usuario está accediendo o no a laaplicación en un momento determinado.

LastActivityDate Fecha del último acceso del usuario a la apli-cación.

LastLoginDate Fecha en la que se autenticó por última vez alusuario.

LastPasswordChangedDate Fecha en la que se cambió por última vez lacontraseña de usuario.

PasswordQuestion Pregunta y respuesta para recuperar la contra-seña.

Provider Proveedor de pertenencia a grupo.

Username Nombre del usuario.

Método Descripción ChangePassword Permite cambiar la contraseña del usuario.

ChangePasswordQuestionAndAns-wer

Permite cambiar la pregunta y la respuestapara recuperar la contraseña.

GetPassword Permite recuperar la contraseña del usuario.

ResetPassword Permite restablecer la contraseña del usuario.




7. Diseño de la interfaz de usuario

Este apartado se centra en algunos de los aspectos más relevantes desde el

punto de vista del diseño de interfaces de usuario, tanto a nivel de una pági-

na, como a nivel de un sitio Web completo. Se empieza con la creación de

controles de usuario y a continuación se cubren aspectos como las páginas

maestras, los temas visuales y las Web Parts. Esto últimos aspectos corres-

ponden a mecanismos incorporados con la versión 2.0 de ASP.NET.

7.1. Controles personalizados

Como se puede ver en el Apéndice “Controles Web Forms : Referencia”,

ASP.NET proporciona un amplio conjunto de controles para construir la

interfaz de usuario de una aplicación. Al margen de dichos controles, la ma-

yoría accesibles directamente desde la caja de herramientas de Visual Studio,

también es posible usar controles de terceros. Sin embargo, lo que resulta

más interesante es la posibilidad de desarrollar controles Web propios, para

posteriormente usarlos en la construcción de interfaces ASP.NET, reutilizar

código de forma inteligente y conseguir aplicaciones mejor estructuradas.

Una posible clasificación de los distintos tipos de controles Web personaliza-

dos podría ser la siguiente:

Controles de usuario o pagelets . No pueden considerarse controles

ASP.NET propiamente. Se trata de fragmentos de código HTML que pue-

den reutilizarse como si de componentes se tratase.

Controles a medida. Derivados directamente de la clase Control (definida

en System.Web.UI) o bien de una de sus clases descendientes de primer ni-

vel, como WebControl (definida en System.Web.UI.WebControls). Estas clases ba-

se no ofrecen ninguna funcionalidad predeterminada, en el caso de Control

ni siquiera las propiedades para mantener una interfaz de usuario en la

página, lo que permite desarrollar controles totalmente nuevos y distintos

a los proporcionados por ASP.NET.

Los siguientes apartados analizan los diversos tipos de controles.

7.1.1. Controles de usuario

Un pagelet es un fragmento de código HTML que, almacenado en un archi-

vo, puede reutilizarse como un componente en diversas páginas Web.Además, el contenido del componente puede personalizarse para cada pági-

na mediante el uso de propiedades, como si de un control se tratase. En con-




secuencia, los pagelets son la base para el desarrollo de controles personali-

zados sencillos usando las mismas técnicas de programación que en la cons-

trucción de cualquier formulario Web de ASP.NET.

Un pagelet se almacena en un archivo con extensión .ascx, lo cual lo identifi-

ca como un control de ASP.NET y, al mismo tiempo, impide que el control

pueda ejecutarse como una página Web independiente. El siguiente código

HTML corresponde al pagelet copyright.ascx que usaremos como ejemplo:

Para poder usar un control externo no propio de ASP.NET (un pagelet puede

considerarse así) en una página Web, el citado control debe registrarse. Esto

se lleva a cabo mediante la directiva Register :

En ella el atributo Src indica donde se encuentra el archivo .ascx con el código

del pagelet . Si en lugar de un archivo .ascx con código HTML se tratase de un

control almacenado en un ensamblado de .NET, se substituiría el parámetro

Src por Assembly. En el registro, TagPrefix determina el espacio de nombres al

que va a pertenecer el nuevo control, mientras que TagName asigna un nom-

bre único al control en dicho espacio de nombres. Esto permitirá incluir el

pagelet en una página mediante la notación prefijo:nombre , de la misma forma

que los controles de servidor propios de ASP.NET. Así como para insertar un

botón se introduce una marca asp:button, del mismo modo puede introducirse

una marca UOC:copyright en cualquier página donde se haya efectuado el re-

gistro para insertar el pagelet anterior, incluido el atributo runat=‖server‖:

Aunque la posibilidad de reutilizar en una página porciones de código HTML

escribiendo simplemente una marca es de gran utilidad, ésta aumenta si

disponemos de la capacidad para personalizar el contenido en cada caso.

Para ello basta con adjuntar código de script al contenido HTML, declaran-

do un conjunto de variables (con valores por defecto, si se desea), propieda-

des y métodos públicos, que se convierten automáticamente en variables,

propiedades y métodos públicos del control. Así pues, podrán usarse poste-

riormente en el contenido HTML para representar elementos como colores,

textos, etc. y parametrizar el comportamiento del control.

<%@ Register TagPrefix=‖UOC‖ TagName=‖copyright‖ Src=‖copyright.ascx‖ %>

<%@ Register TagPrefix="UOC" TagName="copyright" Src="copyright.ascx" %><html>

<body><h3>Ejemplo de Pagelet</h3><UOC:copyright runat="server" ID="Copyright"/>

</body></html>

<HR /> <P> (c) Master .NET, UOC </P>




El pagelet de la Figura 79 implementa el control UOC:Direccion que permite

solicitar una dirección postal al usuario. El código declara el string público

Titulo al que se le puede asignar un valor o consultarlo tanto declarativa comoprogramáticamente. También se declaran propiedades para exponer algunas

propiedades de los TextBox que forman el control. El control resultante hereda

Archivo Ejemplo.aspx<%@ Register TagPrefix="UOC" TagName="Direccion" Src="direccion.ascx" %><html>

<script language="C#" runat="server">void SubmitBtn_Click(Object sender, EventArgs E) {

MyLabel.Text += "<br><b>" + DirEnvio.Titulo + ":</b> "+ DirEnvio.Direccion + ", " +DirEnvio.Ciudad + ", " + DirEnvio.CodPostal + "<br>";MyLabel.Text += "<br><b>" + DirFactura.Titulo + ":</b> " + DirFactura.Direccion + ", " +

DirFactura.Ciudad + ", " + DirFactura.CodPostal + "<br>";}

</script><body><h3>Ejemplo de pagelet con propiedades</h3><form runat="server">

<UOC:Direccion id="DirEnvio" runat="server" Titulo="Dirección de envío"Direccion="Av. Tibidabo, 45-47" Ciudad="Barcelona" CodPostal="08035" />

<p><UOC:Direccion id="DirFactura" Titulo="Dirección de facturación" runat="server"/><p><asp:button Text="Enviar" OnClick="SubmitBtn_Click" runat="server" ID="Button1"/>

</form><asp:Label id="MyLabel" runat="server"/></body>

</html>

Archivo direccion.ascx<script language="C#" runat="server">

public String Titulo = "Dirección";

public String Direccion {get { return TxtDireccion.Value; }set { TxtDireccion.Value = value; }

}

public String Ciudad {

get { return TxtCiudad.Value; }set { TxtCiudad.Value = value; }}

public String CodPostal {get { return TxtCodPostal.Value; }set { TxtCodPostal.Value = value; }

}</script>

<table><tr><td> <b><%=Titulo%></b> </td>

</tr><tr>

<td> Dirección: </td><td colspan="4"> <input id="TxtDireccion" size="54" type="text" runat="server"> </td></tr><tr><td> Ciudad: </td><td> <input id="TxtCiudad" type="text" runat="server"> </td><td> Código postal: </td><td> <input id="TxtCodPostal" size="5" type="text" runat="server"> </td>

</tr></table>

Figura 79. Ejemplo de pagelet con propiedades.




automáticamente la capacidad de gestionar el estado de los TextBox que lo

componen. La página contiene dos instancias del nuevo control, con Titulo

diferente, asignándole a la primera valores iniciales de forma declarativa. La

Figura 80 muestra dos momentos durante la ejecución.

Al igual que los controles de servidor, los controles de usuario participan de

todo el periodo de duración de la ejecución de una solicitud. Esto significa

que un control de usuario puede controlar sus propios eventos mediante la

encapsulación de parte de la lógica de la página Web contenedora. Para ilus-

trarlo hemos modificado el ejemplo de la Figura 79, tal como muestra la

Figura 81. Se ha substituido el control HTML HtmlInputText correspondiente a

la introducción de la calle y número (TxtDireccion), por un control Web de

tipo TextBox, de forma que genere postbacks automáticamente. Además, se

atiende al evento OnTextChanged de forma que al introducirse la calle y el

número se asigne un código postal predeterminado al control HTML TxtCod-

Postal. Así, al introducir los datos de la calle, el cambio se captura y el códigopostal correspondiente se modifica, sin que eso altere a otras instancias del

control de usuario en la misma página.

El valor de una variable opropiedad de un controlpuede incluirse en el códigoHTML mediante la marca<%=variable%>, de la formahabitual en ASP.NET.

Figura 80. Ejemplo de pagelet con propiedades: ejecución.




Los controles de usuario, como los de servidor, también pueden crearse yañadirse al formulario programáticamente. Por ejemplo:

El método LoadControl de la página se utiliza para cargar el control de usuario

indicando la ruta de acceso virtual al archivo .ascx. El tipo de control de usua-

rio viene determinado por el motor de tiempo de ejecución de ASP.NET,

según la convención nombrearchivo _extension . Si se desea asignar un tipo

diferente al control, puede añadirse al archivo .ascx la directiva Control, indi-

cando el nombre del tipo en el atributo ClassName. Por ejemplo, para asignar

el tipo inflexible "DireccionCS" al control de usuario almacenado en el archivo

"direccion.ascx" se usará la siguiente directiva:

Puesto que el método LoadControl devuelve un tipo de System.Web.UI.Control,

debe convertirse al tipo inflexible adecuado para establecer propiedades in-

dividuales del control. Finalmente, el control de usuario se agrega a la colec-ción ControlCollection de la página base.

Como se ha visto, resulta muy sencillo reutilizar código en forma de contro-

les de usuario. Sin embargo este tipo de controles presenta ciertas desventa-

jas en comparación con los controles proporcionados por ASP.NET o un

control Web a medida. Los controles de usuario no pueden añadirse a la caja

de herramientas de Visual Studio y tampoco pueden editarse sus propiedades

desde el diseñador de formularios. Por otra parte, en necesario distribuir el

archivo .ascx correspondiente con cada aplicación utilice un determinado

control de usuario, además de la necesidad de registrar el control en cadapágina que lo incluya.

Cambios en el archivo direccion.ascx de la Figura 79<script>

… public String Direccion {get { return TxtDireccion.Text; }

set { TxtDireccion.Text = value; }}

void TxtDireccion_TextChanged(Object sender, EventArgs E) {this.CodPostal = "08000";

}…

</script>…

<asp:TextBox id="TxtDireccion" size="54" AutoPostBack="true"OnTextChanged="TxtDireccion_TextChanged" runat="server"></asp:TextBox>

…

Figura 81. Ejemplo de gestión de eventos en el control de usuario de la Figura 79.

Control DireccionEnvio = LoadControl("direccion.ascx");((DireccionCS) DireccionEnvio).Titulo = "Dirección de envío";Page.Controls.Add(DireccionEnvio);

<%@ Control ClassName="DireccionCS" %>




7.1.2. Controles a medida

Un control a medida (custom control ) se diferencia de un control de usuario

principalmente en que su código se almacena, ya compilado, en un ensam-

blado (assembly ) de tipo DLL de .NET. Este hecho implica una diferencia

fundamental en la distribución del control, puesto que es suficiente con

agregar dicho ensamblado a la caché global de ensamblados de .NET (GAC)

en el servidor, para que automáticamente todas las aplicaciones alojadas en

dicho servidor puedan usar el control. Otra diferencia, derivada del hecho de

tener que compilar el control, es que el contenido que genera el control no

puede introducirse simplemente como marcas HTML, sino que es precisoenviarlo programáticamente a un flujo de salida HTML.

Aunque es posible crear controles a medida sin interfaz de usuario, general-

mente nos interesará que el control genere algún contenido. Éste puede ser

tan simple como un mensaje de texto o tan complejo como una tabla de

datos. Todos los controles Web, al derivar de la clase Control, heredan el

método Render(), encargado de producir el contenido visual del control. En su

implementación por defecto Render() está vacío, por lo que es necesario rede-

finirlo en la implementación de la clase derivada. Así pues, para crear un

control a medida sencillo, basta con definir una clase que derive de Control yredefinir el método Render(). Este método recibe como parámetro un objeto

de la clase HtmlTextWriter , que tiene métodos como Write() y WriteLine() para es-

cribir en el flujo de salida HTML. El código HTML que el control enviará al

navegador del cliente debe pasarse como parámetro a dichos métodos. La

Figura 82 y la Figura 83 muestran el control a medida WebCC1 derivado de la

clase Control, así como su inclusión en una página Web. El nuevo control

puede insertarse en la página tanto de forma programática como declarativa,

y también arrastrándolo desde la caja de herramientas en el diseñador de

formularios.

La GAC, caché global deensamblados (global assem-bly cache) es un repositoriode ensamblados de .NET enun ordenador al que puedeacceder cualquier aplicación.NET, incluidas las aplicacio-nes ASP.NET. Al margen delacceso global, una de lascaracterísticas fundamentalesde la GAC es la posibilidad decontener múltiples copias deun mismo ensamblado, i.e. con el mismo nombre perocon distinta información de

versión.

En Visual Studio, una bibliote-ca de controles Web puedecontener una o más clases,representando cada una deellas un control a medida.Dichas clases deben ser públi-cas y derivar directa o indirec-tamente de Sys-tem.Web.UI.Control o,

mejor, de Sys-tem.Web.UI.WebControls.WebControl.


Figura 82. Ejemplo de control a medida. Derivando de Control y de WebControl: ejecución.




La clase System.Web.UI.Control es la clase base de la que derivan todos los con-troles Web, incluidos los controles HTML. Algunas de sus clases derivadas

son System.Web.UI.LiteralControl , System.Web.UI.HtmlControls.HtmlControl y Sys-

tem.Web.UI.WebControls.WebControl que se emplean como clases base genéricas

para los controles que no necesitan ser procesados en el servidor, controles

HTML o controles Web ASP.NET, respectivamente. Así pues, la clase base

empleada para programar un control a medida influirá en las capacidades

iniciales que éste vaya a tener. Por ejemplo, si el control debe disponer de

propiedades de configuración de color, tipo de letra y similares, en lugar de

derivar de la clase Control y definir manualmente dichas propiedades, es más

adecuado emplear como base la clase WebControl, que ya dispone de dichas

propiedades. Para demostrarlo, en el ejemplo de la Figura 83 hemos progra-

mado dos veces el mismo control pero derivando de la clase Control en un

Para añadir un control a lacaja de herramientas, bastaclicar con el botón derechosobre ella, seleccionar laopción de añadir y eliminar elementos, y seleccionar laDLL que contiene los contro-les que vayan a añadirse.

Creación de un proyecto debiblioteca de controles Webcon Visual Studio.

Archivo Ejemplo.aspx<%@ Register TagPrefix="cc1" Namespace="Custom_Control_1"

Assembly="Custom_Control_1" %><html>

<body>

<form method="post" runat="server" ID="Form1"><P> <cc1:webcc1 id="WebCC11" runat="server"Text="Control a medida: Control"></cc1:webcc1></P>

<P> <cc1:webcc2 id="WebCC21" runat="server"Text="Control a medida: WebControl"></cc1:webcc2></P>

</form></body>

</html >

Archivo WebCustomControl1.csusing System;using System.Web.UI;using System.Web.UI.WebControls;

namespace Custom_Control_1

{ public class WebCC1 : Control{

private string text;

public string Text {get { return text; }set { text = value; }

}

protected override void Render(HtmlTextWriter output) {output.Write("<H2>"+Text+"</H2>");

}}

public class WebCC2 : WebControl{private string text;


}

protected override void Render(HtmlTextWriter output) {output.Write("<H2>"+Text+"</H2>");

}}

Figura 83. Ejemplo de control a medida. Derivando de Control y de WebControl.




caso ( WebCC1) y de la clase WebControl en el otro ( WebCC2). La Figura 84 mues-

tra el panel de propiedades de cada control en el diseñador de formularios de

Visual Studio, evidenciando la diferencia en el número de propiedades.

Si para crear un control a medida nos limitamos, tal como hemos visto, a

derivarlo de la clase WebControl y a redefinir el método Render(), desaprovecha-

remos gran parte de la funcionalidad de la clase base. En el ejemplo anterior,

propiedades como BorderColor o Font están disponibles, pero su modificaciónno altera el resultado visual del control. Esto se debe a que la redefinición del

método Render() sustituye el mecanismo interno de la clase WebControl para

preparar la lista de atributos y contenido del control. En su lugar, lo adecua-

do es redefinir los métodos AddAttributesToRender() y RenderContents() , agregando

los atributos y contenido específicos e invocando después a la clase base para

que complete el trabajo. Por defecto la clase WebControl asume que su conte-

nido se incluirá en una marca span de HTML, en cuya etiqueta de apertura

introducirá la lista de atributos, a continuación el contenido y, finalmente,

la etiqueta de cierre. Si deseamos que el control a medida genere otra marca

distinta a span, deberemos invocar desde el constructor al de la clase WebCon-

trol, facilitando como parámetro uno de los elementos de la enumeración

HtmlTextWriterTag. El ejemplo de la Figura 85 ilustra todos estos mecanismos

reimplementando los controles de la Figura 83. El control resultante, al tener

acceso a todas sus propiedades, es mucho más configurable incluso desde el

diseñador de formularios.

Figura 84. Propiedades de un control derivado de Control (izq.) y de WebControl (der.).





Generalmente, al desarrollar un control Web estamos construyendo un

componente que va a ser usado por nosotros u otros desarrolladores, en el

interior de una herramienta como Visual Studio. En consecuencia es impor-

tante que los controles, al margen de su funcionalidad, se comporten de

manera adecuada durante la fase de diseño de la interfaz de usuario, lo que

implica tener en cuenta algunas consideraciones: cada control se identifica

mediante un icono a medida en la caja de herramientas; al insertarlo en una

página, el panel de propiedades muestra todas las propiedades del control ylas clasifica por categorías; algunas propiedades disponen de editores a me-

dida, más elaborados que la sencilla edición textual que ofrece el propio

panel de propiedades; etc. Todos estos detalles, que hacen cómodo el uso de

los controles en la fase de diseño, pueden establecerse mediante un conjunto

de atributos. Por ejemplo, para agregar una categoría y descripción a la pro-

piedad Text de los controles de ejemplo de este apartado, bastaría con agregar

los atributos siguientes delante de la definición de la propiedad:

Finalmente, indicar que al margen de los más de diez atributos predefinidos

disponibles, es posible definir atributos nuevos propios que, por ejemplo,

Archivo WebCustomControl2.csusing System;using System.Web.UI;using System.Web.UI.WebControls;

namespace Custom_Control_1{public class WebCC3 : WebControl{

private string text;

// El constructor llama al constructor base indicando el tipo de marca HTML a insertar public WebCC3() : base(HtmlTextWriterTag.Div) {

text = "Master .NET UOC";}


}

// Método para añadir los atributos propios, como la fuente para el textoprotected override void AddAttributesToRender(HtmlTextWriter writer) {

writer.AddStyleAttribute(HtmlTextWriterStyle.FontFamily, "Arial");// Y dejamos que la clase base añada el restobase.AddAttributesToRender(writer);

}

// Método para añadir el contenido propio: el textoprotected override void RenderContents(HtmlTextWriter writer) {

writer.Write(Text);// Y dejamos que la clase base añada el restobase.RenderContents(writer);

}}

}

Figura 85. Controles a medida: redefinición de AddAttributesToRender() y RenderContents().

[Category(―Apariencia‖), Description(―Texto a mostrar en el control‖)]




apliquen a toda una familia de controles. Este tema, sin embargo, cae fuera

del alcance de este texto.

7.2. Páginas maestras

Al construir un sitio Web de cierta entidad es habitual el requerimiento de

que todas las páginas muestren una apariencia y un conjunto de elementos

visuales comunes. Por ejemplo, un logotipo, un menú principal desde donde

enlazar con las diferentes secciones del sitio, un pie de página con informa-

ción de copyright , etc. Si bien los controles de usuario permiten solventar

algunas de estas situaciones, a menudo acaba siendo inevitable replicar el

código común usado como punto de partida para cada página y añadir el

código específico a continuación. Esto, además de poco productivo, perjudi-

ca a la estructura de la aplicación y complica el mantenimiento y actualiza-

ción posteriores.

Las páginas maestras permiten reducir tanto el tiempo de diseño como el

posterior mantenimiento del sitio. Una página maestra es un archivo inde-

pendiente que aloja los citados elementos comunes y que dispone de áreas

reservadas para el contenido específico, i.e. el que difiere de una página a

otra. Así, el proceso de construcción de una aplicación Web con ASP.NET 2.0

consiste en dos partes bien diferenciadas. Primero se diseña la página maes-

tra que incluye todas las partes comunes que aplicarán a un conjunto de

páginas del sitio, y se establecen también las áreas de la página en las que se

incluirán los contenidos específicos. A continuación se añaden las páginas decontenido. Con este mecanismo, las actualizaciones de la página maestra

Una página maestra define laestructura y el aspecto perifé-rico comunes a un grupo depáginas Web.

Figura 86. Mecanismo de páginas maestras.




afectan automáticamente al resto de páginas, lo que simplifica considera-

blemente el mantenimiento.

7.2.1. Estructura y controles

Una página maestra es como cualquier otra página de ASP.NET, i.e. contiene

una combinación de código HTML y controles de servidor. Sin embargo se

almacena en un archivo con extensión .master , en lugar de la habitual exten-

sión .aspx, lo que designa el archivo como página maestra y no como página

ASP.NET accesible directamente. Adicionalmente, la cabecera de una página

maestra utiliza la directiva <%@ master %> en lugar de la directiva <%@ page %>.

Los atributos con que puede contar la directiva master son, básicamente, losmismos que tiene cualquier otra página, indicando el lenguaje de programa-

ción base (Language), el archivo donde se encuentra el código (CodeFile), el

nombre de la clase que generará la página (ClassName), etc. Esta clase será la

misma que la del archivo indicado por CodeFile, gracias a la capacidad de los

lenguajes de .NET 2.0 para definir clases parciales, con la defini-

ción/implementación dividida en varios archivos.

Una página maestra puede contener HTML estático, componentes de servi-

dor y, en general, cualquier otro contenido que pueda existir en una página

ASP.NET. La estructura es la de una página completa, incluyendo la declara-

ción de tipo de documento y marcas como <html>, <head> y <body>. Lo que

distingue a la página maestra de las otras, aparte de la extensión y la directi-

va, es la aparición como parte del contenido de uno o más componentes de

tipo ContentPlaceHolder , en los que posteriormente se añadirá el contenido

específico de cada página.

Para añadir una página maestra a un proyecto se emplea el mismo mecanis-

mo que para cualquier otro elemento en un proyecto. En ASP.NET 2.0 el

conjunto de posibilidades es muy amplio, tal como muestra la Figura 87. Tras elegir el tipo de elemento a agregar al proyecto, se muestra un diseñador

idéntico al de las páginas .aspx convencionales. En consecuencia, sobre el

espacio de diseño pueden arrastrarse controles, editar el código HTML, etc.

Igualmente puede escribirse código en un fichero asociado para atender a los

eventos disponibles, definir métodos propios de la página, etc. La Figura 88

muestra el aspecto del diseñador de páginas maestras en Visual Studio. La

página maestra contiene una cabecera y un pie de página con información

de copyright , así como un menú lateral con enlaces a diversas páginas. La

zona central en color gris corresponde al ContentPlaceHolder donde, en cada

caso, deberá proveerse el contenido específico adecuado.

En ASP.NET 2.0, el atributo

CodeFile substituye a Code-Behind.

<%@ master Language=‖C#‖ CodeFile=‖UOC.master.cs‖ ClassName=‖UOC_master‖ %>




ContentPlaceHolder es un control de servidor ASP.NET, derivado de Sys-

tem.Web.UI.Control, que básicamente sirve para reservar un área en la página

maestra. Es decir, que aparecerán como controles en el archivo .master . Pues-

to que ContentPlaceHolder también es un contenedor, puede alojar en su inter-

ior a otros controles. Si se introduce un contenido en un control de este tipo,

dicho contenido será el que se utilice por defecto, cuando una página

ASP.NET no aporte un contenido específico. La propiedad más interesante de

este control es ID, a la que asignaremos un nombre que posteriormente ser-

virá para enlazar el ContentPlaceHolder con el control Content de la página .aspx

que insertará el contenido.

Figura 87. Plantillas disponibles: páginas maestras.

Figura 88. Ejemplo de página maestra: aspecto visual.




Al igual que ContentPlaceHolder , el control Content es también un contenedor y

está derivado de System.Web.UI.Control. La diferencia es que Content se utiliza en

las páginas .aspx para alojar el contenido específico, vinculándose con un

determinado ContentPlaceHolder mediante la propiedad ContentPlaceHolderID del

primero. La Figura 89 muestra el código resultante para el diseño de la pági-

na maestra de la Figura 88.

7.2.2. Uso de páginas maestras

Los archivos .master no pueden visualizarse directamente por un navegador

como si fuesen páginas ASP.NET convencionales, sino que están diseñados

para que se haga referencia a ellos desde las páginas que aportarán los conte-

nidos específicos. Para ello se dispone de la propiedad MasterPageFile, en la que

se indica el nombre del archivo de página maestra, que aparecerá como atri-

buto en la directiva Page de aquellas páginas que deseen usarla. Por ejemplo:

<%@ Master Language="C#" ClassName="Maestra_master" %><html xmlns="http://www.w3.org/1999/xhtml"><head>

<title>Master .NET UOC</title></head><body>

<form id="form1" runat="server"><div style="text-align: center; border-right: black thin solid; border-top: black thin solid;

border-left: black thin solid; color: white; border-bottom: black thin solid;

background-color: cornflowerblue;"><h1> Master .NET </h1></div><div style="float: left; border-right: solid 1px black; padding-right: 1em;

margin-right: 1em; height: 13.25em"><ul>

<li> <asp:LinkButton ID="LinkButton1" PostBackUrl="Materiales.aspx" runat="server">Materiales

</asp:LinkButton> </li><li> <asp:LinkButton ID="LinkButton2" PostBackUrl="Actividades.aspx" runat="server">

Actividades</asp:LinkButton> </li>

<li> <asp:LinkButton ID="LinkButton3" PostBackUrl="PizzaPricer.aspx" runat="server">Práctica

</asp:LinkButton> </li>

</ul></div><div style="float: left; background-color: Silver">

<div><asp:ContentPlaceHolder ID="AreaContenido" runat="server">Contenido por defecto

</asp:ContentPlaceHolder></div>

</div><div style="text-align: center; clear: both">

(c) Universitat Oberta de Catalunya (UOC), 2006</div>


Figura 89. Ejemplo de página maestra: código.




Incluir el atributo MasterPageFile en la directiva Page implica la inserción en la

página ASP.NET de los elementos comunes presentes en la página maestra,

así como la vinculación entre los contenedores ContentPlaceHolder de esta últi-

ma y los contenedores Content de la primera. El resultado que ASP.NET de-

volverá al cliente será la combinación de contenidos (ver Figura 86), en for-

ma de una única página cuya URL correspondería a la del archivo .aspx, es

decir, la página ASP.NET que hace referencia a la página maestra. Es impor-

tante tener esto en cuenta, ya que el contexto de ejecución del código en el

servidor lo establece la página que aporta el contenido específico, no la pági-na maestra. Por tanto, los elementos de ésta deben tener en cuenta que las

rutas y otras variables de contexto serán las de la página en que esté utilizán-

dose en ese momento, no la relativa al lugar donde se encuentre la propia

página maestra. La Figura 90 muestra el formulario principal de la aplicación

PizzaPricer incrustado como contenido específico de la página PizzaPrice-

rUOC.aspx que emplea la página maestra de la Figura 89.

7.2.3. Páginas maestras globales y anidadas

Como hemos visto, para aplicar una página maestra prácticamente basta con

utilizar el atributo MasterPageFile en la directiva Page de la página de contenido.Aunque esto parece simple, cuando el número de páginas es elevado el pro-

ceso resulta tedioso y el sitio resultante resulta difícil de mantener. Por ello

<%@ Page Language="C#" MasterPageFile="~/UOC.master" Title="Materiales" %><asp:Content ID="Content1" ContentPlaceHolderID="AreaContenido" Runat="Server">

Indice de materiales del Master …

</asp:Content>

Figura 90. Ejemplo de página de contenido a la que aplica la página maestra.




existe un método alternativo según el cual es posible aplicar una página ma-

estra a todas las páginas de contenido de un directorio, o incluso de toda la

aplicación. Para ello basta con modificar el archivo de configuración

Web.config añadiendo el atributo MasterPageFile a la sección pages:

De este modo todas las páginas .aspx afectadas por el archivo Web.config adop-

tarán automáticamente la estructura y contenidos definidos en la página

maestra indicada. Puesto que cada directorio de la aplicación puede disponer

de su propio archivo Web.config, las páginas contenidas en los diversos direc-

torios pueden definirse en base a páginas maestras diferentes.

Adicionalmente, las páginas maestras pueden anidarse. Esto es, una página

maestra puede utilizar como base para su definición otra página maestra ya

definida. Para ello basta con establecer el atributo MasterPageFile indicando lapágina maestra que se quiere usar como base.

Las páginas maestras anidadas suelen usarse para definir la estructura general

del sitio en una página maestra principal, y usar las páginas maestras de se-

gundo nivel para particularizar únicamente ciertos tipos de páginas de con-

tenido, pero sin alterar la estructura general.

Cabe destacar que en el momento de escribir este texto, Visual Studio no

proporciona soporte visual para la creación de páginas maestras anidadas,

por lo que esto debe hacerse manualmente desde la vista de código HTML.

7.3. Temas visuales

Estamos acostumbrados o que los componentes de interfaz de usuario siem-

pre se comporten de la misma forma, i.e. al hacer clic sobre un botón se

espera que suceda determinada acción, o en una lista de selección se espera

poder escoger una o más opciones. Igualmente estamos acostumbrados a que

el aspecto visual de dichos componentes no sea siempre el mismo, depen-

diendo este hecho de la aplicación, del sistema operativo, de cuestiones dediseño, etc. En consecuencia cualquier sistema de construcción de interfaces

gráficas de usuario debe dar soporte de una u otra forma a la posibilidad de

personalizar el aspecto de los componentes de una interfaz.

En ASP.NET siempre ha sido posible configurar las propiedades de apariencia

de un control, como el BackColor , BorderWidth, Font, etc. Sin embargo, configu-

rarlo manualmente para todos los controles de un sitio no es una opción. Ya

desde ASP.NET 1.x se podían usar hojas de estilo CSS para establecer los atri-

butos visuales de los elementos HTML tradicionales, e incluso Visual Studio

2005 ofrece un completo editor de CSS (ver Figura 91).

<pages MasterPageFile=‖UOC.master‖ >




Por su parte, ASP.NET 2.0 hace posible el empleo de máscaras o skins , i.e.

aplicación de temas visuales, a los controles de servidor. Los temas visuales

son un complemento de CSS, llegando allí donde éstas no pueden. Así, un

tema visual hace su trabajo en el servidor, estableciendo propiedades que

afectan a la apariencia de los controles ASP.NET, mientras que CSS lo efectúa

en el cliente, facilitando al navegador del usuario una referencia de los estilos

que debe emplear al procesar una página Web.

Finalmente, no hay que confundir los temas visuales con las páginas maes-tras. Con éstas se configura el aspecto global y la distribución de los conteni-

dos en las páginas de un sitio, mientras que con los temas visuales lo que se

establece es el aspecto de los controles.

Figura 92. Menú contextual de Visual Studio 2005 para añadir temas visuales.

Figura 91. Editor de CSS en Visual Studio 2005.




7.3.1. Estructura

Un tema visual de ASP.NET 2.0 lo componen uno o más archivos de máscara

con la extensión .skin junto con los recursos necesarios, i.e. archivos de imá-

genes y hojas de estilo CSS (con extensión .css). Todos ellos se almacenan en

un directorio con el nombre del tema visual en cuestión. A su vez, los direc-

torios de temas se almacenan en un directorio llamado App_Themes que se

aloja en el directorio raíz de la aplicación. Al añadir el primer tema visual al

proyecto, para lo cual Visual Studio dispone de un menú especial (ver Figura

92), no sólo se crea el directorio correspondiente al tema sino también el

directorio App_Themes, si es que no existía ya.

En el archivo con extensión .skin se indican los controles a los que afectará el

tema visual al aplicarse, así como los valores que el tema visual asignará a

determinadas propiedades de esos controles. En la configuración del temavisual no puede especificarse propiedades de comportamiento, sino única-

mente propiedades que afecten a la apariencia del control, como colores,

tipos de letra, etc. La sintaxis un archivo .skin es a misma que se utiliza en

una página ASP.NET para usar y definir controles de servidor, con la salvedad

de que no puede emplearse el atributo ID. Por ejemplo, la siguiente plantilla

causaría que todos los controles de tipo TextBox tuviesen, por defecto, fondo

de color rojo, bordes azules y texto blanco en cursiva:

El directorio de cada tema puede contener más de un archivo .skin, de manera

que es posible organizar las diferentes configuraciones según diferentes crite-

rios: tipos de controles, estilos, etc.

7.3.2. Creación de temas visuales

Tal como hemos visto en la Figura 92, el primer paso para crear un tema

visual consiste en crear el directorio en el que se almacenarán los archivosdel tema. Seguidamente, mediante el menú contextual del directorio recién

creado, agregaremos una hoja CSS y un archivo .skin. El archivo .css, que es-

tará vacío por defecto, puede editarse manualmente usando la sintaxis

estándar de CSS. Por su parte, el archivo .skin, que por defecto contendrá un

comentario que indica los dos tipos de plantillas visuales que pueden crearse,

puede editarse manualmente con la sintaxis ASP.NET que ya comentada.

La Figura 93 muestra los archivos .css y .skin de un tema visual sencillo. El

archivo .css indica que todos los textos se mostrarán en color amarillo, a no

ser que se vean afectados por una definición en un archivo .skin. Por su parte,

el archivo .skin, que incluye los comentarios por defecto, define la apariencia

de los controles Label y RadioButtonList .

<asp:TextBox runat="server" BackColor="Red" BorderColor="Blue" Font-Italic="True"

ForeColor="White"></asp:TextBox>




Si bien Visual Studio no proporciona ayuda para la creación de archivo .skin,

existe una forma sencilla de crearlos sin necesidad de escribir manualmente

todo el código. Basta con crear una página ASPX vacía y que no será accesi-

ble desde la aplicación, y arrastrar y configurar en su diseño una instancia de

los controles para los que necesitemos definir un aspecto visual. Posterior-

mente podemos copiar en el archivo .skin el código resultante para los diver-

sos controles, y eliminar el atributo ID de todos ellos.

El archivo .skin puede contener tantas entradas como controles vayan a verse

afectados por el tema visual. Además, un mismo archivo .skin puede contener

varias plantillas para un mismo control, siempre que solamente haya una

plantilla por defecto (sin atributo SkinId) y las demás tengan identificadores

distintos para el atributo SkinId. De esta manera lo que se consigue es que a

cada control afectado por un tema visual le aplique una plantilla por defecto,

y puedan definirse otras plantillas que, idealmente sobre el mismo tema

base, definan estilos característicos para situaciones concretas. En el ejemplo

de la Figura 93, todas las plantillas son plantillas por defecto puesto que no

se ha incluido el atributo SkinId.

7.3.3. Aplicación de temas visuales

Utilizar uno de los temas visuales definidos en un proyecto, tanto para pági-

nas individuales como para todo el sitio completo es tarea sencilla. Al hacer

clic sobre el fondo de una página, el panel de propiedades muestra las co-rrespondientes al elemento DOCUMENT. Entre ellas hay dos relacionadas con

la aplicación de temas visuales: Theme y StyleSheetTheme. Aunque puede asig-

Archivo TemaUOC.css* { color:Yellow; }

Archivo TemaUOC.skin<%--Default skin template. The following skins are provided as examples only.

1. Named control skin. The SkinId should be uniquely defined becauseduplicate SkinId's per control type are not allowed in the same theme.

<asp:GridView runat="server" SkinId="gridviewSkin" BackColor="White" ><AlternatingRowStyle BackColor="Blue" />

</asp:GridView>

2. Default skin. The SkinId is not defined. Only one defaultcontrol skin per control type is allowed in the same theme.

<asp:Image runat="server" ImageUrl="~/images/image1.jpg" />--%>

<asp:Label runat="server" BackColor="RoyalBlue" Font-Italic="True" ForeColor="White"></asp:Label>

<asp:RadioButtonList runat="server" BackColor="Red" Font-Bold="True" Font-Names="Arial"ForeColor="White">

</asp:RadioButtonList>

Figura 93. Ejemplo de un tema visual: código CSS y .skin.




narse el nombre del tema a usar a cualquiera de ellas, existe una diferencia

en el modo en que se aplicará. Si se usa Theme, los atributos definidos por el

tema tendrán prioridad sobre los atributos de los controles definidos en la

página, mientras que si se usa StyleSheetTheme la prioridad es la inversa. Estas

propiedades se traducen en la aparición del atributo correspondiente en la

cabecera de la página:

Por lo que también puede añadirse directamente este atributo en el editor de

código, en lugar de recurrir a la ventana de propiedades del diseñador. Al

seleccionar un tema, se aplicarán las plantillas por defecto a los controles que

correspondan, a no ser que los controles en la página hagan referencia a una

plantilla concreta mediante el atributo SkinId.

La Figura 94 muestra el formulario principal de la aplicación PizzaPricer al

que hemos aplicado las páginas maestras del apartado anterior, así como el

tema visual definido en la Figura 93. Puede apreciarse que todos los textos

aparecen en color amarillo, tal como define la hoja de estilo, a excepción de

aquellos controles (los controles de tipo Label) para los que la plantilla del

tema visual indica otro color. Puede apreciarse además que los controles de

tipo Label y RadioButtonList , ofrecen el aspecto visual definido por las plantillas

correspondientes.

Finalmente, indicar que en caso de necesitar aplicar un tema visual a todaslas páginas de un sitio, no es preciso asignar individualmente el atributo

Únicamente los controles conla propiedad EnableTheminga True se ven afectados por los temas visuales.

Figura 94. Tema visual de la Figura 93 aplicado PizzaPricer con páginas maestras .

<%@ Page Theme=‖TemaUOC‖ ...>




Theme de cada una de ellas. Puede usarse la sección <system.web> del archivo

Web.config del proyecto para incluirlo:

7.4. Web Parts

Cada vez es más habitual encontrar sitios Web en los que la interfaz de usua-

rio es dinámica y personalizable. Estos sitios permiten al usuario personalizar

los elementos visuales y su disposición para obtener así una experiencia ex-

clusiva y con los contenidos que le resulten interesantes. Tradicionalmente,

construir este tipo de sitios Web ha requerido un gran esfuerzo por parte del

desarrollador, incluyendo aspectos como la infraestructura de personaliza-

ción en el servidor, código de script para los navegadores, etc.

ASP.NET 2.0 incorpora un mecanismo que simplifica considerablemente el

proceso de personalización. Un conjunto de nuevos controles, a los que se

denomina genéricamente Web Parts, permite la construcción de páginas con

layout modular y dinámico así como contenido personalizable desde la pro-

pia página Web que los contiene. Para conseguirlo, se definen unas áreas en

las que es posible incluir objetos, cada uno de los cuales cuenta con un menú

que permite cerrarlos, minimizarlos y restaurarlos. Además es posible esta-

blecer conexiones entre esos objetos, incluir catálogos de selección y distri-

bución y editores para alterar prácticamente cualquier aspecto de la interfaz.

7.4.1. Estructura de la página

Una página personalizable mediante Web Parts debe incluir una serie de

elementos indispensables, a los que pueden añadirse otros opcionales según

convenga. Es indispensable que la página incluya un componente WebPartMa-

nager , al menos un control WebPartZone, así como los Web Parts propiamente

dichos, que puede ser cualquier control de servidor o de usuario. Como ele-

mentos opcionales se dispone de una amplia lista, siendo los más usuales

CatalogZone, PageCatalogPart, EditorZone y los distintos editores de apariencia( AppearanceEditorPart), comportamiento (BehaviorEditorPart ) y posicionamiento

(LayoutEditorPart).

Lo primero que debe incluirse en una página que va a ser personalizable es el

componente WebPartManager . Su función es la de ocuparse de la comunicación

entre los distintos Web Parts que finalmente haya en la página, así como

gestionar su visualización en función del modo que esté activo en cada mo-

mento. Seguidamente deberán delimitarse las áreas personalizables de la

página, utilizando para ello los controles WebPartZone deseados. Cada uno de

ellos puede contener varios elementos: menús, listas, cuadrículas, calenda-rios y, en general, cualquier control visual, que al ser introducido en el Web-

PartZone se convertirá automáticamente en un Web Part.

Controles Web Part en VisualStudio 2005

<pages theme=‖TemaUOC‖ />




Cada objeto introducido en un WebPartZone, i.e. cada Web Part, se convierte

en un objeto que es posible minimizar, cerrar, editar y conectar. Éstas son las

opciones por defecto del menú que se añadirá al objeto. Adicionalmente, el

usuario podrá llevar cada objeto desde una zona a otra simplemente

arrastrándolo. Los objetos cerrados no podrán volver a abrirse a menos que

la página incluya una zona de catálogo (control CatalogZone) y una lista de los

Web Parts disponibles (control PageCatalogPart).

La Figura 95 muestra la estructura, a nivel de código, de la página personali-

zable mediante Web Parts más simple posible. Simplemente consta de un

WebPartManager , un WebPartZone y de un control Web dentro de éste. El control

Web (en este caso de tipo Calendar ), convertido en Web Part podrá minimi-

zarse dentro de la WebPartZone, moverse a otra WebPartZone, etc.

7.4.2. Ejemplo

Crearemos una página .aspx en la que insertaremos un WebPartManager , segui-

do de dos controles WebPartZone a cuya derecha existirá un área de conteni-

dos. La distribución en la página puede efectuarse con una tabla HTML, por

ejemplo. Podemos editar la propiedad HeaderText de los WebPartZone para dar-

les un título y establecer los nombres de las opciones del menú asociado, con

las propiedades CloseVerb, MinimizeVerb y similares. Debajo de los WebPartZone

insertaremos un botón cuyo fin será habilitar la personalización. La primerade las dos áreas personalizables contendrá un control de tipo Calendar , mien-

tras que la otra contendrá una lista de opciones en forma de RadioButtonList .

Pueden usarse las etiquetas inteligentes asociadas a todos estos controles,

incluidos los WebPartZone, para adecuar el formato. La Figura 96 muestra el

aspecto de la página en Visual Studio.

Con lo hecho hasta el momento obtendremos una página (ver Figura 97) en

la que, al ejecutarse, cada Web Part dispone de un menú con las opciones

para minimizar el objeto o cerrarlo. La figura muestra la página en ejecución,

donde el calendario se han minimizado, y puede restaurarse nuevamente

usando el menú superior.

<html><body>

<form id="form1" runat="server"><asp:WebPartManager ID="WebPartManager1" runat="server"></asp:WebPartManager><asp:WebPartZone ID="WebPartZone1" runat="server">

<ZoneTemplate><asp:Calendar ID="Calendar1" runat="server"></asp:Calendar>

</ZoneTemplate></asp:WebPartZone>


Figura 95. Página personalizable mediante Web Parts: código.




Como se ha visto, si un objeto se minimiza, el menú de Web Part permite

restaurarlo. Sin embargo, si se cierra el objeto, éste desaparece de la página.

Para facilitar la reapertura de los objetos cerrados, y en general su asociación

con una WebPartZone u otra, puede usarse un control CatalogZone y, dentro de

éste, un control PageCatalogPart. La Figura 98 muestra el diseño de la página

con los nuevos componentes en Visual Studio.

Figura 96. Ejemplo de uso de Web Parts: distribución de componentes.

Figura 97. Ejemplo de uso de Web Parts: Web Part minimizado.




Estos nuevos componentes no serán visibles por defecto. En el ejemplo, usa-

remos el botón para activar su visualización, añadiendo el siguiente código al

método de atención al evento Click:

Figura 98. Ejemplo de uso de Web Parts: uso de CatalogZone y PageCatalogPart.

WebPartManager1.DisplayMode = WebPartManager.CatalogDisplayMode;

Figura 99. Ejemplo de uso de Web Parts: catálogo visible.




Lo que conseguiremos es cambiar del modo de visualización del catálogo, de

forma que se active al hacer clic en el botón. En ese momento aparecerá la

zona de configuración, permitiendo marcar los objetos a añadir y su destino.

La Figura 99 muestra el nuevo aspecto de la página.

La Figura 100 ilustra la posibilidad de arrastrar y soltar objetos entre zonas.

En el ejemplo se ha movido el RadioButtonList de la zona inferior a la superior.

Figura 100. Ejemplo de uso de Web Parts: un Web Part ha cambiado de zona.

Figura 101. Ejemplo de uso de Web Parts: Web Part cerrada y añadida al catálogo.




Por otra parte, la Figura 101 muestra cómo al cerrar un Web Part, éste apare-

ce indexado en el elemento catálogo, desde donde es posible volver a inser-

tarlo en cualquiera de las zonas de Web Parts definidas en la página.

Finalmente es interesante destacar que el aspecto final de la página, que es-

tablece la configuración preferida por el usuario, se almacena no solamente

para la sesión actual, sino que en posteriores visitas el usuario seguirá viendo

la página tal como la dejó. Para ello, ASP.NET emplea el directorio App_Data

de la aplicación donde crea una base de datos de SQL Server (puede ser la

versión Express) que almacena en todo momento el estado de las configura-

ciones de todas las páginas del sitio y para todos los usuarios.




I. Controles Web Forms : Referencia

Este apartado presenta una descripción detallada de las clases más importan-

tes de ASP.NET en lo referente a la construcción de interfaces de usuario: la

clase Control, la clase WebControl y la clase Page. Conocer estas clases es impor-

tante dado que la práctica totalidad de las funcionalidades que ofrecen los

diversos controles disponibles viene heredada de alguna de estas clases.

Se incluye además una breve referencia a los controles de servidor disponi-

bles en las diversas librerías del Framework de .NET, de forma que pueda

seleccionarse el control adecuado a cada necesidad. Se distingue entre con-

troles HTML, controles Web y controles de validación. Si bien estos dosúltimos grupos comparten espacio de nombres su funcionalidad es suficien-

temente diferente como para tratarlos por separado.

Esta referencia no pretende ser una guía detallada, pues para ello está dispo-

nible MSDN (Microsoft Developer Network), sino un punto de partida desde

el que poder analizar las opciones disponibles para implementar el interfaz

de usuario de una aplicación.

I.1. Generalidades

Todo control de servidor en ASP.NET deriva directa o indirectamente de la

clase System.Web.UI.Control (ver Figura 102). Esta clase pertenece al espacio de

nombres System.Web.UI, que contiene los elementos comunes a todos los con-

troles de servidor. Los controles de servidor relacionados con la creación de

interfaces de usuario se organizan en dos espacios de nombres: Sys-

tem.Web.UI.HtmlControls y System.Web.UI.WebControls. Mientras que los controles

HTML se corresponden directamente con marcas de HTML, los controles

Web son más sofisticados y abstractos.

Figura 102. Espacios de nombres y jerarquía de controles de ASP.NET.




I.2. La clase System.Web.UI.Control

Esta clase define las propiedades, los eventos y los métodos que son comunes

a todos los controles de servidor de ASP.NET. En consecuencia es la clase

primaria de donde se deriva para la construcción de controles personaliza-

dos. Sin embargo, puesto que Control no ofrece ningún tipo de interfaz de

usuario, no es la mejor candidata para derivar determinados controles, a no

ser que se desee conseguir el máximo grado de personalización.

Una página Web de ASP.NET se implementa a partir de la clase Page, derivada

de Control. También derivan de la clase Control, los controles literales (cadenas

de texto y HTML que no se procesan en el servidor), los controles HTML de

servidor y los controles Web de servidor.

I.1.1 Propiedades comunes

A continuación se muestra una tabla con las propiedades más habituales de

la clase Control junto con su descripción.

Propiedad Descripción Controls Obtiene un objeto ControlCollection que representa los

controles (secundarios) que están contenidos dentrodel control.

EnableViewState Booleano que indica si el control debe mantener suestado de vista y el de sus controles secundarios.

ID Obtiene o establece un string identificador del control.

Page Referencia al objeto Page que contiene al control.

Parent Referencia al control principal que le contiene.

TemplateSourceDirecto-ry

Directorio virtual donde se aloja la página que contieneal control.

UniqueID Obtiene un string identificador único cualificado jerár-quicamente del control.

Visible Booleano que indica si el control es visible o no.

I.1.2 Eventos comunes

A continuación se muestra una tabla con los eventos más habituales de la

clase Control junto con su descripción.

Evento Descripción DataBinding Se produce cuando el control se enlaza a un origen de datos.

Disposed Se produce cuando el control se libera de la memoria.

Init Se produce cuando el control se inicializa.

Load Se produce cuando el control se carga en el objeto Page que lo




contiene.

PreRender Se produce cuando el control se va a procesar en el objeto Page que lo contiene.

Unload Se produce cuando el control se descarga de la memoria.

I.1.3 Métodos comunes

A continuación se muestra una tabla con los métodos más habituales de la

clase Control junto con su descripción. Los métodos heredados de la clase

Object (Equals, GetHashCode, GetType y ToString) se han obviado.

Método Descripción DataBind Enlaza el control y sus controles secundarios con un origen de

datos.

Dispose Habilita el control para que realice limpieza de su contenidoantes de que se libere la memoria.

FindControl Busca un control entre los secundarios a partir de su ID.

HasControls Obtiene un booleano indicando si el control contiene otroscontroles.

RenderControl Envía el contenido del control a un objeto HtmlTextWriter .

I.3. La clase System.Web.UI.WebControls.WebControl

Esta clase define las propiedades, los eventos y los métodos que son comunes

a todos los controles del espacio de nombres System.Web.UI.WebControls. De esta

clase derivan la mayoría de los controles Web de servidor, excepto Literal,

PlaceHolder , Repeater y XML, que poseen funcionalidades bien diferenciadas. Así

pues, la mayoría de las propiedades de apariencia visual y de comportamien-

to de dichos controles se definen en esta clase.

I.1.4 Propiedades comunes

A continuación se muestra una tabla con las propiedades más habituales dela clase WebControl junto con su descripción. Las propiedades heredadas de la

clase Control se han obviado.

Propiedad Descripción AccessKey Establece la “letra subrayada” que permite desplazarse instantá-

neamente al control.

Attributes Obtiene la lista de atributos relacionados con el dibujado delcontrol que no corresponden a propiedades del control.

BackColor Obtiene o establece el color de fondo del control.

BorderColor Obtiene o establece el color del borde del control.

BorderStyle Obtiene o establece el estilo del borde del control.




BorderWidth Obtiene o establece el ancho del borde del control.

Enabled Booleano que indica si el control está habilitado. El valor pordefecto es true.

Font Obtiene las propiedades de la fuente tipográfica usada por elcontrol.

ForeColor Obtiene o establece el color de primer plano (típicamente el deltexto) del control.

Height Obtiene o establece la altura del control.

Style Obtiene una colección de atributos de texto que se procesancomo un atributo de estilo en la marca ASP.NET del control.

TabIndex Obtiene o establece el índice de tabulación del control.

ToolTip Obtiene o establece el texto que se muestra cuando el punterodel ratón se detiene sobre el control.

Width Obtiene o establece la anchura del control.

I.1.5 Eventos comunes

Los eventos comunes a la clase WebControl y a los controles derivados son

exactamente los mismos que los de la clase Control.

I.1.6 Métodos comunes

La mayoría de los métodos de la clase WebControl, incluso los heredados de

Object, son exactamente los mismos que los de la clase control. El resto demétodos ( ApplyStyle, CopyBaseAttributes , MergeStyle, RenderBeginTag y RenderEndTag)

se han obviado puesto que son usados casi en exclusiva por los desarrollado-

res de controles.

I.4. La clase System.Web.UI.Page

La clase Page está asociada a los archivos con extensión .aspx. Estos archivos

se compilan en tiempo de ejecución en forma de objetos Page y se almacenan

en la caché del servidor.

Page es la clase base para la creación de formularios Web mediante la técnica

de code-behind y code-beside .

La case Page sirve también como contenedora de los controles de servidor de

una página Web ASP.NET.

I.1.7 Propiedades

A continuación se muestra una tabla con las propiedades más habituales dela clase Page junto con su descripción. Las propiedades heredadas de la clase

Control se han obviado.




Propiedad Descripción Application Obtiene el objeto Application para la solicitud en curso.

Cache Obtiene el objeto Cache asociado a la aplicación a la cual per-

tenece la página.ClientTarget Obtiene o establece un valor que permite reemplazar la detec-

ción automática de capacidades del navegador y especificarcómo se procesa una página en un navegador concreto.

EnableViewSta-te

Booleano que indica si la página debe mantener su estado devista y el de los controles que contiene.

ErrorPage Obtiene o establece la página de error a la que se redireccionael navegador en caso de error.

ID Obtiene o establece un string identificador de la página.

IsPostBack Obtiene un booleano que indica si la página se está cargando

como respuesta a un valor devuelto por el navegador, o si es laprimera vez que se carga la página.

Request Obtiene el objeto HttpRequest para la página solicitada.

Response Obtiene el objeto HttpResponse para la página solicitada.

Session Obtiene el objeto Session asociado a la solicitud en curso.

User Obtiene información sobre el usuario que hace la solicitud.

Validators Obtiene la colección de controles de validación en la página.

Visible Obtiene o establece un booleano que indica si la página esvisible o no.

I.1.8 Eventos

Los eventos de la clase Page son fundamentalmente los mismos que los de la

clase Control, por lo que no los mostramos aquí. La siguiente tabla muestra el

resto de los eventos, que la clase Page hereda de la clase TemplateControl.

Evento Descripción AbortTransaction Se produce cuando el usuario interrumpe una transacción.

CommitTransac-tion

Se produce cuando se completa una transacción.

Error Se produce cuando se lanza una excepción no controlada.

I.1.9 Métodos

A continuación se muestra una tabla con los métodos más habituales de la

clase Page junto con su descripción. Los métodos heredados de la clase Object

(Equals, GetHashCode, GetType y ToString) y los heredados de la clase Control se han

obviado. Sí que se incluyen sin embargo, algunos de los métodos heredados

de la clase TemplateControl, como LoadControl y ParseControl.




Método Descripción DataBind Enlaza el control y sus controles secundarios con un origen de

datos.

LoadControl Obtiene un objeto UserControl a partir de un archivo de control

de usuario.ParseControl Procesa un string de entrada y genera un objeto Control en la

página o el control de usuario.

Register- ViewState-Handler

Establece que el view state de la página sea persistente.

Validate Indica a cada control de validación incluido en la página quevalide el contenido al que está vinculado.

I.5. Controles HTML de servidor

En una página de ASP.NET los elementos HTML son tratados, por defecto,

como texto interpretable por el navegador por lo que el motor de ASP.NET

los ignora. Para que un elemento HTML sea tratado como un control de

servidor y por tanto sea accesible programáticamente, simplemente debe

añadírsele el atributo runat="server" . Además, como sucede con el resto de

controles, todos los controles HTML de servidor en una página deben estar

incluidos dentro del ámbito de un formulario, i.e. en el ámbito de la marca

<form> con el atributo runat="server" . Desde el punto de vista de la programa-

ción, los controles HTML de servidor se engloban dentro del espacio de

nombres System.Web.UI.HtmlControls. La Figura 103 muestra la jerarquía de clasescorrespondiente a estos controles.

Figura 103. Espacios de nombres y jerarquía de controles HTML de servidor de ASP.NET.




Seguidamente se describen brevemente todos los controles HTML de servidor

disponibles en la caja de herramientas de Visual Studio 2005.

El control Button se basa en la clase HtmlIn-

putButtonen su forma

<Input type=‖button‖>.Proporciona botones clicablespara los formularios. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/html/htmlinputbutton.aspx.

El control ResetButton se basa en la clase

HtmlInputButton en su forma <Input type=‖reset‖>. Proporciona un botón que,

al clicarse, limpia el contenido de los campos del formulario dejándolos

con sus valores por defecto. Ver más en


El control SubmitButton se basa en la claseHtmlInputButton en su forma <Input type=‖submit‖>. Proporciona un botón que

al clicarse causa en el envío del formulario al servidor. Ver más en


El control TextField se basa en la clase

HtmlInputText en su forma <Input type=‖text‖>. Permite que el usuario pueda

introducir un texto en el formulario. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/html/htmlinputtext.aspx.

El control File se basa en la clase HtmlInputFile

en su forma <Input type=‖file‖>. Permite la selección y carga de un archivo

desde el navegador del usuario al servidor. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/html/htmlinputfile.aspx.

El control PasswordField se basa en la clase

HtmlInputText en su forma <Input type=‖password‖>. Permite introducir un tex-

to que se enmascara con caracteres „*‟. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/html/htmlinputtext.aspx.

El control Checkbox se basa en la clase

HtmlInputCheckBox en su forma <Input type=‖checkbox‖>. Muestra una opción

seleccionable (o no) en un formulario. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/html/htmlinputcheckbox.aspx.

El control RadioButton se basa en la clase

HtmlInputRadioButton en su forma <Input type=‖radio‖>. Permite crear un botón

de opción. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/html/htmlinputradiobutton.as

px.




El control Hidden se basa en la clase HtmlIn-

putHidden en su forma <Input type=‖hidden‖>. Permite almacenar de forma

oculta, información en el formulario, que se enviará al servidor en el

próximo postback . Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/html/htmlinputhidden.aspx.

El control TextArea se basa en la clase

HtmlTextArea. Permite escribir texto de múltiples líneas en el formulario.

Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/html/htmltextarea.aspx.

El control Table se basa en la clase HtmlTable.

Permite crear una tabla programáticamente agregando controles HtmlTable-

Row a la colección Rows de la tabla y controles HtmlTableCell a la colección

Cells de la fila. Puede agregarse contenido a una celda programáticamenteagregando controles a la colección Controls de la celda. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/html/htmltable.aspx.

El control Image se basa en la clase HtmlI-

mage. Permite visualizar una imagen en el formulario. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/html/htmlimage.aspx.

El control Select se basa en la clase HtmlSe-

lect. Proporciona una lista desplegable de selección simple. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/html/htmlselect.aspx.

El control HorizontalRule se corresponde con

la marca <HR> de HTML.

El control Div se basa en la clase HtmlGene-

ricControl. Proporciona un panel para colocar otros componentes de la in-

terfaz.

I.6. Controles Web de servidor (Standard)

Como los controles HTML de servidor, los controles Web de servidor requie-

ren del atributo runat="server" y deben situarse en el ámbito de una marca

<form> con el atributo runat="server" . Sin embargo, los controles Web de servi-

dor no tienen porqué tener una correspondencia con elementos HTML sino

que pueden representar objetos más complejos, visual y funcionalmente.

Los controles Web de servidor son controles de servidor ASP.NET con un

modelo de objetos abstracto y un establecimiento inflexible de tipos. No sólo

se incluyen controles de tipo formulario, como botones y cuadros de texto,sino controles de propósito general, como calendarios.




Desde el punto de vista de la programación, los controles Web de servidor se

engloban dentro del espacio de nombres System.Web.UI.WebControls. La Figura

104 muestra la jerarquía de clases correspondiente a estos controles.

Seguidamente se describen brevemente todos los controles Web de servidor


El control Label permite visualizar un texto,

que además puede cambiarse programáticamente durante la ejecución.

Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/label.aspx.

El control TextBox permite que el usuariopueda introducir un texto en el formulario. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/textbox.aspx.

El control Button proporciona botones cli-

cables para los formularios. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/button.aspx.

El control LinkButton proporciona un botón

con el que devolver el formulario al servidor. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/linkbutton.aspx.

Figura 104. Espacios de nombres y jerarquía de controles Web de servidor de ASP.NET.

http://www.w3schools.com/aspnet/control_label.asp



http://www.w3schools.com/aspnet/control_textbox.asp


http://www.w3schools.com/aspnet/control_button.asp








El control ImageButton permite crear boto-

nes clicables a partir de una imagen. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/imagebutton.aspx.

El control HyperLink permite incrustar URLsen un formulario, i.e. enlaces a otras páginas Web. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/hyperlink.aspx.

El control DropDownList proporciona una

lista desplegable de selección simple. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/dropdownlist.aspx.

El control ListBox permite crear listas des-

plegables de selección simple o múltiple. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/listbox.aspx.

El control CheckBox muestra una opción

seleccionable (o no) en un formulario. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/checkbox.aspx.

El control CheckBoxList agrupa un conjunto

de opciones seleccionables. La selección puede ser múltiple. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/checkboxlist.aspx.

El control RadioButton permite crear un

botón de opción. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/radiobutton.aspx.

El control RadioButtonList permite crear gru-

pos de botones de selección, en los que sólo uno puede estar seleccionado

en un momento dado. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/radiobuttonlist.aspx.

El control Image permite visualizar unaimagen en el formulario. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/image.aspx.

El control ImageMap permite crear una

imagen con diferentes zonas clicables. Al clicar en una de dichas zonas, el

control puede generar un postback o redireccionarnos a otra URL. Ver

más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/imagemap.aspx.

El control Table permite mostrar informa-

ción en forma de tablas. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/table.aspx.

http://www.w3schools.com/aspnet/control_imagebutton.asp


http://www.w3schools.com/aspnet/control_hyperlink.asp



http://www.w3schools.com/aspnet/control_dropdownlist.asp


http://www.w3schools.com/aspnet/control_listbox.asp


http://www.w3schools.com/aspnet/control_checkbox.asp


http://www.w3schools.com/aspnet/control_checkboxlist.asp



http://www.w3schools.com/aspnet/control_radiobutton.asp


http://www.w3schools.com/aspnet/control_radiobuttonlist.asp



http://www.w3schools.com/aspnet/control_image.asp


http://www.w3schools.com/aspnet/control_table.asp















El control BulletedList permite crear listas

con el formato habitual de un documento de texto. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/bulletedlist.aspx.

El control HiddenField permite almacenar

datos en formulario que sean persistentes a lo largo de los sucesivos post-

backs al servidor. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/hiddenfield.aspx.

El control Literal muestra contenido estático

al que no se pueden aplicar estilos visuales. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/literal.aspx.

El control Calendar muestra un calendariomensual en el que es posible seleccionar fechas. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/calendar.aspx.

El control AdRotator permite visualizar una

secuencia de imágenes. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/adrotator.aspx.

El control FileUpload permite enviar un fi-

chero al servidor. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/fileupload.aspx.

El control Wizard permite crear asistentes

para llevar al usuario a través de una serie de pasos y recoger información.

Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/wizard.aspx.

El control Xml permite generar documen-

tos XML a partir de una transformación XSL. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/xml.aspx.

El control MultiView es un contenedor de

controles View, contenedores a su vez de otros controles. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/multiview.aspx.

El control Panel proporciona un contene-

dor en el que disponer otros controles. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/panel.aspx.

El control PlaceHolder se usa como contene-

dor de otros controles que se añaden dinámicamente desde el código de

http://www.w3schools.com/aspnet/control_panel.asp


http://www.w3schools.com/aspnet/control_placeholder.asp








la aplicación. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/placeholder.aspx.

El control View permite almacenar otros

controles para generar una vista en tiempo de ejecución. Ver más enhttp://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/multiview.aspx.

El control Substitution ofrece un mecanism

oavanzada para la inserción de contenido dinámico en la página Ver más

en http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/substitution.asp.

I.7. Controles de validación de servidor

Los controles de validación de servidor se engloban dentro del espacio de

nombres System.Web.UI.WebControls por lo que pueden considerarse controlesWeb de servidor. Sin embargo su funcionalidad no está enfocada al diseño

visual de interfaces de usuario sino a la validación de los datos introducidos

a través del resto de controles. En caso de no validación estos controles pue-

den encargarse de visualizar mensajes de error.

Seguidamente se describen brevemente todos los controles de validación de

servidor disponibles en la caja de herramientas de Visual Studio 2005.

El control CompareValidator valida el conte-

nido de un control comparándolo con el valor de otro control, o con el

valor explícito de la propiedad ValueToCompare del control. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/validation/comparevalidator.as

px.

El control CustomValidator permite realizar

validaciones personalizadas mediante la invocación a una función especí-

ficamente diseñada para ello. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/validation/customvalidator.asp

x.

El control RangeValidator permite comprobar

que el usuario introduzca un valor dentro de un intervalo dado. Ver más

en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/validation/rangevalidator.aspx.

El control RegularExpressionValidator permite

verificar que la entrada de datos coincide con el patrón definido por una

expresión regular. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/validation/regularexpressionval

idator.aspx.

http://www.w3schools.com/aspnet/control_comparevalidator.asp



http://www.w3schools.com/aspnet/control_customvalidator.asp


http://www.w3schools.com/aspnet/control_rangevalidator.asp



http://www.w3schools.com/aspnet/control_regularexpvalidator.asp









El control RequiredFieldValidator permite veri-

ficar si se han introducido datos en un campo del formulario. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/validation/requiredfieldvalidato

r.aspx.

El control ValidationSummary recoge en un

área delimitada todos los mensajes de error obtenidos por las distintas va-

lidaciones en una página. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/validation/validationsummary.

aspx.

I.8. Controles de acceso a datos

Seguidamente se describen brevemente todos los controles de acceso a datos


El control GridView muestra información pro-

veniente de una fuente de datos en formato de tabla y, opcionalmente,

admite la selección, ordenación, paginación y edición de los datos. Ver

más en http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/gridview.aspx.

El control DataList muestra los elementos de

datos en una lista de repeticiones y admite opcionalmente la selección y

edición de elementos. El contenido y diseño de los elementos de la lista

de DataList se define utilizando plantillas. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/datalist.aspx.

El control DetailsView permite asociar una

fuente de datos mostrar un registro cada vez. Suele usarse habitualmente

para actualizar o insertar datos en la funete asociada. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/detailsview.aspx.

El control FormView es muy similar a DetailsView

a excepción de que la interfaz de usuario se especifica mediante plantillasy no es tan estática. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/formview.aspx.

El control Repeater muestra elementos de

datos en una lista de repeticiones. Parecido a DataList, el contenido y dise-

ño de los elementos de la lista se define utilizando plantillas. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/repeater.aspx.

El control SqlDataSource corresponde a una

conexión con un proveedor de ADO.NET para una base de datos SQL. Ver

más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/sqldatasource.aspx.

http://www.w3schools.com/aspnet/control_reqfieldvalidator.asp







El control AccessDataSource corresponde a una

conexión con un proveedor de ADO.NET para una base de datos Micro-

soft Access. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/accessdatasource.aspx.

El control ObjectDataSource corresponde a un

enlace con un proveedor estructurado de datos, que no necesariamente es

una base de datos. El control no expone una conexión sino una clase con

la que se realizan las operaciones de acceso. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/objectdatasource.aspx.

El control XmlDataSource corresponde a un

enlace de datos con un archivo XML. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/xmldatasource.aspx.

El control SiteMapDataSource establece una

fuente de datos para el mapa de navegación en un sitio Web. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/sitemapdatasource.aspx.

I.9. Controles de login

Seguidamente se describen brevemente todos los controles de login disponi-

bles en la caja de herramientas de Visual Studio 2005.

El control Login proporciona una interfaz para

que un usuario se autentifique en un sitio Web. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/login/login.aspx.

El control LoginView permite mostrar los datos

del usuario actualmente autenticado en el sitio Web. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/login/loginview.aspx.

El control PasswordRecovery proporciona unainterfaz para recuperar el password de un usuario de un sitio Web. Ver

más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/login/passwordrecovery.aspx.

El control LoginStatus detecta si el usuario que

accede al sitio está autenticado o no y muestra el indicador apropiado de

login/logout en las páginas del sitio. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/login/loginstatus.aspx.

El control LoginName muestra el nombre del

usuario autenticado que está accediendo al sitio Web. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/login/loginname.aspx.




El control CreateUserWizard proporciona una

interfaz para crear usuarios en un sitio Web. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/login/createuserwizard.aspx.

El control ChangePassword proporciona una

interfaz para cambiar el password de un usuario de un sitio Web. Ver más

en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/login/changepassword.aspx.

I.10. Controles de navegación

Seguidamente se describen brevemente todos los controles de navegación


El control SiteMapPath muestra una lista deenlaces que representan la posición de la página que está visionando el

usuario en la estructura jerárquica de un sitio Web. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/navigation/sitemappath.aspx.

El control Menu permite construir menús de

navegación estáticos o dinámicos en un sitio Web. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/navigation/menu.aspx.

El control TreeView permite visualizar estructu-

ras jerárquicas estáticas o dinámicas en forma de árbol. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/navigation/treeview.aspx.

I.11. Controles Web Part

Seguidamente se describen brevemente todos los controles Web Part dispo-

nibles en la caja de herramientas de Visual Studio 2005.

El control WebPartManager es la clase reponsa-

ble de gestionar y coordinar todos los controles en las WebZones. Ver másen

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/webpartmanager.asp

x.

El control ProxyWebPartManager permite especi-

ficar estáticamente los datos de conexión en una página cuando WebPart-

Manager se especifica en una página maestra. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/proxywebpartmanag

er.aspx.

El control WebPartZone se emplea para alojar

los controles de servidor y así dotarles de funcionalidad de Web Part. Ver




más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/webpartzone.aspx.

El control CatalogZone se emplea para alojar

controles del tipoCatalogPart

. Sólo es visible cuando el usuario activa elmodo CatalogDisplayMode en la página que esté visionando. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/catalogzone.aspx.

El control DeclarativeCatalogPart proporciona un

mecanismo para añadir declarativamente controles de servidor a un catá-

logo en una página Web. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/declarativecatalogpa

rt.aspx.

El control PageCatalogPart sirve como catálogopara contener aquellos controles añadidos a la página que el usuario haya

minimizado, de forma que puedan recuperarse más tarde. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/peclarativecatalogpa

rt.aspx.

El control ImportCatalogPart permite a los usua-

rios importar un archivo que describe la configuración de una Web Part o

un control de servidor que el usuario desea añadir a la página. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/importcatalogpart.as

px.

El control EditorZone permite a un usuario

personalizar las Web Parts de las páginas y almacenar sus preferencias. Ver

más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/editorzone.aspx.

El control AppearanceEditorPart permite editar las

propiedades de apariencia de una Web Part asociada. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/appearanceeditorpar t.aspx.

El control BehaviorEditorPart permite editar las

propiedades de comportamiento de una Web Part asociada. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/behavioreditorpart.a

spx.

El control LayoutEditorPart permite editar las

propiedades de layout de una Web Part asociada. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/layouteditorpart.asp

x.




El control PropertyGridEditorPart proporciona una

interfaz genérica para editar las propiedades personalizadas (no de inter-

faz de usuario) de los controles de tipo Web Part. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/propertygrideditorpa

rt.aspx.

El control ConnectionsZone posibilita la interco-

nexión de Web Parts dinámicamente. Ver más en

http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/connectionszone.asp

x.




II. Instalación del servidor Web IIS

Para poder servir aplicaciones ASP.NET o de cualquier otro tipo basadas en

un motor de páginas de servidor, es necesario disponer de un ordenador con

un servidor Web instalado y en ejecución. Si el servidor tiene asociada una IP

pública, las aplicaciones alojadas en él podrán ejecutarse desde cualquier

lugar de Internet. De otro modo sólo podrán ejecutarse desde los navegado-

res de los usuarios de la red interna donde se halle instalado el servidor. En

todo caso, la URL del servidor corresponderá al nombre del servidor Web tal

como se haya registrado en el directorio DNS correspondiente, o bien su

dirección IP, si no se ha registrado en DNS. Finalmente recordemos que todo

ordenador recibe la dirección IP privada 127.0.0.1 y el nombre localhost. Asípues podremos usar esta dirección IP y este nombre cuando estemos pro-

gramando y depurando aplicaciones Web en el mismo ordenador que tiene

el servidor Web instalado.

Al tratarse ASP.NET de una tecnología de Microsoft, el servidor Web por

defecto es IIS (Internet Information Services ), actualmente en la versión 6.0.

IIS se incluye como un componente de los sistemas operativos Windows

2000 Server, Windows XP Profesional y Windows 2003 Server. A continua-

ción veremos algunos de los aspectos relacionados con la instalación y con-

figuración de IIS y el motor de ASP.NET para los sistemas más actuales, i.e. Windows XP y Windows 2003.

II.1. IIS y ASP.NET en Windows XP Profesional

Aunque Windows XP Profesional incorpora IIS, no lo instala por defecto.

Para instalarlo necesitaremos el CD de instalación del sistema y seguiremos

los siguientes pasos:

Abrir el Panel de Control de Windows y seleccionar la opción Agregar o

quitar programas.

Hacer clic sobre el botón de Agregar o quitar componentes de Windows

situado en el lado izquierdo de la ventana (ver Figura 105).

En la ventana Asistente para componentes de Windows seleccionar el

componente Servicios de Internet Information Server (IIS) (ver Figura

106).

Finalmente hacer clic en el botón Siguiente, con lo que se completa la

instalación.

Si instalamos los componentes de la plataforma .NET con posterioridad a la

instalación de IIS, no será necesario realizar ningún paso adicional.




Si el orden de la instalación ha sido el inverso, el filtro ISAPI de ASP.NET no

estará configurado correctamente para IIS. La configuración puede comple-

tarse desde la línea de comandos ejecutando el programa asp_regiis.exe con la

opción –i . Dicho programa se encuentra alojado en el directorio

C:\Windows\Microsoft.NET\Framework\vXXXX, donde XXXX corresponde a la versión

de la plataforma .NET que se esté usando en el sistema.

Puede comprobarse que el motor de ASP.NET está listo para su uso acudien-

do nuevamente al Panel de Control del sistema operativo:

En el Panel de Control seleccionamos Herramientas administrativas y acontinuación Servicios de Internet Information Server (ver Figura 107).

Figura 106. Instalación de IIS en Windows XP Profesional (2).





En el árbol desplegable de la consola de administración abrimos la rama

Sitios Web.

Hacemos clic con el botón secundario del ratón sobre el Sitio Web prede-

terminado y elegimos la opción Propiedades.

En la ventana que nos aparece seleccionamos la pestaña Directorio parti-

cular y hacemos clic en el botón Configuración de la parte inferior.

En la primera pestaña de la ventana que se abre vemos una lista con to-

das las asignaciones de aplicación. Debemos observar la presencia de las

extensiones de archivo .aspx y .asmx .

Tras estos pasos el sistema operativo y el servidor Web IIS quedan configura-

dos para ejecutar aplicaciones ASP.NET en Windows XP Profesional.






II.2. IIS y ASP.NET en Windows 2003 Server

Windows 2003 Server incorpora todo lo necesario para la ejecución de apli-

caciones ASP.NET. Concretamente lleva preinstalados tanto el servidor IIS

6.0 como el .NET Framework. Sin embargo, la instalación por defecto del

sistema no activa ni IIS ni ASP.NET. Con el CD de instalación del sistema amano, seguiremos los siguientes pasos:






En las Herramientas administrativas seleccionamos la opción Administre

su servidor.

Hacemos clic en el enlace Agregar o quitar función. Se lanza el asistente

de configuración donde elegimos la opción Servidor de aplicaciones (IIS,

ASP.NET) y hacemos clic en el botón Siguiente (ver Figura 111).

En la ventana de opciones del servidor marcamos la opción Habilitar

ASP.NET y procedemos con la instalación (ver Figura 112).

Al finalizar la instalación podemos comprobar si ASP.NET está en funciona-

miento:

Figura 112. Instalación de IIS en Windows 2003 Server (2).





En el Panel de Control seleccionamos Herramientas administrativas y a

continuación Administración de Internet Information Server (IIS).

En la pestaña Extensiones de servicio Web comprobamos la lista donde

debe aparecer ASP.NET v2.x.xxxx en estado Permitido (ver Figura 113).

II.3. Alternativas a IIS

Durante el desarrollo de aplicaciones ASP.NET no es obligatorio usar IIS co-

mo servidor Web, aunque sí sea la mejor opción si finalmente la aplicación

ha de alojarse en un servidor para su explotación.

Cassini, un servidor Web desarrollado como ejemplo de programación de

servicios de .NET, es otra opción posible. Está escrito en C# y su código fuen-

te está disponible en Internet. Webmatrix, una herramienta gratuita de desa-

rrollo de aplicaciones ASP.NET, incorpora Cassini. Igualmente, Visual Studio

también puede configurarse para usar Cassini y así desarrollar y depurar apli-

caciones ASP.NET sin tener que instalar IIS.

Por otra parte, la nueva familia de entornos de desarrollo Visual 2005, de la

cual forma parte Visual Web Developer 2005 Express, tienen incorporado su

propio servidor Web de desarrollo. Así, sólo será necesario instalar IIS para

las pruebas finales previas a la explotación de la aplicación.





Actividades

Todas las actividades que se plantean a continuación hacen referencia a la

aplicación PizzaPricer del apartado “Primera aplicación ASP.NET”. Cada acti-

vidad plantea un objetivo básico que pretende dar pie a la experimentación.

1 Añade un control de tipo RequiredFieldValidator asociado al RadioButtonList PizzaSi-

zes . Si la validación no es satisfactoria la aplicación deberá mostrar un aste-

risco de color rojo junto a la etiqueta “Elige el tamaño de la pizza: ”. El obje-

tivo es forzar que la aplicación no pueda solicitar el precio de la pizza sin que

el usuario haya seleccionado el tamaño de la misma.

2 Añade un control de tipo CustomValidator . Programa una función de validación

personalizada de forma que no se produzca la validación si el tamaño de la

pizza es “Grande” y no se ha elegido ningún complemento. Si la validación

no es satisfactoria la aplicación deberá mostrar un asterisco de color rojo

junto a la etiqueta “Elige los complementos: ”.

3

Añade un control de tipo ValidationSummary que permita mostrar mensajes de

error personalizados para los casos de no validación de las dos actividades

anteriores. Los mensajes deberán aparecer en las líneas posteriores al botón

“Calcular precio”.

4 Construye un archivo XML que permita almacenar de forma estructurada

una lista de parejas complemento/precio . Utiliza el mecanismo de Data Bin-

ding para popular el objeto ToppingsList a partir de la información conteni-da en dicho archivo.

5 Utiliza el archivo Global.asax para detectar el inicio de la sesión y mostrar un

mensaje en la página indicando el tipo de navegador del usuario.

6 7 Utiliza el objeto Application para almacenar datos de cuántas pizzas de cada

uno de los tres tamaños han sido solicitadas a lo largo del tiempo. Añade unbotón al formulario principal que permite consultar la estadística.




8 Utiliza el objeto Session para almacenar el color de fondo de todas las páginas

de una sesión. El color se debe asignar de forma aleatoria al inicio de la se-

sión y debe mantenerse a lo largo de toda ella en todas las páginas visitadas.

9 Escribe un control de usuario consistente en un recuadro con una línea de

texto en su interior. El control debe ofrecer propiedades para cambiar el tipo

de línea y el color del recuadro, así como el texto de su interior. Usa el nuevo

control para dotar al formulario de una cabecera y un pie de página.

10 Escribe un control a medida derivado de WebControl con una funcionalidad

similar al de la actividad anterior.

11 Utiliza el archivo Web.config para redireccionar los accesos a URLs inexistentes

(código 404) en los directorios de la aplicación, hacia una página de error

personalizada.

12 Construye un sistema de autenticación de usuarios basada en formularios. La

aplicación debe ofrecer una primera página donde autenticarse o darse dealta si todavía no se es un usuario registrado. Una vez autenticado el usuario,

la aplicación debe mostrar el formulario principal. Puedes almacenar los

nombres de usuario y las contraseñas en un archivo XML, por ejemplo.

Prueba a usar encriptación (System.Security.Cryptography ) para las contraseñas.




Bibliografía

Walther, S. (2003). ASP.NET Unleashed, Second Edition. SAMS.

Esposito, D. (2003). Programming Microsoft ASP.NET. Microsoft Press.

Cameron, R et al. (2003). Building ASP.NET Server Controls. Apress.

Esposito, D. (2002). Building Web Solutions with ASP.NET and ADO.NET.

Microsoft Press.

Muhammad, F et al. (2003). Real World ASP.NET Best Practices. Apress.

Evjen, B et al. (2005). Professional ASP.NET 2.0. Wrox.

Esposito, D. (2005). Programming Microsoft ASP.NET 2.0 Core Reference. Mi-

crosoft Press.

MSDN: Portal sobre ASP.NET -

http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/dnanchor/html/anchoraspdotnet.asp

GotDotNet : Tutorial sobre ASP.NET 1.x -

http://samples.gotdotnet.com/quickstart/aspplus/

W3Schools: Tutorial sobre ASP.NET 1.x -

http://www.w3schools.com/aspnet/default.asp

Portal ASP.NET: Tutorial sobre ASP.NET 2.0 -

http://www.asp.net/QuickStart/aspnet/Default.aspx

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/anchoraspdotnet.asp














teoria_asp_Español

Documents

Transcript of teoria_asp_Español