Teoria ASP

ASP.
NET

Marco Antonio Pea Basurto
Juan Lpez Rubio

.
Universitat Oberta de Catalunya 3 ASP.NET
ndice
ndice .................................................................................................... 3
Introduccin ........................................................................................ 5
Objetivos ............................................................................................... 6
1. Aplicaciones para la Web y ASP.NET ............................................ 7
1.1. Introduccin ...................................................................................... 7
1.2. Fundamentos de la Web .................................................................... 8
1.3. Aplicaciones Web ............................................................................ 10
1.4. ASP y ASP.NET ................................................................................. 12
1.5. Caractersticas de ASP.NET .............................................................. 13
1.6. Arquitectura de ASP.NET: modelos de cdigo y ejecucin .............. 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. Diseo de interfaces ........................................................................ 32
2.4. Eventos ............................................................................................ 36
2.5. Acceso al flujo de HTML .................................................................. 40
3. Primera aplicacin ASP.NET ........................................................ 42
3.1. Introduccin .................................................................................... 42
3.2. Creacin del proyecto ..................................................................... 43
3.3. Diseo de la interfaz ........................................................................ 44
3.4. Comportamiento de la interfaz ....................................................... 46
3.5. Pruebas y depuracin ...................................................................... 47
3.6. Observaciones .................................................................................. 49
4. Procesamiento de formularios ..................................................... 50
4.1. Ciclo de vida de una pgina Web Forms ......................................... 50
4.2. Formularios HTML y Web Forms .................................................... 53
4.3. Validacin 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. Gestin del estado ........................................................................... 73
5.4. Gestin del estado en la prctica ..................................................... 77
5.5. Configuracin de la aplicacin ........................................................ 85
6. Seguridad ....................................................................................... 91
6.1. Autenticacin y autorizacin .......................................................... 91
6.2. Seguridad y el modelo de proveedores ............................................ 98
6.3. Herramienta de configuracin de la seguridad .............................. 101
6.4. Controles de Login ........................................................................ 102
6.5. API de pertenencia a grupo ........................................................... 108
7. Diseo de la interfaz de usuario ................................................ 110
7.1. Controles personalizados .............................................................. 110
7.2. Pginas 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 validacin de servidor ............................................... 146
I.8. Controles de acceso a datos ........................................................... 147
I.9. Controles de login .......................................................................... 148
I.10. Controles de navegacin ............................................................. 149
I.11. Controles Web Part ...................................................................... 149
II. Instalacin 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
Bibliografa ...................................................................................... 160

Introduccin
Aunque ASP.NET toma su nombre de la anterior tecnologa 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 construccin de aplicacio-
nes usando cualquiera de los lenguajes soportados por el .NET Framework,
como Visual Basic .NET, JScript .NET, C#, etc., pero tambin usando lengua-
jes como Perl o Python. Al contrario que otras tecnologas basadas en cdigo
de script, ASP.NET ofrece un rendimiento mejorado, puesto el cdigo de
servidor se precompila en forma de DLLs en el servidor Web.

ASP.NET simplifica la transicin de los programadores acostumbrados al
desarrollo para Windows hacia el desarrollo Web, puesto que permite la
creacin de pginas 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 cdigo HTML que se incrustan en las pginas que el
servidor enva 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 generacin de la interfaz de usuario. Otros aspectos, co-
mo el acceso a bases de datos, tambin estn 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-
sin 2.0, con el enfoque puesto en lo relativo a la generacin de interfaces de
usuario. As pues, inicialmente se introducen los conceptos bsicos y se crea
una aplicacin de ejemplo. A continuacin se dedica buena parte del texto a
la comprensin de los mecanismos fundamentales en los que se asienta la
ejecucin de las aplicaciones. Al tiempo, se proponen actividades comple-
mentarias sobre la aplicacin base que permiten poner en prctica 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 bsicos relativos a la construccin de aplica-
ciones para la Web.
Asimilar el concepto de control de servidor y los aspectos relacionados
como la gestin de eventos.
Comprender el concepto de Round trip.
Ser capaces de implementar mecanismos de validacin de datos.
Comprender los mecanismos de gestin del estado en una aplicacin
ASP.NET.
Ser capaces de implementar controles de usuario y controles personaliza-
dos bsicos.
Ser capaces de configurar adecuadamente lo fundamental en una aplica-
cin ASP.NET.
Ser capaces de implementar mecanismos sencillos de autenticacin y
autorizacin de usuarios.
Aprender a utilizar los espacios de nombres ms importantes de ASP.NET
mediante C#.
Desarrollar una aplicacin sencilla de ejemplo.

1. Aplicaciones para la Web y ASP.NET
El objetivo de este apartado es situar los contenidos del mdulo en un con-
texto ms global, el de la Web y el desarrollo de aplicaciones para la Web.
Por ello, antes de introducir la tecnologa ASP.NET se revisan algunas nocio-
nes fundamentales y se establece el vocabulario a emplear en adelante.

1.1. Introduccin

La World Wide Web (WWW) fue creada originalmente con el objetivo de
facilitar la transferencia de documentos (estticos) y su navegacin mediante
el uso de enlaces entre s. As, el lenguaje HTML permiti la construccin de
hiper-documentos que incluan texto, imgenes y enlaces (hiperenlaces) a
otros documentos. Poco tiempo despus los documentos dejaron de ser est-
ticos para pasar a auto-modificarse mientras el usuario interaccionaba con
ellos. El as llamado HTML dinmico (DHTML) incluye, no slo HTML, sino
tambin porciones de programa que ejecuta el navegador del usuario para
generar el cdigo HTML que finalmente se visualiza. Algunas tecnologas
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 tambin como plataforma para facilitar la
ejecucin de aplicaciones. En ese sentido destacan dos grandes familias: los
CGI y las pginas de servidor.

Mediante CGI (Common Gateway Interface) se puede crear una interfaz que
comunica el servidor de pginas Web con aplicaciones convencionales. As
ante una solicitud al servidor Web, ste puede ejecutar una aplicacin que
genere las pginas Web correspondientes como respuesta. Este tipo de pro-
gramas puede escribirse en cualquier lenguaje de programacin, siendo algu-
no de los ms habituales C o Perl, por lo que los CGI suelen orientarse ms a
programadores que a diseadores de pginas Web.

Las pginas de servidor se denominan as puesto que cuando un usuario las
solicita a travs de su navegador, el servidor no las devuelve directamente,
tal como hara con una pgina HTML convencional. Sin embargo, somete las
pginas a un procesado previo, ejecutando en el propio servidor el cdigo
incrustado en dichas pginas. As pues este tipo de pginas consisten en una
mezcla de HTML con cdigo que debe compilarse o interpretarse en el pro-
pio servidor, para que ste genere la pgina completa antes de devolverla al
usuario. Destacan en este mbito tecnologas como JSP de Java, PHP o ASP
de Microsoft.
JavaScript es un lenguaje de
script orientado a objetos
muy usado en la construccin
de pginas Web para acceder
dinmicamente a los objetos
que forman una pgina.

Pongamos un poco ms de propiedad en todo este mar de acrnimos.

1.2. Fundamentos de la Web

La Web se fundamenta en el uso de tres estndares. Las URL (Uniform Re-
source Locator), que especifican una forma de otorgar una direccin nica
a una pgina Web. El protocolo HTTP (Hyper Text Transfer Protocol), que
especifica la manera en que el navegador y el servidor se envan informacin
mutuamente. Y el lenguaje HTML (Hyper Text Markup Language), que pro-
porciona un mtodo para codificar la informacin de los documentos de
forma que pueda visualizarse en una gran variedad de dispositivos. Aunque
las compaas que producen programas y contenidos para la Web respetan
dichos estndares mayoritariamente, el W3C (World Wide Web Consortium)
es el organismo encargado de mantener actualizados estos y otros estndares
para que la comunicacin el Web sea efectiva. La Figura 1 muestra la relacin
entre todos estos elementos.

URLs
De forma sencilla, una URL es la direccin 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 continuacin.
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. Anatoma de una aplicacin Web.

Servidor Web
PC/Mac/Unix/...
+ Navegador
Cliente
Servidor
Solicitud:
http://www.digimon.com
Respuesta:
<html>.</html>
Red
TCP/IP, HTTP, HTML
Nmero de puerto: Permite indicar a qu puerto concreto del servidor de
destino debe encaminarse la conexin. Por ejemplo, en
http://www.uoc.edu:80 se especifica el puerto 80. Si no se especifica ningn
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 tpico de HTTP, un navegador Web, inicia una solicitud
estableciendo una conexin en el puerto 80 (por defecto) del servidor. Un
proceso que escucha en el puerto 80 del servidor HTTP identifica el tipo de
solicitud y responde en consecuencia, con un mensaje de error o con el con-
tenido del documento solicitado. Una conversacin tpica entre un navega-
dor y un servidor Web en www.example.org tendra un aspecto como el si-
guiente. A la respuesta le seguira el texto HTML de la pgina Web alojada en
el servidor.

HTML
HTML es el lenguaje usado por una pgina Web para dar formato al texto y
las imgenes que la componen. Es un lenguaje de texto puro basado en un
conjunto de cdigos especiales (marcas) que indican al navegador cmo
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 podramos llamar hola.html, con el siguiente contenido:

<b>Hola Mundo UOC!!!!</b>
Solicitud:
GET / HTTP/1.1
Host: www.example.org

Respuesta:
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2004 22:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html
Al abrir este documento con el navegador veramos 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 prra-
fos anteriores, daremos aqu una definicin ms 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
podramos citar Internet Information Services (IIS) o Apache, entre otros.

Con estos elementos, la as llamada, navegacin por la Web sucede de la
siguiente 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 enva 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 aplicacin Web es un programa distribuido a travs de Internet o de una
red de rea local y que los usuarios ejecutan a travs de un navegador. En los
ltimos aos 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 aplicacin requiere de un
programa cliente propio que debe instalarse independientemente en cada
ordenador desde donde quiera ejecutarse la aplicacin. Las actualizaciones
en el servidor a menudo conllevan tambin actualizaciones en todos los
clientes, lo que sin duda es ineficiente y costoso.

Por el contrario, una aplicacin Web genera la interfaz de usuario en forma
de un conjunto de pginas Web estndar. Aunque una pgina Web es tcni-
camente un documento esttico, una secuencia de pginas Web bien dis-
puestas proporcionan una sensacin de interactividad muy prxima a la de
las aplicaciones convencionales. As pues, una aplicacin Web puede ejecu-
tarse desde cualquier ordenador que tenga un navegador instalado. Adems
las actualizaciones slo afectan al lado del servidor, el navegador cliente no
tiene por qu cambiar.

Actualmente es muy comn
dotar a las aplicaciones de
interfaces Web.
Recientemente, hay una tendencia muy fuerte hacia la creacin de interfaces
Web para todo tipo de aplicaciones. Esto incluye aplicaciones ya clsicas
como Webmail, buscadores, diccionarios on-line, etc. Tambin aplicaciones
monousuario han cambiado a la filosofa basada en pginas 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 tambin incrustado. Finalmente,
otro mbito de uso de las aplicaciones Web son las interfaces de configura-
cin de equipos de comunicaciones como switches, routers, puntos de acce-
so Wi-Fi, etc.

Aunque una aplicacin Web puede construirse de diversas maneras, tpica-
mente constan de tres capas:
La capa de interfaz de usuario, encargada del aspecto visual de la aplica-
cin y de la interaccin con el usuario, est compuesta por las pginas
HTML que el usuario solicita a un servidor Web y que visualiza en un na-
vegador Web.
La capa de lgica de negocio est compuesta por los mdulos que imple-
mentan la lgica de la aplicacin y que se ejecutan en un servidor de apli-
caciones. Esta capa suele tener la forma de un programa creado a partir de
alguna tecnologa de generacin de contenido Web dinmico, 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 gestin de bases de datos (servidor de datos), que ma-
neja la aplicacin Web.

En definitiva, las aplicaciones Web han pasado de ser simples extensiones de
un conjunto de pginas Web estticas, a complejas aplicaciones desarrolladas
en base a muchas capas. Esto permite mayor adaptabilidad y robustez, im-
prescindibles para el desarrollo de tcnicas de escalabilidad y balanceo de
carga, en aplicaciones que deban dar servicio a gran nmero de usuarios
simultneamente.

Para concluir, cabe apuntar el hecho de que la programacin de aplicaciones
Web presenta una serie de dificultades que no suelen darse en la programa-
cin de aplicaciones tradicionales.

Implementacin de interfaces de usuario ricas. Una interfaz de usuario con
un layout complejo, gran cantidad de contenido dinmico, etc. puede ser
muy difcil de construir usando HTML. La dificultad se acenta si lo que
queremos es que la interfaz de usuario pueda visualizarse en mltiples plata-
formas.

Separacin 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 genrica-
mente a una aplicacin Web
que permite leer y enviar
correo electrnico desde un
navegador.
Un servidor de aplicaciones es
un servidor Web con capaci-
dad de procesamiento, por lo
que suele ser a la vez servidor
Web y servidor de lgica de
negocio.
Hablamos de layout en una
interfaz de usuario para des-
cribir tanto el proceso como
el resultado mismo de posi-
cionar y dimensionar los
diferentes elementos que
componen la interfaz en el
espacio de ventana o pgina
Web destinado a ello.
mas operativos que tambin pueden ser diferentes. En consecuencia las dos
partes de la aplicacin comparten muy poca informacin, i.e. pueden co-
municarse pero slo intercambian pequeos bloques de datos.

Ejecucin sin estado. Cuando un servidor recibe la solicitud de una pgina,
ste la busca, la procesa y la retorna al navegador cliente. Inmediatamente
despus el servidor descarta toda informacin relacionada con la pgina
recin servida. Si el usuario solicita la misma pgina posteriormente, el servi-
dor repite el proceso desde cero. Dicho de otro modo, el servidor no tiene
memoria de las pginas que procesa. En consecuencia si una aplicacin nece-
sita mantener informacin relacionada con una pgina, es la propia aplica-
cin 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 diversos
navegadores. 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 mltiples servidores, por ejemplo.

1.4. ASP y ASP.NET

Las siglas ASP (Active Server Pages) se refieren a la tecnologa de Microsoft
que permite que un servidor Web, adems de alojar y servir pginas HTML,
ejecute cdigo de script incrustado en dichas pginas. 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 bsicamente un archivo HTML, pero puede contener
tambin cdigo en forma de scripts. Dicho cdigo 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 la
extensin .asp
VBScript (Visual Basic Scrip-
ting Edition) es un subconjun-
to de Visual Basic usado en
ASP, aunque tambin se usa
como 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 pgina ASP.

motor de ASP. Este analiza el archivo y ejecuta el cdigo en su interior, para
finalmente devolver como resultado un archivo HTML. En el ejemplo de la
Figura 2 podemos ver la seccin de cdigo script delimitada por las marcas
<% y %>. Se trata de cdigo VBScript que se ejecuta en el servidor previa-
mente a la devolucin de la pgina HTML. Si salvamos el cdigo del ejemplo
usando cualquier editor de texto (como el bloc de notas de Windows, por
ejemplo) en un archivo con extensin .asp y posteriormente lo abrimos con
un navegador, veremos que el contenido que se visualiza no muestra el
cdigo sino el resultado de su ejecucin. Es ms, si solicitamos al navegador
que nos muestre el cdigo fuente de la pgina, lo que veremos ser el archi-
vo HTML resultante de la ejecucin del cdigo, no el cdigo en s mismo.

La ltima versin de ASP es la 3.0, aunque nunca habr una versin 4.0. Por
el contrario ASP.NET, originalmente conocida como ASP+, es la nueva gene-
racin de ASP, desarrollada completamente desde cero. No se trata de una
nueva versin de ASP, sino de un nuevo paradigma en el desarrollo de apli-
caciones Web basadas en cdigo de servidor sobre la plataforma .NET. No
existe compatibilidad completa con versiones anteriores, por lo que una
aplicacin ASP debe sufrir algunas modificaciones para ejecutarse sobre
ASP.NET. Para que el servidor diferencie las aplicaciones implementadas con
esta nueva tecnologa, los archivos de ASP.NET utilizan una nueva exten-
sin: .aspx. Como motor de proceso de pginas de servidor, ASP.NET es simi-
lar a otras tecnologas como PHP o JSP.

ASP.NET ofrece gran cantidad de caractersticas interesantes para los disea-
dores y desarrolladores de aplicaciones Web, entre las que destacan el sopor-
te a mltiples lenguajes de programacin, la programacin orientada a even-
tos, componentes basados en XML, escalabilidad, alto rendimiento, etc. El
siguiente apartado detalla estos y otros aspectos.

1.5. Caractersticas de ASP.NET

ASP.NET proporciona una plataforma de desarrollo completamente integra-
da con el Framework de .NET, lo que permite la construccin sencilla de
aplicaciones 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
pginas 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 lgica de la
aplicacin est en el servidor, eliminado la necesidad de escribir cdigo es-
pecfico para diversos navegadores. En todo caso, tambin posibilita que las
Los archivos ASP.NET usan la
extensin .aspx
ASP slo admite cdigo escri-
to en VBScritp y JScript.
aplicaciones se beneficien automticamente de las capacidades especficas de
cada navegador, generando cdigo cliente eficiente.

Soporte multi-lenguaje. Al estar integrado con el .NET Framework las pgi-
nas ASP.NET pueden incluir cdigo 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 ms 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 libreras externas para generar
grficos, acceder a bases de datos, trabajar con XML, etc.

Modelo de objetos consistente e intuitivo. El entorno de desarrollo de pgi-
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 abstraccin
respecto al contenido HTML de una pgina Web y respecto a la interaccin
entre el navegador y el servidor. En general pueden usarse los controles de
servidor como si se usasen controles en una aplicacin de escritorio tradicio-
nal, sin pensar en el cdigo HTML necesario para mostrarlos y procesarlos.

Orientacin a eventos. Web Forms aporta a la construccin de aplicaciones
Web el tradicional mtodo de escritura de mtodos 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 pgina son receptivos a eventos
que pueden procesarse mediante cdigo .NET de una forma estructurada.

Gestin del estado de forma intuitiva. ASP.NET gestiona automticamente
el estado de los formularios y los controles, adems de proporcionar meca-
nismos explcitos par gestionar el estado de informacin especfica de la
aplicacin.

Autenticacin y gestin de usuarios. ASP.NET soporta autenticacin basada
en formularios, incluyendo gestin de cookies, redireccin en caso de fallo
de autenticacin, etc. Adems permite la definicin de perfiles de usuario
por aplicacin, para proporcionar acceso a diferentes contenidos o ejecutar
diferente cdigo en funcin del usuario.

Configuracin y despliegue simplificados. Las aplicaciones se configuran
mediante archivos de texto planos que pueden modificarse an con la apli-
cacin en ejecucin y sin necesidad de reiniciar el servidor Web. Las actuali-
zaciones en el cdigo no requieren tampoco del reinicio del servidor pues
basta con cambiar el cdigo y el servidor redirecciona las peticiones hacia el
nuevo cdigo.

Rendimiento mejorado. El cdigo en ASP.NET es compilado por lo que su
ejecucin se beneficia de optimizaciones nativas y sistemas de cache, entre
Una aplicacin ASP.NET tiene
acceso a todos los servicios de
la plataforma .NET
otros, para conseguir un mejor rendimiento. El cdigo slo se compila la
primera vez que es accedido, a diferencia de los entornos interpretados en los
que el cdigo 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 migracin a 64 bits puede ser tan sencilla como copiar
el cdigo de 32-bits al servidor, dejar que el motor de ASP.NET 2.0 lo compi-
le y finalmente lo ejecute como una aplicacin nativa de 64 bits. Sin cam-
bios en el cdigo.

Escalabilidad. ASP.NET proporciona facilidades de comunicacin entre ser-
vidores de forma que una aplicacin compleja o muy solicitada puede distri-
buirse en granjas de servidores con muy pocos cambios en la lgica de la
aplicacin.

Multiplataforma. Un inconveniente que suele achacarse a ASP.NET el hecho
de 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. Adems, al margen de IIS, tambin puede
usarse Apache junto con Cassini como servidores Web para ASP.NET.

1.6. Arquitectura de ASP.NET: modelos de cdigo y ejecucin

Como ya hemos comentado previamente, una pgina 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 cdigo escrito en cualquiera de los
lenguajes de .NET. As pues, la forma ms simple de una pgina de ASP.NET
consistira en tomar cualquier archivo HTML y cambiarle la extensin. La
Figura 3 muestra un ejemplo de pgina 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 cdigo se delimita entre las marcas <% y %>.

Aunque para este ejemplo concreto no es necesario, para que una aplicacin
ASP o ASP.NET puede ejecutarse creando dinmicamente el contenido de la
Cassini es un servidor Web de
ejemplo programado con
.NET y preparado para servir
pginas 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 pgina ASP.NET.

pgina respuesta, es necesario que los diferentes archivos que forman parte
de la aplicacin se hallen en el lugar adecuado del servidor Web (vase el
Apndice Instalacin 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 cdigo incrustado en la pgina 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 pgina ASP.NET puede
combinar el aspecto visual (marcas HTML) y la lgica de una aplicacin (e.g.
cdigo C#). El resultado es en general un archivo poco inteligible y difcil de
mantener. Lo recomendable es, como mnimo, separar ambas cosas median-
te la tcnica denominada code-behind. Esta tcnica consiste bsicamente en
alojar en archivos separados el cdigo HTML y la lgica de la aplicacin. As,
el cdigo HTML se almacena en un archivo con extensin .aspx, mientras que
el cdigo ejecutable se almacena en un archivo con extensin .aspx.cs, .aspx.vb,
etc. dependiendo del lenguaje de programacin especificado (ver Figura 5).
Adems se establece un vnculo entre la pgina .aspx y el cdigo mediante los
atributos Codebehind e Inherits en la marca Page. La Figura 6 muestra cmo que-
dara el cdigo del ejemplo anterior empleando la tcnica de code-behind. La
Figura 7 muestra el aspecto visual de la pgina 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 mdulo de cdigo 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.

Aplicacin 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 pgina 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 pgina ASP.NET con code-behind.: ejecucin.

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

En ASP.NET 2.0 y Visual Studio 2005 este modelo de separacin de cdigo e
interfaz ha evolucionado considerablemente. El nuevo modelo de separacin
de cdigo 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 mltiples archivos de cdigo. De este modo se puede
definir parte de una clase en un archivo, algunas de sus propiedades en otro,
sus mtodos en otro, etc. La principal utilidad de este modelo est enfocada
a herramientas de creacin de cdigo, para facilitar la regeneracin de cdigo
parcial de una clase y para que varios programadores puedan trabajar al
mismo tiempo en partes diferentes de una misma clase.

En las pginas ASP.NET 2.0, Visual Studio 2005 aprovecha esta caracterstica
para definir parte de la clase de la pgina Web en el propio archivo .aspx, que
contiene definiciones de controles y eventos, y el cdigo que gobierna su
funcionamiento en un archivo aparte por medio de una clase parcial. Esto se
controla 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 slo el cdigo que gobierna el funcionamien-
to de la pgina. La Figura 8 muestra el ejemplo Figura 6 pero esta vez imple-
mentado con la tcnica 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 conversin)
son varias, y cabe destacar una mayor sencillez de cdigo y una mayor sepa-
racin real entre interfaz y lgica de trabajo.

Si se usa la herramienta de desarrollo Visual Studio .NET para implementar la
aplicacin, la vinculacin entre las pginas ASP.NET y los mdulos de cdigo
se efecta de forma automtica y transparente para el programador. Adems,
la aplicacin se registra automticamente en el servidor Web por lo que pue-
de ejecutarse directamente. Si para escribir el cdigo no se usa Visual Studio
.NET sino un editor de texto cualquiera, antes de poder ejecutar la aplicacin
(como la de la Figura 6) debe compilarse el cdigo para producir la corres-
pondiente DLL. Adems 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
pgina Web cuyo contenido se genera dinmicamente. La clase Page se utiliza
habitualmente como base para derivar nuevas clases de pgina, 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 pgina .aspx al servidor Web, ASP.NET compila din-
micamente el cdigo incrustado en la pgina generando una clase derivada
de la clase Page. La clase recibe un nombre por defecto que puede alterarse
mediante el atributo ClassName en la lnea <% @Page (ver Figura 3). Cuando se
usa code-behind o code-beside el proceso es un poco ms elaborado puesto
que el atributo Inherits permite tomar como base una clase distinta a Page. En
cualquier caso, la clase slo se genera y compila la primera vez que se accede
a la pgina, mientras que en accesos posteriores la clase de pgina ya genera-
da previamente simplemente se instancia y se usa (ver Figura 9).

Clase
Pgina
generada
Figura 9. Modelo de ejecucin detallado de una aplicacin ASP.NET.

Archivo
.aspx
Solicitud
Motor
ASP.NET
Parseador
Generar
Respuesta
Solicitud
Instanciar
Respuesta
Clase
Pgina
Instanciar,
ejecutar y
renderizar
Compilador
Clase
code-behind
o 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 pgina ASP.NET con code-beside.

Archivo ASP.NET_UOC_cb.aspx.cs

using System;
using System.Web;

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 bsicos 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 genrica en cualquier aplicacin. La arquitec-
tura basada en proveedores proporciona a los bloques bsicos la posibilidad
de usar diversos mecanismos de almacenamiento y recuperacin de informa-
cin, como SQL Server, Active Directory, etc. Por su parte, los frameworks de
pgina emplean los bloques bsicos para ofrecer servicios de alto nivel a las
aplicaciones, lo que facilita la creacin de portales, por ejemplo. Finalmente
se dispone de un conjunto de controles de servidor, mucho ms amplio que
en 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 identificacin segura de usuarios, navegacin, creacin de
mens, visualizaciones en rbol, creacin de portales, etc. Adems, mejora
la extensibilidad de los controles, proporcionando gran cantidad de clases
base que encapsulan comportamientos tpicos. A continuacin repasamos
algunas de las familias de nuevos controles:

Figura 10. Arquitectura de ASP.NET 2.0. Visin de desarrollador.

Controles de acceso a datos. El acceso a datos puede llevarse a cabo de for-
ma totalmente declarativa, i.e. sin escribir cdigo. 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 navegacin. Controles como treeview, menu y sitemappath, se ba-
san en los servicios de ASP.NET 2.0 para almacenar y recuperar flujos de na-
vegacin predefinidos, y as permitir establecer la navegacin entre las pgi-
nas de un sitio Web de forma estructurada y consistente.

Controles de login. Estos controles proporcionan mecanismos para la auten-
ticacin y autorizacin de usuarios en un sitio Web. Para ello se basan en los
servicios de pertenencia y gestin de roles.

Web parts. Estos controles permiten aadir contenido y layout ricos a un
sitio Web, al tiempo que le proporcionan la capacidad de editarlos directa-
mente desde la propia aplicacin.

1.7.2. Frameworks de pgina

Los frameworks de pgina proporcionan servicios de alto nivel a las aplica-
ciones. Entre ellos destacan los siguientes:

Pginas maestras. Permiten definir una estructura y elementos de interfaz de
usuario comunes a todo un sitio Web. As, cabeceras y pies de pgina, barras
de navegacin, etc. pueden definirse en una pgina maestra en la que se
basarn todas las pginas del sitio.

Temas visuales. Permiten personalizar el look-and-feel de las pginas de un
sitio Web. La informacin de estilo se almacena en un lugar comn deno-
minado tema y se aplica globalmente a todas las pginas y controles del
sitio. Como la anterior, esta caracterstica reduce la cantidad de cdigo du-
plicado y, por lo tanto, permite mejorar el mantenimiento de la aplicacin.

Interfaz de usuario adaptativa. Los servicios de personalizacin permiten
crear experiencias de usuario personalizadas de una misma aplicacin me-
diante la gestin de perfiles, de forma muy sencilla y con muy poco cdigo.
Por otra parte, los servicios de localizacin proporcionan herramientas e
infraestructura para construir aplicaciones en mltiples 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 creacin de
aplicaciones sofisticadas. Por ejemplo, soporte a mecanismos de pertenencia
(almacenamiento/recuperacin de credenciales del tipo nombre de usuario y
palabra clave) y de gestin de roles. O servicios de personalizacin que per-
miten almacenar/recuperar configuraciones y preferencias de usuario. O un
sistema de navegacin que permite la construccin de estructuras de nave-
gacin 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 grfica los principales espacios de nombres
que agrupan la funcionalidad necesaria par la creacin de aplicaciones y
servicios Web con ASP.NET. A continuacin se describe en ms detalle cul
es el contenido de cada uno de ellos:

System.Web. Proporciona clases e interfaces que posibilitan la comunicacin
entre navegadores y servidores Web. Es el espacio de nombres de ms alto
nivel de ASP.NET y agrupa a todos los dems.

System.Web.Caching. Proporciona clases para implementar, en el servidor, ca-
ches de recursos frecuentemente usados, ya sean pginas, documentos XML,
sesiones, aplicaciones, etc.

System.Web.Configuration. Proporciona las clases usadas en la configuracin de
ASP.NET.

System.Web.Security. Proporciona clases que permiten la implementacin de
estrategias de seguridad en las aplicaciones Web.

System.Web.Services. Proporciona las clases que permiten la construccin de
servicios Web XML. Esto es aplicaciones que ofrecen la posibilidad de inter-
cambiar mensajes e interoperar mediante protocolos estndar como HTTP,
XML, XSD, SOAP y WSDL.

System.Web.Services.Description. Proporciona las clases que permiten describir
pblicamente 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 comunicacin entre servicios Web y
sus clientes.

System.Web.UI. Proporciona clases, enumeraciones e interfaces que dan sopor-
te a la creacin e interfaces de usuario para Web Forms.

System.Web.UI.HtmlControls. Proporciona las clases que permiten la creacin de
controles HTML de servidor en una pgina Web. Los controles HTML de
servidor se corresponden con elementos estndar de HTML por lo que son
soportados por cualquier navegador. Dichas clases permiten controlar pro-
gramticamente los elementos HTML de una pgina.

System.Web.UI.WebControls. Proporciona las clases que permiten la creacin de
controles Web de servidor en una pgina Web. Los controles Web de servi-
dor incluyen formularios y controles habituales como botones y cuadros de
texto, as como otros controles ms 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 excepcin de lo que ha sucedido en los sencillos ejemplos vistos hasta
ahora, habitualmente utilizaremos algn entorno de desarrollo que facilite la
construccin de la aplicacin. Dichos entornos de desarrollo (como en el
caso de Visual Studio .NET) se encargan, entre otras cosas, de la separacin
entre la lgica de la aplicacin y la interfaz de la misma empleando code-
behind, o de simplificar el diseo de las pginas.
S Sy ys st te em m. .W We eb b
C Co on nf fi ig gu ur ra at ti io on n S Se es ss si io on nS St ta at te e
S Se ec cu ur ri it ty y
Figura 12. Espacios de nombres de ASP.NET.

C Ca ac ch hi in ng g
S Se er rv vi ic ce es s U UI I
H Ht tm ml lC Co on nt tr ro ol ls s
W We eb bC Co on nt tr ro ol ls s
D De es sc cr ri ip pt ti io on n
D Di is sc co ov ve er ry y
P Pr ro ot to oc co ol ls s

Relacionado con el diseo de las pginas, 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 creacin 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 aplicacin Web queda diluido.

Este es uno de los puntos importantes que diferencia ASP.NET de otros sis-
temas para generacin 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 aplicacin cliente (el navega-
dor) pero son tratados por el servidor Web dentro del Framework de
ASP.NET. Ms concretamente, la informacin de los eventos capturados en
el 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 informacin e invocar al mtodo correspondiente que
trata el evento.

Desde el punto de vista del desarrollador, no hay diferencias sustanciales a la
hora de construir una aplicacin de Windows Forms y una aplicacin Web
ASP.NET. La diferencia fundamental estriba en el conjunto de controles dis-
ponibles, siendo los de Windows Forms mucho ms potentes en cuanto a su
complejidad visual y de interaccin con el usuario. En ASP.NET tambin se
dispone de controles habituales en los formularios, como botones, etiquetas,
etc. En este caso sin embargo, existen controles especficos derivados del
hecho de que HTML ya posee un conjunto de controles bsicos y por lo tan-
to algunos de los controles de ASP.NET pueden mapearse directamente sobre
ellos. Adicionalmente, ASP.NET ofrece controles especficos orientados a la
Web, as como controles cuya ejecucin 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 bsicos de ASP.NET
que dan soporte a la construccin de una aplicacin 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 gestin de eventos, estos controles permiten la construc-
cin 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 por
los que un usuario interacta con un sistema, una aplicacin, etc. La interfaz
proporciona mtodos por los que el usuario controla el sistema y mtodos
por los que el usuario recibe informacin del mismo.

Un tipo particular de interfaz lo constituye la interfaz grfica de usuario
(GUI) que se basa en la manipulacin de imgenes grficas y elementos vi-
suales (widgets) como ventanas, botones, cuadros de texto, etc. Junto a estos
elementos, un sistema de gestin 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 de
Windows) o un intrprete especializado (como en el caso de Tcl/Tk) se en-
cargan de gestionar el conjunto.

El aprovechamiento de la Web para que, adems de permitir la visualizacin
de documentos, permita tambin el acceso a aplicaciones remotas mediante
una interfaz HTML, implica algunas peculiaridades que diferencian este tipo
de interfaz de los GUI ms 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 bsicos para mostrar y solicitar informa-
cin a travs de formularios. El procesado de los formularios, sin embargo, se
efecta 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
creacin de pginas Web programables que sirvan como interfaz de usuario
para las aplicaciones Web. Gracias a la tecnologa ASP.NET, el cdigo que se
ejecuta en el servidor (incluida la lgica de la aplicacin) genera dinmica-
MDI (Multiple Document
Interface) se refiere a la inter-
faz grfica de usuario por la
que todas las ventanas de un
programa residen en el inte-
rior de una ventana que hace
las veces de marco. Este tipo
de interfaz es el ms comn
en Windows, por ejemplo.
En una interfaz SDI (Single
Document Interface) las
ventanas de un programa son
independientes entre s y las
gestiona el propio gestor de
ventanas del sistema operati-
vo. Este tipo de interfaz es el
ms comn en Unix, por
ejemplo.
mente el contenido de las pginas Web hacia el navegador. El resultado pro-
ducido por una pgina Web Forms puede contener casi cualquier forma de
los lenguajes transmisibles sobre HTTP, como HTML, XML, WML, JScript y
JavaScript. As, una pgina Web Forms genera automticamente el cdigo
adaptado a las capacidades del navegador cliente. Como resultado de lo an-
terior, una pgina Web Forms puede mostrar informacin al usuario en
prcticamente cualquier navegador o dispositivo cliente.

El diseo 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 interaccin. 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 informacin al usua-
rio. Aunque la construccin de los formularios es muy similar a cmo se
hace en Windows Forms, el conjunto de controles es diferente, existiendo,
por ejemplo, controles basados en HTML especficamente diseados para la
Web. Otro aspecto diferencial es la forma de situar los controles en el formu-
lario, siendo mucho ms arbitraria su colocacin en el caso de los formula-
rios Web, puesto que una pgina puede adoptar diferentes tamaos depen-
diendo del navegador con el que se visualice, el tamao de la ventana de
ste, o incluso la resolucin de la pantalla en que se ejecute el navegador. Por
ello, la colocacin de los componentes visuales en una pgina no sigue un
posicionamiento absoluto como en Windows Forms.

2.2. Controles de servidor

El cdigo de la Figura 13 muestra un pequeo ejemplo de pgina ASP. Como
puede verse, el bloque de cdigo se sita justo en el lugar de la pgina en la
que debe aparecer el resultado producido por dicho cdigo. En ASP es impo-
sible separar el cdigo ejecutable del cdigo HTML que da forma a la pgina.
El resultado es un cdigo difcil de leer y de mantener.

ASP.NET resuelve de forma ordenada el problema de programar el compor-
tamiento dinmico de las pginas 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 puede
dejarse que los elementos
visuales fluyan en la pgina,
distribuyndose segn las
dimensiones del navegador, o
bien puede usarse posiciona-
miento absoluto mediante
CSS (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 pgina ASP.

ampliables programticamente. ASP.NET aporta ms de 40 controles de ser-
vidor aunque existe gran cantidad de ellos proporcionados por terceros.

Existen tres clases de controles de servidor:
Controles HTML: bsicamente son marcas HTML
Controles Web: controles propios de ASP.NET
Controles de validacin: controles propios de ASP.NET para la validacin
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 pgina 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 pgina al navegador del cliente.
Puesto que los elementos HTML en una pgina ASP.NET se tratan como sim-
ple texto y no se procesan, para hacerlos programables debe aadrseles el
atributo runat=server . Adems se suele aadir un atributo id que permite
identificar el control y as poder manipularlo desde el cdigo en tiempo de
ejecucin.

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 podrn accederse y
manipularse por el cdigo de script que se ejecute en el servidor.

El cdigo de la Figura 14 muestra una pgina de ASP.NET que usa un control
HtmlAnchor de servidor para incrustar un hipervnculo en una pgina Web.
Como se ve, el atributo HRef del control se manipula en tiempo de ejecucin
mediante el cdigo de atencin al evento Page_Load que se produce cuando se
carga la pgina .aspx. Se observa tambin que ahora todo el cdigo ejecutable
se ha separado del cdigo HTML.

Los controles HTML son ms
adecuados para los elementos
estticos de la pgina.
<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 explci-
tamente a controles HTML de servidor se les asigna el tipo de control genri-
co System.Web.UI.HtmlControls.HtmlGenericControl.

2.2.2. Controles Web

Adicionalmente al soporte de controles estndar HTML, ASP.NET permite el
uso de controles semnticamente mucho ms ricos. Al igual que los contro-
les HTML de servidor, los controles Web de servidor tambin 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 cdigo HTML, y por lo tanto pue-
de encapsular funcionalidades ms 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, mtodos 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
ejecucin. Veremos ms sobre eventos en el apartado Eventos.

La sintaxis para declarar un control Web de servidor en una pgina es la
siguiente: <asp:nombre_control id="algun_id" runat="server" /> , donde se aprecia la
marca asp al inicio de la declaracin.

El ejemplo de la Figura 15 muestra la declaracin de un botn en un archivo
.aspx . Al margen del identificador y el texto del botn, se declara tambin
una funcin de atencin al evento OnClick del botn. La funcin cambia el
texto del botn al presionarlo en tiempo de ejecucin.

2.2.3. Controles de validacin

El modelo de formularios de ASP.NET proporciona un conjunto de controles
de validacin de servidor que pueden emplearse para la validacin de los
datos que introduce el usuario a travs de otros controles del formulario. El
El motor de ASP.NET se en-
carga de traducir los controles
Web en marcas de HTML y
cdigo ejecutable.
<html>
void submit(Source As Object, e As EventArgs) {
boton1.Text="Ya has hecho clic!";
}
</script>
<body>
<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 validacin se visualiza un
mensaje de error.

Cada control de validacin puede llevar a cabo un tipo especfico de com-
probacin: 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 patrn, 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 validacin de una pgina se invocan cuando se
hace clic sobre un control de tipo Button, ImageButton o LinkButton. Puede in-
habilitarse la validacin de un control asignando a false la propiedad CausesVa-
lidation. La sintaxis para declarar un control de validacin de servidor es idn-
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 validacin 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 condicin no se
cumple, el control de validacin mostrar el mensaje indicado en el atributo
Text. La Figura 17 muestra la pgina Web en ejecucin, donde puede verse la
validacin en accin.

<html>
<body>
Introduce un nmero entre 1 y 100:
<asp:TextBox id="tbox1" runat="server" />
<br />
<asp:Button Text="Enva" 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 validacin de servidor en ASP.NET.

Figura 17. Ejemplo de uso de controles de validacin de servidor en ASP.NET: ejecucin.

Es interesante destacar que los controles de validacin 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-
dacin se lleve a cabo eficientemente en el propio navegador mediante el
uso de DHTML y cdigo JavaScript, pero tambin en el servidor. Si el nave-
gador es muy sencillo, como el de muchos telfonos mviles, la validacin
slo ser posible en el servidor. Lo ms interesante es que el modelo de pro-
gramacin es idntico 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-
cin a la propiedad Page.IsValid para determinar si todos los controles de
validacin se han evaluado positivamente. Esto proporciona un mecanismo
sencillo para validar un formulario y decidir si debe procederse con la ejecu-
cin de un determinado cdigo 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 cuestin al motor de ASP.NET para que lo procese. El motor,
que no depende del servidor Web sino de la plataforma de ejecucin de apli-
caciones que haya por debajo, debe extraer todas las marcas con el prefijo
asp y substituirlas por los elementos HTML y el cdigo script de cliente ade-
cuados. La substitucin 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 trminos de elementos y atributos HTML,
estilos CSS y cdigo JavaScript.

Para ver cmo trabaja el motor de ASP.NET en lo que respecta a la traduccin
de los diversos controles durante el procesamiento de una pgina, podemos
recurrir a una sencilla prueba. Usando un editor de texto cualquiera creare-
mos una nueva pgina de ASP.NET y aadiremos 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 mediante
lenguajes de marcas. Tpica-
mente se usa para definir el
estilo de una pgina Web
escrita en HTML o XHTML.
<html>
<body>
<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 cdigo resultante, mientras que la Figura 19 muestra el
aspecto de la pgina Web en ejecucin.

La Figura 20 muestra el cdigo que recibe el navegador en respuesta a la soli-
citud de la pgina anterior. Como puede observarse el cdigo es muy dife-
rente. En la parte inferior del cdigo 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 botn
de seleccin, y un elemento label asociado que muestra el ttulo. Al hacer clic
sobre el control se invoca a la funcin JavaScript que ha generado el motor
de ASP.NET y que se muestra en el cdigo. En ella se comprueba qu nave-
gador visualiza la pgina y se recupera la referencia al formulario a travs 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" /><label
for="cbox1">"Seleccioname"</label></span>

</form>
</body>
</html>
Figura 20. Procesamiento de controles: cdigo generado por el motor de ASP.NET.

Figura 19. Procesamiento de controles.: ejecucin.

un mtodo 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 cdigo).

Como se aprecia en el ejemplo, el motor de ASP.NET genera gran cantidad
de cdigo por nosotros cuando usamos controles Web de servidor. Una bue-
na prctica para evitar generar pginas muy pesadas consiste en emplear
controles HTML para construir el contenido esttico de las pginas, en el que
no sea necesario personalizar ningn atributo ni tampoco se espere una res-
puesta. Por el contrario, se emplearn controles Web en caso de necesitar
acceder a las propiedades de un elemento visual desde el cdigo 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 tambin es un control) podrn accederse y manipu-
larse por el cdigo de script que se ejecute en el servidor. Es importante des-
tacar que una pgina .aspx slo puede contener un formulario de servidor.

La marca form puede ir acompaada 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 cdigo de la Figura
20, generado por el motor de ASP.NET para el cdigo de la Figura 18.

2.3. Diseo de interfaces

Hasta el momento todos los ejemplos que hemos revisado han consistido en
escribir directamente el cdigo ASP.NET. Es obvio que para disear aplica-
ciones Web de cierta entidad, esta forma de programar no es la ms adecua-
da. Adems de ser muy propensa a la comisin de errores se requiere del
programador conocimientos de diversas tecnologas relacionadas con la pro-
gramacin 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 cdigo que
finalmente se genera. La idea detrs de estas herramientas es conseguir que
los desarrolladores no deban preocuparse demasiado de los detalles de la
Controles HTML en Visual
Studio 2005

programacin de interfaces para Web, sino que puedan construir la interfaz
de forma lo ms 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 categoras existen controles similares como Button, CheckBox o Table.
Sin embargo, como es de esperar, Visual Studio los trata de forma diferente y
genera un cdigo distinto para ellos. Vemoslo con un ejemplo sencillo.
Creamos una aplicacin 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 cdigo resultante (ver Figura 21) consiste
en tres marcas INPUT de HTML de tipo text, checkbox y button, respectivamente.
Para los controles Web el cdigo generado hace referencia a los controles
correspondientes de ASP.NET, incluyendo un identificador para poder ser
accedidos programticamente en tiempo de ejecucin, etc.

Ms rigurosamente, si insertamos en una pgina 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 cuestin segn el estndar 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 Visual
Studio 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 construccin de aplicaciones de
escritorio. Se trata por lo tanto de elementos visuales ms completos y que
permiten gestionar una interaccin ms elaborada con el usuario.

La construccin de interfaces ricas de usuario requiere, por tanto, el uso de
un conjunto de controles que comparten caractersticas 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 caractersticas de los controles, la mayora de ellos, como es el
caso de los distintos tipos de botones, disponen de la propiedad Text para
asignarles un ttulo. Si se trata de un CheckBox se dispone tambin de la pro-
piedad Checked, de tipo booleano. Si es un TextBox, ste puede usarse para
introducir una o ms lneas de texto dependiendo de la propiedad TextMode,
emplendose 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.

Adems de estas propiedades especficas, que no describiremos en detalle,
para cada tipo de control, existen otras propiedades de carcter genrico que
aplican 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 ms usuales son:

Height y Width: Establecen, respectivamente, la altura y la anchura del con-
trol, mediante diversas unidades de medida absolutas (pxeles, milme-
tros, pulgadas, ) y relativas (respecto al tamao de letra por defecto,
etc.). La unidad de medida se indica mediante un sufijo, e.g. 10px para 10
pxeles, 10em para 10 veces el tamao 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 ms sencillo es usar la paleta de colores del diseador de
interfaces.
BorderColor, BorderStyle y BorderWidth: Permiten configurar el color (de igual
forma que en las propiedades anteriores), estilo (segn CSS) y anchura del
borde (usando las unidades de medida descritas anteriormente) de un
control.
Font: Establece el tipo de letra, su tamao y dems atributos habituales.

Todas estas propiedades estarn especificadas en el documento .aspx alojado
en el servidor Web correspondiente y se aplicarn en la visualizacin de la
pgina ASP.NET. Sin embargo, el navegador lo nico que recibir sern 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 si
el control ser accesible mediante teclado o ratn, 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 cdigo de la pgina en respuesta a cualquier
evento o condicin. Debe tenerse en cuenta, sin embargo, que la visualiza-
cin/ocultacin de un control oculto/visible puede conllevar una redistribu-
cin del resto de los controles en la pgina, 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 pgina (teclado, ratn, etc.).
Cmo slo un control en la pgina 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: 2px
solid; BORDER-TOP: 2px solid;
BORDER-LEFT: 2px solid;
BORDER-BOTTOM: 2px solid;
WIDTH: 234px; HEIGHT:
216px; BACKGROUND-
COLOR: #FF0BA6

Estilo correspondiente a un
control con borde slido de 2
pxeles, anchura de 234
pxeles, altura de 216 pxeles
y color de fondo expresado
en RGB.
el usuario puede usar el ratn para dar el foco de entrada a un control cual-
quiera de la pgina, es recomendable facilitar el acceso mediante teclado.
Para ello se usan las propiedades AccessKey y TabIndex. TabIndex contendr un
nmero entero superior a cero, tomando automticamente el foco de la
pgina recin cargada el control con el menor valor en esta propiedad, y
avanzando el foco al siguiente control en el orden con cada pulsacin del
tabulador. Por su parte, la propiedad AccessKey permite asignar a un control
cualquier carcter 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 pgina HTML es un documento esttico
que, una vez recibido, es visualizado por el navegador sin que haya ninguna
interaccin ms con el servidor hasta que una nueva pgina es solicitada. A
lo sumo, si la pgina contiene un formulario, los datos se enviarn al servi-
dor al hacer clic sobre el botn 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 programacin basado en eventos. As pues, cuando un control
cambia su estado, por ejemplo cuando un usuario hace clic en un botn, el
botn 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 orientacin a
eventos real. En ASP una pgina se procesa de forma secuencial, i.e. las lneas
de HTML o cdigo ASP se procesan una tras otra. Las acciones de usuario
comportan el envo de la pgina al servidor, por lo que ste debe reconstruir
la pgina, tras lo cual debe procesarla nuevamente de forma secuencial. En
consecuencia la aplicacin no muestra propiamente un comportamiento
orientado a eventos. Al contrario, si se desea dicho comportamiento debe
programarse explcitamente manteniendo el estado al ms bajo nivel, etc.
Todo ello limita la riqueza de la interfaz de usuario al tiempo que complica
enormemente el cdigo de la aplicacin.

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 asociacin de un mtodo a un evento de un control. En
la asociacin 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 mtodo
(event handler) al que invocar cuando dicho evento se produzca. Por ejem-
La generacin de eventos en
las interfaces Web de ASP.NET
requiere del envo de una
solicitud al servidor.
plo, la Figura 23 muestra cmo asociar un evento Click a un botn para cam-
biar el valor de la propiedad Text en un TextBox en tiempo de ejecucin. La
Figura 24 muestra el aspecto visual de la pgina.

Se llama a un mtodo de control de eventos slo cuando ocurre un evento
especfico de un control determinado, lo que permite evitar tener un mtodo
global en el formulario que controle todos los eventos de todos los controles.
Adems, debido a que la arquitectura de eventos de los formularios est ba-
sada en delegados, los mtodos 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 mtodo durante la compilacin.

Dos clases dan soporte a cada evento. Por una parte la clase de delegado
EventHandler, utilizada para registrar el mtodo 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
mtodo controlador:

El modelo de atencin a los
eventos de los formularios se
basa en el uso de mtodos
delegados.
En programacin orientada a
objeto es habitual identificar
un mtodo mediante su
signatura. Esta consiste en el
nombre del mtodo, el nme-
ro y tipo de sus parmetros, y
el tipo del resultado que
retorna.
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>
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 gestin de un evento.

Figura 24. Ejemplo de gestin de un evento: ejecucin.

Como resultado, cualquier mtodo 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 mtodo
de control del evento. As, si en la programacin de la lgica de la aplicacin
se usa un lenguaje fuertemente tipado, e.g. C#, se producir un error de
tiempo de compilacin si la signatura del mtodo de control del evento no
coincide con la signatura del mtodo delegado.

Existen varios eventos que utilizan clases EventHandler e EventArgs genricas. Sin
embargo, algunos eventos necesitan informacin adicional que es especfica
del tipo del evento provocado. Por ejemplo, los eventos relacionados con el
movimiento del ratn incluyen informacin acerca de la posicin del punte-
ro y de los botones del ratn. 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 despus de que se produzcan
cambios en tipos de estado de los controles o la pgina, 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 despus 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 despus de que se produzca un cambio de
estado. Si un cambio de estado provoca slo un evento, ese evento normal-
mente no tendr ningn sufijo. Por ejemplo, el evento Click.

2.4.2. Eventos en pginas 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 especficos relacionados con aspecto propios de las aplicaciones Web.
Trataremos la carga de pginas y el lanzamiento controlado de eventos.

Algunos eventos, como los de
ratn, necesitan clases de
soporte especficas, eso s,
derivadas de las clases genri-
cas EventHandler y EventArgs
<html>
void Page_Load () {
et1.Text="La fecha y hora actual es: " + System.DateTime.Now.ToString();
}
</script>
<body>
<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 pgina. Cuando eso sucede, ASP.NET invoca automticamente al
mtodo 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 pgina.

Propiedad Page.IsPostBack. El mtodo Page_Load() se ejecuta cada vez que se
carga la pgina en cuestin. Si lo que queremos es que el cdigo de Pa-
ge_Load() se ejecute slo la primera vez que se carga la pgina, debemos con-
sultar el valor de la propiedad booleana Page.IsPostBack. Si la propiedad tiene
valor falso, la pgina se est cargando por primera vez, pero si la propiedad
es cierta, la pgina est siendo cargada de nuevo, como cuando se han con-
firmado los datos del formulario, por ejemplo. El cdigo de la Figura 26
muestra un ejemplo en el que se comprueba el valor de la propiedad Pa-
ge.IsPostBack en el mtodo Page_Load(), de forma que la fecha y hora mostradas
en la pgina no cambian cuando se pulsa el botn de envo.

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 cdigo al evento Chec-
kedChanged, ste en realidad no tendr lugar cuando el usuario cambie la se-
leccin en el CheckBox, sino slo al enviar el formulario al servidor. Si asig-
namos el valor cierto a la propiedad AutoPostBack haremos que ASP.NET aada
a la pgina el cdigo 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-
cacin Web ejecuta la interfaz de usuario en el navegador del cliente, mien-
tras que la lgica de la aplicacin se ejecuta en un servidor remoto con el que
el navegador se comunica a travs de un medio relativamente lento como es
<html>
void Page_Load () {
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>
<asp:button text="Envo" onclick="submit" runat="server" />
</form>
</body>
</html>
Figura 26. Ejemplo de uso de Page.IsPostBack.

una red. As pues el envo continuado de solicitudes, por ejemplo en cada
cambio de seleccin en una lista, provocaran un funcionamiento de la apli-
cacin y un trfico excesivamente pesados.

2.5. Acceso al flujo de HTML

La ltima forma de interfaz para las aplicaciones consiste en la utilizacin
directa del flujo de informacin HTML, en cualquiera de los dos sentidos.

En diversos de los ejemplos vistos hasta el momento hemos utilizado tci-
tamente la propiedad Response de la clase Page, y concretamente el mtodo
Write(), para introducir contenido en el documento que se enva a travs 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 travs de sus mtodos.

Mediante el mtodo Write() de Response, no slo es posible introducir un string
de cdigo HTML en el flujo de respuesta, sino que tambin puede introducir-
se directamente la informacin almacenada en un archivo usando el mtodo
WriteFile(). Igualmente es posible introducir datos binarios en el documento de
respuesta mediante el mtodo BinaryWrite(), que admite como parmetro 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.

Tambin 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 pgina distin-
ta mediante el mtodo Redirect(), entre otras cosas.

Por su parte, la propiedad Request dispone de propiedades que permiten recu-
perar diversa informacin procedente del navegador cliente: la cadena de
consulta (QueryString), los formularios (Form), los archivos adjuntos a la solici-
tud (Files), etc. Adems, 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 mtodos como BinaryRead() y SaveAs() para leer datos de la
solicitud o guardar dicha informacin en una archivo, por ejemplo.
3. Primera aplicacin ASP.NET
El objetivo de este breve apartado es proporcionar cierta familiaridad prctica
con la construccin de la interfaz de usuario de una aplicacin Web de
ASP.NET, mediante Visual Studio. La aplicacin simula un sistema sencillo
de compra de pizzas a travs de Internet. En primer lugar crearemos un pro-
yecto de Visual Studio para el desarrollo de una aplicacin Web. Seguida-
mente disearemos la interfaz de usuario de la aplicacin mediante la caja de
herramientas del diseador 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-
recern el los captulos sucesivos, harn referencia a la aplicacin resultante
de este apartado, por lo que es muy recomendable completarlo antes de se-
guir con el resto de apartados.

3.1. Introduccin

Tal como se ha comentado, la aplicacin que vamos a desarrollar se enmarca
en el contexto de un sencillo sistema de compra de pizzas a travs de Inter-
net. Concretamente construiremos una pgina .aspx en la que se determinar
el precio de la pizza a partir de las preferencias del cliente. En definitiva se
tratar simplemente de disear un formulario Web utilizando diversos con-
troles y dotndolos de comportamiento. El proceso de construccin de la
aplicacin ser guiado por sucesivos pasos a modo de tutorial.

Cabe resaltar que el trmino aplicacin se usa en este punto de forma un
tanto ambiciosa puesto que el concepto de aplicacin en ASP.NET incluye
muchos ms elementos de los que aqu se van a tratar (ver apartado
Aplicaciones Web). Por otra parte hacer notar que aunque la aplicacin
resultante de este apartado es una sencilla pgina Web, se espera dar pie a la
experimentacin con los diversos controles que pueden usarse en un formu-
lario Web, sus propiedades visuales, as como la gestin de sus eventos.

En lnea con lo anterior, cabe destacar que en ningn caso esta aplicacin
pretende ser una aplicacin "real". Por una parte su funcionalidad es muy
reducida y no pretende ser representativa de la complejidad que puede llegar
a tener una aplicacin ASP.NET. Por otra, su diseo e implementacin se ha
realizado teniendo en cuenta los pocos conocimientos vistos hasta este pun-
to. Por lo que la aplicacin no emplea mecanismos que se vern ms adelan-
te y que toda aplicacin ASP.NET bien diseada debera utilizar, como por
ejemplo validacin, gestin del estado, etc.

3.2. Creacin del proyecto

En los pasos siguientes crearemos un proyecto de aplicacin Web que deno-
minaremos PizzaPricer y programaremos en C#.

1. Ejecutamos Visual Studio, si no est ya en ejecucin.
2. Para crear un nuevo proyecto hacemos clic en el men Archivo, en la
opcin 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 Ubicacin escribimos el directorio donde se alojar la apli-
cacin (no usaremos IIS). La Figura 28 muestra el cuadro de dilogo resul-
tante.
6. Clicamos Aceptar y el IDE ofrece un aspecto como el de la Figura 29.

Figura 28. Dilogo de creacin de un proyecto de aplicacin Web en Visual Studio.

Figura 29. IDE de Visual Studio para la creacin de aplicaciones Web.

Si hubisemos decidido usar IIS para alojar la aplicacin, 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 fsicamente en C:\inetpub\wwwroot\PizzaPricer\, se alojan no slo los
archivos de cdigo sino todos los archivos que precisa Visual Studio para la
programacin y depurado de la aplicacin (ver Figura 30).

3.3. Diseo de la interfaz

En este punto construimos una sencilla interfaz de usuario en la que podr
indicarse el tamao de la pizza mediante RadioButtons, escogerse los ingredien-
tes mediante CheckBoxes y, al clicarse un botn, visualizar el precio resultante.

7. En el panel Explorador de soluciones, clicamos con el botn 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 seccin
Apaciencia, cambiamos el valor de la propiedad Text por la cadena Elige el
tamao de la pizza: .
10. En la seccin Varios, cambiamos el valor de (ID) por SizeLabel.
11. En el diseo del formulario Web, nos situamos tras la etiqueta introduci-
da y presionamos ENTER para saltar de lnea.
12. En el panel Cuadro de herramientas seleccionamos un control tipo Radio-
ButtonList y lo arrastramos sobre el formulario.
Varios, cambiamos el valor de (ID) por PizzaSizes. En la propiedad Items de

Figura 30. Directorio virtual del proyecto PizzaPricer.

la misma seccin Varios clicamos sobre el botn . Aparecer el editor
de la coleccin ListItem.

14. Clicamos el botn Agregar y aadimos las parejas de Miem-
bros/Propiedades siguientes:
Pequea 5.95
Mediana 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.
Apariencia, cambiamos el valor de la propiedad Text por Elige los com-
plementos: . Asimismo, en la seccin Varios, cambiamos el valor de (ID)
por ToppingsLabel.
18. En el diseador del formulario nos situamos tras la etiqueta introducida y
presionamos ENTER para saltar de lnea.
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 seccin Varios clicamos sobre el botn . Aparecer el editor de
la coleccin ListItem. Clicamos en el botn Agregar y aadimos las pare-
jas de Miembros/Propiedades siguientes:
Pimiento 0.50
Chorizo 0.50
Carne 0.75
Olivas 0.25

Figura 31. Aspecto de Visual Studio al completar el diseo 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 diseo del formulario nos situamos tras la etiqueta recin introdu-
cida y presionamos la barra espaciadora para separar esta etiqueta de la
que introduciremos a continuacin.
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 vaco y cambiamos el valor de (ID) por PriceResults.
25. En el diseo del formulario presionamos ENTER para saltar de lnea y
aadimos 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 debera mostrar un aspecto
como el de la Figura 31 en el que se aprecia el diseo del formulario Web
en el centro.

Con los pasos anteriores se ha completado el diseo de la interfaz de usuario
consistente en un nico formulario Web. El cdigo C# correspondiente es
autogenerado por el IDE de Visual Studio y puede verse presionando la tecla
F7 o mediante la opcin Cdigo del men Ver. Igualmente, presionando
SHIFT-F7 puede verse el cdigo HTML autogenerado por el diseador.

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 botn Calcu-
lar precio, la etiqueta PriceResults muestre el precio resultante. En el formula-
rio que acabamos de disear, esto consistir simplemente en asociar un
mtodo delegado al evento Click del citado botn.

27. De vuelta al diseo del formulario (ver Figura 31) seleccionamos el botn
CalculatePrice y en el panel de Propiedades hacemos clic en el botn
, lo que da acceso a la lista de mtodos asociados a eventos para el
control seleccionado.
28. En la accin correspondiente al evento Click escribimos el nombre del
mtodo, CalculatePrice_Click, que a continuacin programaremos. Al presio-
nar ENTER el IDE cambia al modo de escritura de cdigo. En la ventana
que se abre escribiremos el cdigo de la Figura 32 para el mtodo recin
creado.


3.5. Pruebas y depuracin

Una vez el cdigo asociado a la interfaz est listo, ya podemos compilar la
solucin y probarla.

29. Para compilar el cdigo seleccionamos la opcin Generar Sitio Web del
men Generar.
30. Para ejecutar la aplicacin hacemos clic con el botn derecho sobre el
archivo PizzaPricer.aspx en el panel Explorador de soluciones, selecciona-
mos la opcin Ver con y, seguidamente, la opcin Explorador integra-
do. Visual Studio mostrar un aspecto similar al de la Figura 33.

31. La aplicacin tambin puede ejecutarse en el navegador predeterminado
del sistema, para su depuracin desde Visual Studio. Esto puede hacerse
seleccionando la opcin Iniciar del men Depurar, presionando F5 o
haciendo clic sobre el botn del IDE (ver Figura 34). La depuracin

Figura 33. Ejecucin 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. Mtodo CalculatePrice_Click.

puede detenerse en cualquier momento seleccionando la opcin Detener
depuracin del men Depurar o clicando sobre el botn .

Finalmente, si se ha usado IIS para alojar la aplicacin durante el desarrollo,
sta tambin puede ejecutarse directamente en el navegador preferido del
desarrollador (ver Figura 35). Si se accede desde el propio ordenador donde
se est desarrollando la aplicacin esto puede hacerse accediendo a la URL
http://localhost/PizzaPricer/PizzaPricer.aspx. Si se est accediendo desde otro
ordenador de la misma red donde se est programando la aplicacin bastar
indicar la URL con la direccin 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. Ejecucin de PizzaPricer en Mozilla Firefox lanzado desde Visual Studio.

Figura 35. Ejecucin de PizzaPricer en Mozilla Firefox.


3.6. Observaciones

Como ya hemos comentado anteriormente, la aplicacin que se ha cons-
truido en este apartado dista mucho de ser considerada una aplicacin Web
propiamente, puesto que no plantea casi ninguna de la problemtica habi-
tuales en este tipo de aplicaciones.

En primer lugar se trata de una aplicacin constituida por una sola pgina
Web, para acceder a la cul no es preciso ningn tipo de autenticacin pre-
via. Habitualmente una aplicacin Web, por sencilla que sea, consta de di-
versas pginas enlazadas entre s a las que se accede tras la identificacin del
usuario en otra pgina inicial (ver apartado Autenticacin y autorizacin),
usando mecanismos de autenticacin diversos: los propios de la aplicacin,
los del servidor Web, un directorio activo, etc. El uso de diversas pginas en
una aplicacin plantea adems la problemtica de cmo mantener los datos
de la aplicacin cuando el usuario cambia de una pgina a otra, problemtica
derivada del desacoplamiento entre cliente y servidor del protocolo HTTP
(ver apartado Aplicaciones Web).

Por otra parte, no hay tampoco ningn tipo de validacin de los datos (ver
apartado Validacin de datos) lo que puede provocar que la aplicacin 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 permitirn ir completando algunos de los aspectos
citados, sobre la aplicacin 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 pgina 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
cmo 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 pgina Web Forms

El procesamiento de una pgina Web Forms es similar al de cualquier proce-
so Web que se ejecuta en el servidor, i.e. la informacin 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 informacin enviada
junto a los formularios y la hace accesible a travs de propiedades de objetos.

Comprender la secuencia de eventos que tienen lugar durante el procesa-
miento de una pgina Web Forms puede ayudar a desarrollar aplicaciones
Web de forma ms efectiva. Antes, sin embargo, revisaremos algunas carac-
tersticas 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 enva de nuevo al servidor (post back). Adems, 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 mayora de acciones de usuario, como hacer clic en un
botn, dan como resultado un round trip. Por esa razn, los controles de
servidor slo exponen eventos de tipo clic, i.e. eventos que requieren de una
accin explcita 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 penalizaran el rendimiento de la aplicacin.

En Web Forms tambin puede
crearse cdigo de script ejecu-
table en el navegador cliente.
Esto es til para la validacin
de datos introducidos por el
usuario en el formulario, por
ejemplo. Este tipo de cdigo
script no interacta con com-
ponentes de servidor.

Puesto que las pginas se reconstruyen con cada round trip, el servidor no
necesita mantener la informacin de la pgina una vez que ha finalizado su
procesamiento y la ha enviado al navegador. Es decir, el servidor no mantie-
ne el estado y la prxima vez que se solicite la pgina sta ser reprocesada
de nuevo. Al liberarse los recursos del servidor tras cada solicitud, una aplica-
cin Web puede escalarse a un gran nmero de usuarios simultneos.

En una aplicacin Web tradicional, la nica informacin de un formulario
que el servidor almacena es la informacin que introducida por el usuario en
los diversos controles de la pgina, puesto que dicha informacin se enva al
servidor cuanto se le devuelve el formulario. Cualquier otra informacin,
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 pgina y de los controles entre round
trips. Esto se conoce habitualmente como almacenar el view state de los
controles.
Proporciona mecanismos de gestin del estado, de forma que el progra-
mador pueda conservar el valor de las variables y otra informacin propia
de la aplicacin o la sesin 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 mtodos de atencin a los mismos.
Estos mtodos proporcionan puntos de entrada que permiten que la pgi-
na pueda manipularse desde el cdigo.
El servidor puede configurarse
para que utilice una cach de
pginas con el fin de mejorar
el rendimiento. Sin embargo,
es preferible pensar que el
servidor descarta las pginas
una vez ha acabado de proce-
sarlas.

Figura 36. Ciclo de vida de una pgina Web Form (Round trip).

A continuacin se resumen las etapas ms 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 pgina se solicita o se
produce un round trip.

Es importante destacar que en el procesamiento de pginas Web Forms exis-
ten ms 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. Excepcin hecha del caso
en el que el programador est desarrollando sus propios controles de servidor
(ver apartado Controles personalizados).

Inicializacin del entorno de ejecucin de la pgina. Se lanza el evento
Page_Init y se restaura el valor del view state de la pgina. Durante este evento
el entorno de ejecucin de la pgina restaura las propiedades y los datos de
los controles.

Inicializacin del cdigo de usuario. Se lanza el evento Page_Load. Mediante
la propiedad Page.IsPostBack puede saberse si es la primera vez que se carga la
pgina o se trata de un post back. Si la pgina 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.

Validacin. Se invoca al mtodo Validate() de los controles de validacin pre-
sentes en la pgina. Esta etapa no es accesible para el programador. El resul-
tado de la validacin puede consultarse en la siguiente etapa mediante un
mtodo de atencin a eventos. Veremos ms sobre validacin de datos en el
apartado Validacin de datos.

Atencin a eventos. Si la pgina se invoc en respuesta a un evento del for-
mulario, el mtodo de atencin a dicho evento se invoca en esta etapa. Es
importante destacar que los eventos no se lanzan en ningn 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 tpicamente
realiza alguna de las siguientes tareas:
Si la pgina contiene controles de validacin de servidor, se comprueba la
propiedad IsValid de la pgina y de los controles individuales para actuar en
consecuencia.
Si se est manteniendo explcitamente el estado de algunas variables, este es
el momento de salvar sus valores.
Salvar el estado de los controles que se hayan aadido dinmicamente en
esta etapa.

Limpieza. Se lanza el evento Page_Unload puesto que se ha completado la
construccin de la pgina 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 explcitamente en esta etapa y no se espere a que el procedimiento de
recoleccin 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 pgina 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 pgina puede
contener diversos formularios HTML, no es habitual tener ms de uno. El
elemento form de HTML admite principalmente dos atributos: action, que
determina a qu URL se enviar la informacin del formulario, y method que
indica el mtodo usado en la solicitud. En el caso de ASP.NET action apuntar
a la pgina .aspx encargada de procesar los datos del formulario, mientras que
method es generalmente post, de forma que los datos se envan incrustados en
el cuerpo de la solicitud HTTP y no como parmetros 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 pgina .aspx. La Figura 37
muestra el cdigo 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 pgina Ejemplo_Procesado.aspx (ver Figura 38). Para el
envo de los datos no se utiliza ninguna caracterstica especfica del sistema
operativo, ni del navegador, ni de ASP.NET, sino simplemente HTTP y HTML
estndar. De hecho, el navegador no tiene conocimiento del contenido de
los datos en ningn momento, sino que su funcin consiste nicamente en
enviarlos segn el mtodo 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 tambin procesar datos de cualquier
formulario HTML. Para ello usaremos una propiedad de la clase Page llamada
Request (un objeto de la clase HttpRequest) que permite acceder directamente a
El estndar HTTP define me-
canismos para el envo de
datos desde formularios
HTML. 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> Telfono: <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 cmo se ha enviado el formulario, es decir, si se ha usado el
mtodo GET o el mtodo 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-
formacin aadida al final de la URL de una pgina. 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 coleccin 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, podramos acceder al valor introducido por el usuario
en el formulario de la siguiente forma:

Una forma alternativa e independiente del mtodo usado para la solicitud
consiste en usar la coleccin Params, que permite acceder adems a las cookies
y a las variables del servidor, de la siguiente forma:

La Figura 38 muestra el cdigo de la pgina Ejemplo_Procesado.aspx que enumera
todos los parmetros 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>
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 estndar. Sin embargo, lo realmente interesante
es usar los Web Forms y los controles Web de servidor. En tal caso, sern los
propios controles, quienes al ejecutarse en el servidor, sern 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 cdigo 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 escribir
Nombre.Text obtenemos el texto introducido en el cuadro de texto Nombre. La
Figura 40 muestra el resultado de la ejecucin. El resultado es el mismo tanto
si se emplea un formulario HTML como si se emplea un formulario Web
Forms.

<html>
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> Telfono: <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: ejecucin.

4.3. Validacin de datos

Cualquier aplicacin, sea para la Web o no, necesita comprobar que los datos
introducidos por el usuario cumplen determinados criterios de validez que
permitirn que la aplicacin se ejecute adecuadamente. En una aplicacin
Web, las comprobaciones se ejecutaran en el servidor una vez que este
hubiese recibido los datos del formulario. En tal caso, ante un error en los
datos, ste se indicara al usuario mediante un reenvo de la pgina, quedan-
do el servidor a la espera de la correccin, y as sucesivamente. Es evidente,
que si el conjunto de datos a verificar fuese grande, el nmero de solicitudes
y reenvos podra comprometer considerablemente el rendimiento de la
aplicacin.

La mayora de validaciones de datos no son excesivamente complejas o no
requieren de acceso a otra informacin fuera del formulario. As, para mini-
mizar la citada bajada de rendimiento, es habitual que la propia interfaz de
usuario incorpore lgica (normalmente JavaScript) que permita la realizacin
de ciertas validaciones en el propio navegador cliente, antes de enviar los
datos al servidor. Aunque siempre es posible escribir cdigo de validacin a
mano, lo ms indicado es recurrir a los controles de validacin que propor-
ciona ASP.NET, de forma que la validacin se lleve a cabo automticamente.

Todos los controles de validacin de una pgina ASP.NET forman parte au-
tomticamente de una coleccin de tipo ValidatorCollection en el objeto Page,
que es accesible mediante la propiedad de slo lectura Validators. La validacin
se desencadena al invocarse el mtodo Validate() de la clase Page, bien explci-
tamente o bien indirectamente a travs de algn 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 botn del formulario se validarn
los datos y slo se enviarn los datos al servidor si la validacin es satisfacto-
ria. En todo caso, el mtodo Validate() recorre la lista Validators y ejecuta la vali-
dacin indicada por cada control. Si alguna validacin falla la propiedad
IsValid de Page toma el valor false lo que permite al programador disear accio-
nes especficas en reaccin a las situaciones de error.

Como veremos, existen controles para tipos concretos de validacin, como
la comprobacin de intervalos o la coincidencia con un patrn, adems de
RequiredFieldValidator, que permite detectar situaciones en las que un usuario
haya omitido un campo de entrada obligatorio. Adicionalmente se puede
adjuntar ms de un control de validacin 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 especfico de valores.

Los controles de validacin slo funcionan con un subconjunto de controles
de servidor HTML y Web. Para cada control, una propiedad especfica con-
Controles de validacin 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 acta la validacin:

Control Propiedad de validacin
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 validacin

La forma ms sencilla de validacin son los campos requeridos, es decir la
verificacin de que un determinado control no quede vaco. Si el usuario
introduce algn valor en un campo, ste es vlido. Si todos los campos del
formulario son vlidos, la pgina es vlida. En un control de validacin de
tipo RequiredFieldValidator es imprescindible establecer dos propiedades: Control-
ToValidate en la que se indica a qu control afecta la validacin; y ErrorMessage
en la que se especifica el mensaje que debe mostrarse en la pgina si el usua-
rio intenta enviar el formulario sin introducir un valor en el campo validado.

Si aadimos el cdigo 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 Telfono.

El motor de ASP.NET substituye la marca asp:RequiredFieldValidator por instruc-
ciones JavaScript y atributos que se aaden al formulario y al botn que
desencadena la validacin. La Figura 42 muestra parte del cdigo de la pgi-
na que recibe el navegador, donde se observa cmo se usa el evento onsubmit
para invocar una funcin JavaScript antes de realizar el envo de los datos al
servidor. Adems 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 nmero de telfono" />

</form>
</body>
</html>
Figura 41. RequiredFieldValidator para el ejemplo de la Figura 39.


Al margen de este tipo de validacin sencilla, tambin hay controles de vali-
dacin para tipos de validacin especficos, como la comprobacin de inter-
valos o la coincidencia con patrones. A continuacin resumimos los diversos
tipos de validacin:

<html>
<body>
<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> Telfono: <input name="Telefono" type="text" id="Telefono" />
<span id="Validator3" controltovalidate="Telefono"
errormessage="Debe introducir un nmero de telfono"
evaluationfunction="RequiredFieldValidatorEvaluateIsValid" initialvalue=""
style="color:Red;visibility:hidden;">Debe introducir un nmero de telfono</span>
</p>

<p> <input type="submit" name="BotonRegistro" value="Registrar"
onclick="if (typeof(Page_ClientValidate) == 'function') Page_ClientValidate(); "
language="javascript" id="BotonRegistro" />
</p>


</script>


</script>
</form>
</body>
</html>
Figura 42. RequiredFieldValidator: pgina 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-
racin (menor que, igual a, mayor qu, etc.).
RangeValidator: Comprueba que una entrada de usuario se encuentra entre
los lmites superior e inferior especificados. Se pueden comprobar los in-
tervalos entre pares de nmeros, caracteres alfabticos o fechas. Los lmi-
tes se pueden expresar como constantes.
RegularExpressionValidator: Comprueba que la entrada coincide con un patrn
definido por una expresin regular. Este tipo de validacin permite com-
probar secuencias de caracteres previsibles, como las de los cdigos posta-
les, las direcciones de correo electrnico, etc.
CustomValidator: Comprueba la entrada del usuario mediante lgica de vali-
dacin especificada por el programador. Este tipo de validacin permite
comprobar los valores generados en tiempo de ejecucin.
ValidationSummary: Muestra los errores de validacin en forma de resumen
para todos los validadores de la pgina.

4.3.2. Validacin en el cliente

Los controles de validacin que hemos citado anteriormente siempre reali-
zan la validacin mediante cdigo ejecutado en el servidor. No obstante, si el
usuario trabaja con un navegador que admite DHTML, los controles de vali-
dacin tambin pueden realizar validaciones mediante cdigo script ejecuta-
ble por el navegador. Cuando se hace validacin en el cliente, los errores se
detectan antes de enviar el formulario al servidor. Si alguna de las validacio-
nes no se supera, el envo 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 validacin interactiva al usuario.

Es importante destacar que el motor de Web Forms siempre realiza la valida-
cin en el servidor, incluso cuando ya se ha realizado en el cliente. De esta
forma, se evita que los usuarios puedan omitir la validacin mediante la
suplantacin de otro usuario o de una transaccin previamente aprobada.

La validacin en el cliente es el comportamiento por defecto. Si el cliente lo
permite, la validacin de alto nivel se realiza automticamente. Para deshabi-
litar la validacin en el cliente, basta con establecer la propiedad ClientTarget
de la pgina en "Downlevel" ("Uplevel" fuerza la validacin en el cliente).

Todos los controles de valida-
cin derivan de la clase Base-
Validator definida en el espa-
cio de nombres
System.Web.UI.WebControls.
Se recomienda realizar la actividad 1 antes de continuar.
4.3.3. Visualizacin de errores de validacin

Tal como hemos visto en los ejemplos anteriores, si falla un control de vali-
dacin puede mostrarse un mensaje de error en el lugar ocupado por el con-
trol en la pgina. Por otra parte, tambin pueden mostrarse varios errores (o
todos) agrupados en cualquier lugar de la pgina mediante un control Valida-
tionSummary. El control ValidationSummary recoge los mensajes de error de todos
los controles de validacin de la pgina y los visualiza si la propiedad IsValid
de la pgina es false.

La Figura 43 muestra el cdigo resultante al aadir un control ValidationSumma-
ry al ejemplo. Para evitar que el resto de los validadores tambin muestren el
mensaje de error de forma redundante, se ha modificado su propiedad Text
para que, en caso de no validacin, nicamente muestren un asterisco. La
Figura 44 muestra el resultado de la ejecucin.

<html>
<body>


<p> Telfono: <asp:TextBox id="Telefono" runat="server" />
<asp:RequiredFieldValidator id="Validator3" runat="server"
ErrorMessage="Debe introducir un nmero de telfono"
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 accin.

4.3.4. Validacin relacional y de rangos

Adems de forzar que un control de entrada de datos contenga un valor,
tambin es posible comprobar si el valor introducido guarda algn tipo de
relacin con un valor de referencia (CompareValidator) o si el valor est dentro
de un rango de valores predeterminados (RangeValidator).

El operador de comparacin 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
nmero entero, un nmero 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
cdigo de la Figura 45 aade al ejemplo la comprobacin de que el telfono
introducido sea un nmero entero.

4.3.5. Expresiones regulares

Es frecuente que la validacin de datos requiera de comprobaciones ms
complejas que la simple comparacin con un valor o un rango de referencia.
Aunque siempre puede recurrirse a una validacin totalmente personalizada
(ver siguiente apartado), a menudo puede caracterizarse el conjunto de valo-
res vlidos para un campo mediante una expresin regular.

En ASP.NET el control de servidor RegularExpressionValidator permite comprobar
la correspondencia de una secuencia de caracteres respecto a una expresin
regular: como las de los nmeros de la seguridad social, las direcciones de
correo electrnico, los nmeros de telfono, los cdigos postales, etc. Regula-
Una expresin regular, a
menudo llamada tambin
patrn, es una expresin que
describe un conjunto de
cadenas de caracteres sin
enumerar sus elementos. Por
ejemplo, el grupo formado
por las cadenas Handel,
Hndel y Haendel se puede
describir mediante el patrn
"H(||ae?)ndel". Algunos
lenguajes de programacin
como Perl tienen un amplio
soporte a la manipulacin de
expresiones regulares.

<html>
<body>


<asp:CompareValidator id="CompareValidator1" ControlToValidate="Telefono"
ErrorMessage="El telfono debe ser un nmero" 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 validacin:
ControlToValidate, que contiene el valor que hay que validar; y ValidationExpression
que contiene el patrn con el que el valor debe coincidir. El patrn 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
programacin Perl.

El cdigo de la Figura 46 aade al ejemplo la comprobacin de que el nme-
ro de telfono introducido siga el patrn +34-934317015 en el que se especi-
fica el cdigo del pas seguido del nmero de telfono.

Aunque permite la edicin manual de expresiones regulares, Visual Studio
incorpora tambin una lista de expresiones predefinidas (ver Figura 47).

4.3.6. Validacin personalizada

En ltima instancia cabe la posibilidad de escribir una funcin de validacin
que lleve a cabo cualquier tipo de validacin, por compleja que sea, y que los
controles de validacin anteriores no puedan llevar a cabo. Dicha funcin
deber vincularse al control correspondiente del formulario mediante el
control CustomValidator y su propiedad ControlToValidate. La funcin 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>


<asp:RegularExpressionValidator id="RegularExpressionValidator1" runat="server"
ErrorMessage="Nmero de telfono no vlido" 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
validacin.

Si se desea que la validacin suceda en el servidor para as poder programarla
en cualquier lenguaje que estemos usando junto a ASP.NET, deber asignar el
mtodo delegado a la propiedad OnServerValidate. La Figura 48 muestra el cdi-
go resultante para el control CustomValidator. En este caso, la validacin 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 validacin se
notifica a la pgina mediante el valor de la propiedad IsValid. Puesto que la
validacin sucede en el servidor, sta no tiene lugar hasta que se produce el
envo 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 validacin no se harn visibles hasta que se complete
el round trip.

Por otra parte, si lo que se desea es que la validacin suceda completamente
en el navegador del cliente, deberemos programar la funcin de validacin
usando un lenguaje de script como Javascript, JScript o VBScript. El nombre
de la funcin de validacin personalizada debe identificarse en la propiedad
ClientValidationFunction. La Figura 49 muestra un ejemplo de validacin en el
cliente mediante una funcin escrita en Javascript.

Para concluir este punto cabe destacar que ASP.NET permite combinar am-
bos tipos de validacin. Es decir, es posible asignar una funcin de valida-
cin ejecutable en el cliente mediante la propiedad ClientValidationFunction y
Parte de archivo .aspx

<html>
<body>


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

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 funcin de validacin 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 negociarn el tipo de validacin, dando preferencia la valida-
cin 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 slo con orgenes de datos, sino tambin con
propiedades simples, colecciones, expresiones e incluso con resultados de
llamadas a mtodos. La siguiente tabla muestra algunos ejemplos:

Propiedad simple
Cliente: <%# custID %>
Coleccin
Pedidos: <asp:ListBox id="List1" datasource='<%# myArray %>'
runat="server">
Expresin
Contacto: <%# ( cliente.Nombre + " " + cliente.Apellido ) %>
Resultado de mtodo
Balance: <%# ObtenerBalance(custID) %>

El enlace a datos de ASP.NET se evala cuando se invoca al mtodo DataBind().
ste es un mtodo 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;
else
arguments.IsValid = true;
}
</script>
<body>


<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 mtodo 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 pgina se evalan. Data-
Bind() suele invocarse desde el evento Page_Load.

Una expresin de enlace a datos puede usarse casi en cualquier parte de la
seccin declarativa de una pgina .aspx. Los anteriores ejemplos de propiedad
simple, expresin y mtodo muestran texto al usuario cuando se evalan. En
estos casos, la expresin de enlace a datos debe evaluar a un valor de tipo
String. En el ejemplo de la coleccin, la expresin de enlace a datos evala a
un valor de tipo vlido 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 pblicas, pro-
piedades de Page y propiedades de otros controles de la pgina. El ejemplo de
la Figura 50 muestra cmo enlazar con una variable pblica y una propiedad
simple de la pgina. Debe observarse que estos valores se inicializan antes de
llamar a DataBind().

Los controles de servidor que utilizan algn tipo de lista, como DataGrid, List-
Box y HTMLSelect, utilizan una coleccin como origen de datos. Lo ms 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 coleccin de tipo ArrayList. La Figura 52 muestra el
resultado de la ejecucin del ejemplo.

<html>
Page.DataBind();
}

string IDCliente{
get { return ("CLI145"); }
}

int NumPedidos{
get { return (15); }
}
</script>
<body>
<form runat=server ID="Form1">
Cliente: <b><%# IDCliente %></b><br>
Nmero 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 pgina o con un control. El ejemplo de la Figura 53 muestra
tambin cmo enlazar con una expresin y con el valor devuelto por un
mtodo.

<html>
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 coleccin de tipo ArrayList.

Figura 52. Enlace de datos con una coleccin de tipo ArrayList: ejecucin.


4.4.2. Visual Studio

Visual Studio proporciona diversos controles especficos para facilitar el acce-
so a fuentes de datos y para realizar enlace a datos de una forma bastante
automtica e intuitiva mediante asistentes. Destaca por ejemplo el control
GridView para mostrar datos en forma de hoja de clculo, 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 prctico sobre cmo usar el control GridView.

Controles de datos en Visual
Studio 2005

<html>
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>
<asp:DataList id="DataList1" runat="server" BorderWidth="2" GridLines="Both"
CellPadding="4" >
<ItemTemplate>
El nmero <%# Container.DataItem %>
es <%# ParOImpar((int) Container.DataItem) %>
</ItemTemplate>
</asp:Datalist>
</form>
</body>
</html>
Figura 53. Enlace de datos con una coleccin de tipo ArrayList y con un mtodo.

Figura 54. Aspecto de un GridView en tiempo de diseo.

5. Aplicaciones Web
El objetivo de este apartado es profundizar en el concepto de aplicacin Web
de ASP.NET as como los mecanismos para su gestin. Se entiende por apli-
cacin el conjunto de pginas 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 aplicacin Web desde el punto de vista de
ASP.NET, repasando los principales objetos implicados, los distintos estados
por los que pasa una aplicacin a lo largo de su ciclo de vida, etc. A conti-
nuacin estudiaremos el archivo Global.asax mediante el cul es posible alma-
cenar informacin, definir mtodos de control de eventos, etc. de forma
general a toda la aplicacin. A continuacin estudiaremos en detalle los me-
canismos que proporciona una aplicacin para solventar un problema clsi-
co en las aplicaciones Web, la gestin del estado, bien sea entre solicitudes,
sesiones, o a nivel de toda la aplicacin. Finalmente se estudiar el sistema
de configuracin de las aplicaciones ASP.NET, analizando el contenido de los
archivos de configuracin Web.config y su uso desde programa.

5.1. Aplicaciones Web ASP.NET

Una aplicacin Web ASP.NET se define como el conjunto de todas las pgi-
nas HTML, pginas .aspx, archivos XML, cdigo ejecutable, etc. que pueden
invocarse o ejecutarse dentro del mbito de un determinado directorio vir-
tual en un servidor de aplicaciones Web.

Cada aplicacin de un servidor Web se ejecuta de forma segura dentro de un
dominio nico de aplicacin (AppDomain) del entorno de ejecucin 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 estticas, entre
otras cosas.

El concepto de aplicacin se expone al programador mediante el objeto Appli-
cation (ver apartado Gestin del estado). Puede usarse este objeto, por
ejemplo, para almacenar otros objetos con visibilidad global a toda la aplica-
cin, es decir, accesibles por todas las pginas y formularios que la compo-
nen. Por otra parte, la creacin de un archivo Global.asax (ver apartado El
archivo Global.asax) en la raz del directorio virtual de la aplicacin, permi-
tir, entre otras cosas, la definicin de diversos mtodos controladores de
eventos, por ejemplo para los eventos de inicio y finalizacin de una aplica-
cin.

Los dominios de aplicacin,
representados por objetos de
la clase AppDomain, propor-
cionan al entorno de ejecu-
cin de .NET aislamiento y
fronteras de seguridad para la
ejecucin del cdigo de
distintas aplicaciones simulta-
neamente.
A lo largo del tiempo en que una aplicacin Web est en ejecucin, sta debe
poder gestionar diversas conexiones concurrentes de uno o mltiples usua-
rios. Esta flexibilidad, debida al desacoplamiento entre el navegador cliente
de la aplicacin y el servidor, presenta algunas problemticas cuando se trata
de mantener datos globales a toda la aplicacin. Por ejemplo un histrico
con datos de clientes en una tienda virtual. Es ms, an en una misma se-
sin 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 aplicacin.

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 aplicacin Web. ASP.NET asigna automtica-
mente una de estas instancias para procesar cada solicitud HTTP entrante
recibida por la aplicacin. La instancia concreta de la clase HttpApplication
asignada a la solicitud es responsable del procesamiento de la solicitud a lo
largo de todo su perodo de duracin y slo se puede reutilizar despus de
que la solicitud se haya completado. Esto significa, entre otras cosas, que el
cdigo 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 peticin.

La puesta en marcha y el procesamiento de las distintas solicitudes que se
suceden en una aplicacin de ASP.NET sigue las etapas descritas a continua-
cin (ver Figura 55):

Se dice que un programa es
reentrante si est diseado de
forma que una sola copia del
programa en memoria pueda
compartirse por mltiples
usuarios y/o diferentes proce-
sos. Una de las claves para
construir programas reentran-
tes es que las variables locales
se almacenen reas de memo-
ria distintas para cada usuario
o proceso. La programacin
reentrante es clave en siste-
mas multitarea y multiusuario
como las aplicaciones Web.

Figura 55. Ciclo de vida de una aplicacin ASP.NET.

En el momento en que el servidor Web recibe la primera solicitud desti-
nada a una aplicacin, el motor de ASP.NET crea el mbito de aplicacin,
i.e. un objeto AppDomain, especfico para la aplicacin. Antes de la primera
solicitud no se ejecuta ningn cdigo ASP.NET relacionado con dicha
aplicacin.

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 recin llegada, liberndose 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 mtodo 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
mdulos HTTP necesarios para atender la solicitud. Los mdulos se inicia-
lizan, invocando a su respectivo mtodo Init(), en el orden en que apare-
cen en el archivo Web.config (ver apartado Configuracin de la aplica-
cin), almacenado en la raz del directorio virtual. Seguidamente se
invoca al mtodo Init() del propio objeto HttpApplication que est procesando
la solicitud. Este mtodo es un mtodo virtual al que puede hacerse un
override en el archivo Global.asax. A diferencia del mtodo controlador de
eventos Application_Start(), el mtodo Init() se invoca una vez por cada ins-
tancia de la clase HttpApplication, es decir, por cada solicitud a la aplicacin.

Cuando se completa una solicitud se invoca al mtodo Dispose del objeto
HttpApplication que estaba procesando la solicitud. Al igual que el mtodo
Init(), el mtodo Dispose() de HttpApplication se invoca por cada instancia, de
forma que un mismo objeto HttpApplication puede utilizarse varias veces a
lo largo de la ejecucin de la (misma) aplicacin.

Antes de que ASP.NET finalice el AppDomain, la clase HttpApplication lanza el
evento OnEnd que normalmente es atendido por el mtodo 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 ejecucin de la aplicacin.

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 raz del directorio vir-
tual de la aplicacin. Este archivo, tambin conocido como el archivo de
aplicacin de ASP.NET, es de gran importancia para la gestin del estado
Un mdulo HTTP es un filtro
capaz de pre y postprocesar
las solicitudes HTTP en su
paso por el motor de gestin
del protocolo HTTP. Por
ejemplo, diversos servicios de
ASP.NET, como los mecanis-
mos de seguridad y de ges-
tin del estado de una sesin,
estn implementados me-
diante mdulos HTTP.
En ASP.NET los mdulos HTTP
son clases que implementan
la interface Sys-
tem.Web.IHttpModule .
puesto que en l puede especificarse cdigo de atencin a los eventos de
nivel de aplicacin provocados por ASP.NET o los mdulos HTTP.

Global.asax se analiza y compila en tiempo de ejecucin, generndose dinmi-
camente una clase derivada de HttpApplication en la que pueden redefinirse los
mtodos de atencin 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 aplicacin correspondiente. Seguidamente se muestra la forma en que
puede definirse un mtodo de atencin al evento de inicio de la aplicacin:

Si el cdigo de atencin a los eventos necesita importar espacios de nombres
adicionales, se puede utilizar la directiva @ Import de la misma forma que en
una pgina .aspx:

El archivo Global.asax es opcional, por lo que si no se define, ASP.NET asume
que no se van a definir mtodos de atencin a los eventos del nivel de apli-
cacin o sesin. El archivo est protegido de accesos directos desde el nave-
gador del cliente, de forma que no puede descargarse ni verse su cdigo.

Los cambios en el archivo Global.asax pueden hacerse an cuando la aplica-
cin est ejecutndose. Cuando ASP.NET detecta los cambios en el archivo,
espera a que se completen todas las solicitudes, enva el evento Applica-
tion_OnEnd y reinicia el dominio de la aplicacin. Esto conlleva cerrar todas
las sesiones activas y que el estado de la sesin 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 perodo de vida de los objetos Application,
Session y Request. La primera vez que se abre la pgina, se provoca el evento
Start para la aplicacin y la sesin, con lo que se ejecutan los mtodos Applica-
tion_Start() y Session_Start(), respectivamente. Los eventos BeginRequest y EndRe-
quest se provocan en cada solicitud. Cuando la pgina se actualiza, slo apa-
recen mensajes de BeginRequest, EndRequest y el mtodo Page_Load. Al abandonar
la sesin actual (haciendo clic en el botn "Finalizar esta sesin"), se crea una
nueva sesin y se provoca de nuevo el evento Session_Start. La Figura 57 mues-
tra un instante de la ejecucin del ejemplo.


void Application_Start(object sender, EventArgs e) {
// Cdigo que se ejecutar al iniciarse la aplicacin
}
</script>
<%@ Import Namespace="System.Text" %>

Archivo Ejemplo.aspx
<html>
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 pgina" runat="server" ID="Submit1"
NAME="Submit1"/>
<input type="submit" OnServerClick="Session_Click" Value="Finalizar sesin"
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 sesin...<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: ejecucin.

5.3. Gestin del estado

Se entiende por estado de una aplicacin cualquier dato que afecta al com-
portamiento global de la misma. Algunos ejemplos paradigmticos incluyen
los catlogos 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 gestin no lo es tanto, debido
fundamentalmente al desacoplamiento entre solicitudes consecutivas al ser-
vidor. Es ms, tratar de gestionar el estado de una aplicacin Web va, por as
decirlo, en contra de los principios fundamentales de diseo de la propia
Web. Por principio, la Web y el protocolo HTTP proporcionan un medio
escalable para el intercambio de informacin. Al aadir informacin de esta-
do la escalabilidad se reduce considerablemente puesto que las pginas mos-
tradas a un usuario sern diferentes a las pginas mostradas a otro y, por lo
tanto, no podrn 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 bsica como la experiencia de usuario dependen en
buena medida de la capacidad de la aplicacin de almacenar datos sobre
cada usuario, ya sean los artculos que un cliente lleva en el carrito de la
compra, los das de vacaciones solicitados por un empleado, etc.

ASP.NET proporciona mecanismos sencillos de gestin del estado tanto a
nivel de la aplicacin global, como a nivel de la sesin de un usuario concre-
to. Por ejemplo, el problema de la prdida de datos del formulario en el
round trip desaparece automticamente al disponerse de un mecanismo
denominado view state. Adicionalmente a los mecanismos predefinidos, que
generalmente se asocian a toda la pgina y/o a los controles que contiene,
ASP.NET tambin facilita que el programador pueda almacenar datos espec-
ficos de la aplicacin, 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 informacin en la propia pgina o en el navegador del
cliente. Ninguno de estos mecanismos recurre al servidor para almacenar
informacin entre round trips.

Campos ocultos. ASP.NET permite usar campos ocultos del estndar 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 explcitamente 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 podra ver y
modificar el contenido de un
campo oculto con relativa
facilidad. En consecuencia no
se recomienda usar campos
ocultos para almacenar in-
formacin sensible.

Cuando se enva una pgina al servidor, el valor de los campos ocultos se
enva junto con los valores del resto de controles. As, un campo oculto pue-
de usarse para almacenar cualquier informacin especfica de la pgina.

Finalmente remarcar que para poder usar campos ocultos el mecanismo de
envo de la pgina 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 pgina proporciona un
objeto de diccionario que permite almacenar valores a lo largo de mltiples
solicitudes de una misma pgina al servidor. Este es el mtodo que usa la
pgina entre round trips para almacenar tanto sus propiedades como las de
los controles que contiene. As, cuando se procesa una pgina, su estado
actual y el de sus controles se codifica en un string que se almacena en la
propia pgina como un campo oculto denominado _VIEWSTATE. Cuando la
pgina se solicita nuevamente al servidor la pgina analiza dicho string y
restaura los valores de las propiedades de los objetos en la pgina. 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 pequea cantidad de datos almacenados en un
archivo en el ordenador del cliente o en la memoria de la sesin del navega-
dor del cliente. Una cookie contiene informacin especfica de una pgina
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 tamao de las cookies a un mximo de 4096
bytes lo que condiciona la cantidad de informacin que puede almacenarse
mediante este sistema.

Una cookie puede usarse para almacenar informacin sobre el navegador, la
sesin o la aplicacin. As, cuando el cliente solicita una pgina, el navega-
dor enva al servidor la informacin de la cookie junto a la propia de la soli-
citud. Posteriormente el servidor puede extraer el valor de la cookie.

Un uso tpico de la cookies es el de almacenar un token (a menudo encripta-
do) que indica que el usuario ya se ha autenticado en la aplicacin por lo
que no es necesario volver a solicitarle sus datos en la prxima solicitud.
Otro uso tpico es el de almacenar datos sobre preferencias del usuario en su
interaccin con la aplicacin.

ViewState proporciona un
diccionario de informacin de
estado mediante el que alma-
cenar y recuperar el view state
de un control de servidor a lo
largo de mltiples solicitudes
al servidor.
Aviso de seguridad. El nave-
gador slo puede enviar la
cookie al servidor que la cre
originalmente. Sin embargo,
un usuario malicioso podra
apropiarse de una cookie y
leer su contenido. As pues no
es recomendable almacenar
informacin sensible (e.g. un
password) en una cookie. En
su lugar es preferible almace-
nar una clave que permita al
servidor recuperar dicha
informacin sensible.

Query strings. Mecanismo sencillo, aunque limitado, de almacenar cierta
informacin de estado. Por ejemplo, permiten pasar informacin de una
pgina a otra, como el cdigo de un producto mientras se compra en una
tienda virtual. La limitacin suele hallarse en la longitud del string ya que
muchos navegadores no admiten URLs de ms de 255 caracteres.

Aviso de seguridad. La infor-
macin almacenada en una
query string es visible en la
URL que muestra el navega-
dor por lo que no se reco-
mienda usar este mecanismo
para almacenar informacin
sensible.
<html>
<body>
<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> Telfono: <input name="Telefono" type="text" id="Telefono" />
<span id="Validator3" controltovalidate="Telefono"
errormessage="Debe introducir un nmero de telfono"
evaluationfunction="RequiredFieldValidatorEvaluateIsValid" initialvalue=""
style="color:Red;visibility:hidden;">Debe introducir un nmero de telfono
</span>
</p>

<p> <input type="submit" name="BotonRegistro" value="Registrar"
onclick="if (typeof(Page_ClientValidate) == 'function') Page_ClientValidate(); "
language="javascript" id="BotonRegistro" />
</p>


</script>


</script>
</form>
</body>
</html>
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 gestin del estado
tanto a nivel del conjunto de la aplicacin, como a nivel de una sesin de
usuario concreta.

Estado de la aplicacin. ASP.NET proporciona un mecanismo de almacena-
miento global accesible desde todas las pginas de una aplicacin Web. Me-
diante l es posible almacenar informacin que necesita mantenerse entre
round trips, entre solicitudes a distintas pginas y entre las distintas sesiones
simultneas. El acceso concurrente al almacn de datos de estado global de la
aplicacin se puede controlar mediante un sencillo mecanismo de sincroni-
zacin. Adems, los datos estn protegidos de forma que no sean accesibles
desde otras aplicaciones ASP.NET ejecutndose en el mismo servidor.

La primera vez que el navegador solicita una URL del directorio virtual de
una aplicacin ASP.NET se crea una instancia de la clase HttpApplicationState. El
objeto creado, nico para toda la aplicacin, permanece accesible a lo largo
de su ciclo de vida a travs de la propiedad Application de diversos objetos,
incluido el objeto Page.

El empleo adecuado de variables de estado de aplicacin puede ayudar a
mejorar significativamente el rendimiento de una aplicacin Web. Por ejem-
plo, al procesar una pgina que deba mostrar gran cantidad de informacin
calculada, podran cargarse los datos y realizarse los clculos, de forma que
almacenados como datos globales permitan que sucesivas solicitudes se re-
suelvan de forma mucho ms 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 sesin. El concepto de estado de sesin es similar al de estado
de aplicacin, a excepcin de que se circunscribe nicamente a una sesin
concreta de un navegador. Es decir, cada usuario-navegador que accede a la
aplicacin tiene su propio estado de sesin independiente. Es ms, si un
usuario deja la aplicacin y se reconecta ms tarde, su estado de sesin 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 sesin; generar cdigos de sesin 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 sesin; generar eventos de inicio (Session_OnStart) y finalizacin
de sesin (Session_OnEnd) en los que el programador puede aadir funcionali-
dad especfica de sesin; as como liberar los datos de sesin si el navegador
correspondiente no genera solicitudes durante cierto periodo de tiempo.

El estado de la sesin se gestiona mediante una instancia de la clase HttpSes-
sionState, nica para cada sesin, y que es accesible a travs 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 pginas de la aplicacin.

Uso de bases de datos. Es muy habitual usar bases de datos cuando la infor-
macin de estado es muy abundante. Combinado con el uso de cookies y la
identificacin nica de sesin, la base de datos puede almacenar datos de
forma persistente e independiente de posibles reinicios en el servidor.

5.4. Gestin del estado en la prctica

Aunque algunos de los mecanismos que hemos descrito en el punto anterior
son usados de forma implcita por ASP.NET para implementar algunas de sus
funcionalidades bsicas, dichos mecanismos tambin pueden usarse por el
desarrollador para almacenar datos de estado si es necesario. A continuacin
veremos algunos sencillos ejemplos de cmo usar los mecanismos ms co-
munes para ello. Antes, sin embargo, la siguiente tabla resume brevemente
las caractersticas de dichos mecanismos:

Mecanismo mbito Ventajas Desventajas
ViewState A lo largo de
un round
trip.
Independiente de la
configuracin del servi-
dor.
Slo funciona si el mtodo
de envo es POST.

El estado se enva y devuelve
con cada solicitud.
Cookie Por cliente. Independiente de la
configuracin del servi-
dor.

El estado se almacena en
el cliente.

Los datos permanecen
ms all de la sesin.
El estado se enva 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 asociacin
de los datos con el cliente.
Application Global a la
aplicacin.
El estado se comparte
entre todos los navegado-
res.
Abusar puede limitar la esca-
labilidad.

No puede compartirse en una
granja de servidores.

5.4.1. Uso del ViewState

ASP.NET proporciona la nocin de estado de la presentacin 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 cmo 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 ejecucin de la aplicacin.
En cada round trip provocado por el clic en un botn, se consulta el valor
del ndice para saber qu Panel no debe visualizarse, y se actualiza el ndice
// Aadimos 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: ejecucin.

para saber qu Panel se va a visualizar a continuacin. Como los valores de los
objetos de diccionario son de tipo string debe usarse conversin de tipos
para almacenar valores de otros tipos, como el ndice entero del ejemplo.

<html>
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 ) {
ViewState["PanelIndex"] = (int)ViewState["PanelIndex"] - 1;
String PrevPanelId = "Panel" + ViewState["PanelIndex"].ToString();

p.Visible=false;
p = (Panel)FindControl(PrevPanelId);
p.Visible=true;
}

void Finish_Click(Object Src, EventArgs E ) {
p.Visible=false;

MyLabel.Text += "<b>Hemos recibido la siguiente informacin: </b><p>";
MyLabel.Text += "Nombre: " + FirstName.Value + "<br>";
MyLabel.Text += "Apellido: " + LastName.Value + "<br>";
MyLabel.Text += "Direccin: " + Address.Value + "<br>";
MyLabel.Text += "Ciudad: " + City.Value + "<br>";
MyLabel.Text += "Cdigo postal: " + Zip.Value + "<br>";
}
</script>
<body>
<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>Direccin: <INPUT id="Address" type="text" size="45" runat="server"></P>
<P>Ciudad: <INPUT id="City" type="text" size="45" runat="server"></P>
<P>Cdigo postal: <INPUT id="Zip" type="text" size="45" runat="server"></P>
<P><INPUT id="Submit2" type="submit" value=" << Atrs " 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 mtodos 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 sesin como al estado entre sesiones.

En el ejemplo de la Figura 62, cuando se almacenan los datos en el cliente, el
mtodo 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 pginas. La Figura 61 muestra diversos momentos de la ejecucin de la
aplicacin correspondientes a una misma sesin.

El comportamiento del ejemplo puede comprobarse abriendo la pgina Ejem-
plo.aspx y modificando las preferencias. Si abrimos la misma pgina en otra
ventana del navegador, esta ventana debe reflejar las nuevas preferencias. Si
se cierran todas las ventanas del navegador y se abre de nuevo la pgina
Ejemplo.aspx, la cookie temporal debera eliminarse y con ella deberan restau-
rarse las preferencias por defecto.

Figura 61. Ejemplo de uso de cookies para almacenar valores de estado: ejecucin.


<html>
void Page_Load(Object sender, EventArgs E) {
if (Request.Cookies["prefs"] == null) {
HttpCookie cookie = new HttpCookie("prefs");
cookie.Values.Add("BackColor","beige");
Response.AppendCookie(cookie);
}
}

protected String GetBC() {
HttpCookie cookie = Request.Cookies["prefs"];
if (cookie != null) return cookie.Values["BackColor"];
return "";
}
</script>
<body style="background-color:<%=GetBC()%>">
<b><a href="customize.aspx">Personalizar la pgina</a></b>
<p>Texto de ejemplo<br>
</body>
</html>

Archivo customize.aspx
<html>
if (!IsPostBack) {
ViewState["Referer"] = Request.Headers["Referer"];
if (cookie != null) BackColor.Value = (String)cookie.Values["BackColor"];
}
}

void Submit_Click(Object sender, EventArgs E) {
HttpCookie cookie = new HttpCookie("prefs");
cookie.Values.Add("BackColor",BackColor.Value);
Response.AppendCookie(cookie);
if ( ViewState["Referer"] != null ) Response.Redirect(ViewState["Referer"].ToString());
}

void Cancel_Click(Object sender, EventArgs E) {
}

if (cookie != null) return cookie.Values["BackColor"];
return "";
}
</script>

<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"/>
</form>
</body>
</html>

Figura 62. Ejemplo de uso de cookies para almacenar valores de estado.

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 bastara aadir el siguiente fragmento de cdigo en el mtodo Sub-
mit_Click() de la pgina 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-
macin global, su uso indiscriminado puede limitar severamente la escalabi-
lidad de una aplicacin, especialmente si se emplea para almacenar datos
que la aplicacin deba actualizar.

La Figura 63 muestra un ejemplo tpico de uso del estado a nivel de aplica-
cin. Tan pronto como se pone en marcha la aplicacin, el mtodo Applica-
tion_Start() de atencin al evento correspondiente, carga ciertos datos de una
base de datos y los almacena en un DataSet. Los subsiguientes accesos a la
aplicacin no necesitarn cargar los datos nuevamente desde la base de da-
tos, sino que accedern a ellos mediante el objeto Application, consultado en el
ejemplo desde el mtodo Page_Load().

El objeto Application est provisto de un mecanismo de acceso concurrente
segn el cual pueden realizarse mltiples lecturas simultneas pero slo es
posible realizar una escritura cada vez. Este mecanismo, a diferencia de lo
que suceda en ASP, lo gestiona automticamente ASP.NET otorgando permi-
sos de lectura o escritura para aadir elementos, de forma conveniente. En
// Carga de los datos en el mtodo Application_Start() definido en global.asax
void 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 pginas de la aplicacin que necesiten los datos del DataSet
private void Page_Load(object src, EventArgs e)
{
DataSet ds = (DataSet)(Application["FuenteDeDatos "]);
// Por ejemplo para visualizar en un DataGrid los datos precargados
MyDataGrid.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-
cin 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 explcita es necesario invocar a los mtodos Lock() y Un-
Lock() de Application, para bloquear y desbloquear el acceso al objeto respecti-
vamente. La Figura 64 muestra un ejemplo de esta situacin en el que, cada
vez que se accede a la pgina, 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 nmero de accesos realizados con cada navegador particular.
Seguidamente se muestran las estadsticas hasta el momento.

5.4.4. Uso del objeto Session

El ejemplo de la Figura 65 ilustra el uso del estado de una sesin para alma-
cenar preferencias de usuario voltiles, de forma similar a lo que se mostr
en el ejemplo de la Figura 62 mediante cookies. En este caso, sin embargo, se
emplea el objeto Session y el evento de inicio de sesin para asignar el valor
por defecto al fondo de las pginas en el mtodo Session_Start(), que aqu defi-
nimos en el archivo Global.asax. Por otra parte, en la pgina de personaliza-
cin (customize.aspx), se modifica el valor de la preferencia del usuario en el
mtodo Submit_Click() con la informacin seleccionada por el usuario.

Para comprobar que el valor seleccionado se almacena realmente con mbito
de sesin, es preciso abrir dos veces la pgina 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 comn.

Una condicin de carrera
consiste es una situacin en
un sistema segn la cul su
respuesta depende del orden
en el que sucedan ciertos
eventos, lo que constituye un
potencial error en dicha
respuesta. El trmino provine
de la electrnica, con la idea
de dos seales elctricas
compitiendo por llegar antes
al final de un camino conduc-
tor y as influenciar en al
respuesta antes que la otra
seal.
<script runat='server'>
private void Page_Load(object sender, System.EventArgs e)
{
// Bloqueo del objeto Application
Application.Lock();

// Actualizamos un valor del objeto Application
if (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 Application
for (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 sincronizacin para el objeto Application.


Es posible configurar las caractersticas del estado de una sesin en la seccin
<sessionState> de un archivo web.config (ver apartado Configuracin de la apli-
cacin). Por ejemplo, para doblar el tiempo de espera de inactividad de la
sesin, predeterminado a 20 minutos, se puede agregar el cdigo siguiente al
archivo web.config:
<html>
return Session["BackColor"].ToString();
}
</script>
<b><a href="customize.aspx">Personalizar la pgina</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;
}

void Cancel_Click(Object sender, EventArgs E) {
}

return Session["BackColor"].ToString();
}
</script>
<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"/>
</form>
</body>
</html>

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 sesin en el
mismo proceso que atiende la solicitud. Si no hay cookies disponibles, se
puede hacer un seguimiento de una sesin agregando un identificador de
sesin a la direccin URL. Esto puede habilitarse de la manera siguiente:

5.4.5. Buenas prcticas

A continuacin se resumen algunas buenas prcticas aplicables a la gestin
del estado de una aplicacin, en cualquiera de las vertientes comentadas a
los largo de los apartados anteriores:

Utilizaremos variables de estado de la aplicacin 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 aplicacin.

Utilizaremos variables de estado de la sesin para almacenar datos espec-
ficos de una sesin o de un usuario. Los datos se almacenan completa-
mente en el servidor. Utilizaremos estas variables para datos de corta du-
racin, datos importantes o grandes cantidades de datos.

Almacenaremos pequeas cantidades de datos voltiles en una cookie no
persistente. Los datos se almacenarn en el cliente, se enviarn al servidor
en cada solicitud y caducarn cuando finalice la ejecucin en el cliente.

Almacenaremos pequeas cantidades de datos no voltiles en una cookie
persistente. Los datos se almacenarn en el cliente hasta que caduquen y
se enviarn al servidor en cada solicitud.

Almacenaremos en el estado de la presentacin (ViewState) pequeas can-
tidades de datos especficos de una solicitud. Los datos se envan desde el
servidor al cliente y viceversa.

5.5. Configuracin de la aplicacin

Cualquier servidor de aplicaciones Web debe poseer un sistema de configu-
racin de las aplicaciones que sea potente y flexible. Potente para permitir al
programador parametrizar la aplicacin sin tener que almacenar los valores
<sessionState timeout=40 />

<sessionState cookieless=true />
de configuracin dentro del cdigo, y flexible para que el administrador
pueda modificar dichos valores de forma sencilla. ASP.NET cumple ambos
requisitos, ofreciendo una infraestructura de configuracin jerrquica que
permite definir datos de configuracin extensibles y utilizarlos a lo largo de
una aplicacin Web, un sitio Web o un servidor. Algunos parmetros de
configuracin tpicos en una aplicacin Web incluyen por ejemplo: strings
de conexin a las bases de datos, mensajes de error, parmetros culturales
como el idioma, etc.

Seguidamente se resumen algunas de las caractersticas del sistema de confi-
guracin de ASP.NET:

ASP.NET almacena los valores de configuracin junto con el resto del
contenido de la aplicacin dentro de una nica jerarqua de directorios.
Usuarios y administradores slo necesitan copiar un nico rbol de direc-
torios para instalar una aplicacin ASP.NET en un servidor.

Los datos de configuracin se almacenan en archivos XML accesibles
mediante cualquier editor de texto, analizador XML o lenguaje de script
para interpretar y actualizar la configuracin.

La infraestructura de configuracin es extensible, lo que permite a pro-
gramadores terceros almacenar sus propios valores de configuracin, 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 travs del cual esos valores se exponen a la aplicacin.

ASP.NET detecta automticamente los cambios en los archivos de confi-
guracin y los aplica sin que sea necesario reiniciar el servidor Web para
que surtan efecto.

5.5.1. Archivos de configuracin

Los archivos de configuracin de ASP.NET son archivos XML (cada uno con
el nombre Web.config) que pueden aparecer en cualquier directorio del servi-
dor de aplicaciones. Cada archivo Web.config aplica valores de configuracin
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 configuracin raz
(C:\WINDOWS\Microsoft.NET\Framework\<version>\CONFIG\machine.config) propor-
ciona valores de configuracin predeterminados para todo el servidor. Por
ejemplo, los valores de configuracin para la URL
http://servidor/aplicacion/dir/pagina.aspx se calcularan 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 raz de la aplicacin es totalmente opcional. Si no existe un archivo
Web.config, todos los valores de configuracin para el directorio se heredan
automticamente del directorio principal. Por otra parte, si existe un archivo
Web.config en el directorio raz del sitio, por ejemplo, "inetpub\wwwroot", sus
valores de configuracin se utilizarn para todas las aplicaciones de ese sitio.

Durante la ejecucin, ASP.NET utiliza los archivos de configuracin para
calcular jerrquicamente los valores de configuracin para cada solicitud de
una URL determinada. Dichos valores se calculan slo una vez y despus se
guardan en cach a lo largo de las solicitudes subsiguientes. ASP.NET moni-
toriza los cambios en los archivos de configuracin 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 pblicos.

5.5.2. Sintaxis de Web.config

Aunque basada en XML, la sintaxis (y la semntica asociada) de los archivos
de configuracin de ASP.NET es materia de estudio en s misma. Puesto que
analizarla en detalle sera tedioso y seguramente poco prctico, hemos prefe-
rido acercarnos a ella a travs del anlisis de un ejemplo de archivo Web.config
que generado por defecto por Visual Studio para cierto proyecto de aplica-
cin Web ASP.NET (ver Figura 66).

Como puede apreciarse, la etiqueta <configuration> slo tiene una etiqueta
anidada (<system.web>) formando un grupo de secciones de configuracin.
Algunas de las secciones de configuracin tpicamente incluidas en un gru-
po son: compilation, customErrors, authentication, authorization, etc. El funcionamien-
to es sencillo: basta detallar las particularidades de la configuracin en la
seccin correspondiente. Por ejemplo, si se quiere usar un modo de autenti-
cacin diferente al indicado, basta indicarlo en la seccin authentication.

Configuracin base del servidor:
C:\WINDOWS\Microsoft.NET\Framework\ v1.1.4322\CONFIG\machine.config

Sobrescrita por la configuracin del sitio (o la aplicacin de la raz de IIS):
C:\inetpub\wwwroot\Web.config

Sobrescrita por la configuracin de la aplicacin:
D:\ aplicacion \Web.config

Sobrescrita por la configuracin del subdirectorio:
D:\aplicacion\dir\Web.config

Al margen de la configuracin estndar de system.web, puede definirse tam-
bin la configuracin especfica de la aplicacin, como los strings de co-
nexin a las bases de datos, mediante la etiqueta <appSettings>. As pues, el
archivo Web.config tendr tpicamente la siguiente estructura:

En el grupo de secciones system.web se especifican opciones que antes de la
aparicin de ASP.NET se especificaban directamente sobre IIS. Si bien este
grupo admite una gran cantidad de etiquetas de configuracin, habitualmen-
te se emplean slo unas pocas, que describimos a continuacin.

<authentication> En esta seccin se indica el tipo de autenticacin a usar para
acceder a la aplicacin. El valor None indica que cualquier usuario puede
acceder a ella, mientras que "Windows", "Forms" o "Passport" indican el tipo de
autenticacin requerida, si es el caso.
<authorization> Permite dar o denegar el acceso a la aplicacin a determinados
usuarios o perfiles. El mdulo de autenticacin de ASP.NET procesa las sec-
ciones de configuracin segn 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 aplicacin 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 compilacin, si
bien las ms empleadas son las opciones de depuracin (true o false) y el len-
guaje de programacin empleado (vb, c#, etc.).

<customErrors> Permite ofrecer a los usuarios pginas de error con mensajes a
medida. En el modo RemoteOnly slo los usuarios remotos vern los citados
mensajes mientras que los usuarios en el propio servidor vern los detallados
y tcnicos mensajes de ASP.NET. En el modo Off todos los usuarios vern 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-
cin del archivo Web.config (e.g. ../error404.html) para redireccionar la aplica-
cin 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 los
nmeros o las fechas.

<httpRuntime> En esta seccin pueden especificarse diversas opciones de tiem-
po de ejecucin de la aplicacin, como por ejemplo appRequestQueueLimit o
executionTimeout. La primera indica el nmero mximo de solicitudes que el
servidor puede atender en momentos de mucho trfico. La segunda indica el
tiempo mximo que el servidor puede dedicar a procesar a una solicitud.

<sessionState> Esta seccin permite indicar dnde se va a almacenar el estado
de la sesin. El lugar por defecto es el propio proceso de ASP.NET.

<trace> El log de seguimiento de la aplicacin se encuentra en el archivo tra-
ce.axd del directorio raz de la aplicacin. En esta seccin puede indicarse la
forma en que se va a mostrar la informacin de dicho archivo. Por ejemplo,
establecer el atributo localOnly a "false" permite acceder a la informacin de
<authorization>
<allow roles="Administrators, Users" />
<deny users="*" />
</authorization>
<httpRuntime appRequestQueueLimit="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 aadir la informacin de
seguimiento al final de cada pgina, 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 aplicacin a las que necesita
acceder desde mltiples pginas. Un ejemplo tpico son los strings de co-
nexin a las bases de datos.

5.5.3. Acceso a la configuracin

Es posible acceder a las opciones de configuracin pblicas desde el cdigo
de una aplicacin ASP.NET mediante los mtodos estticos intrnsecos que
ASP.NET expone. Por ejemplo, para leer el valor del atributo cookieless de la
seccin <sessionState>, puede utilizarse la lnea de cdigo siguiente:

Por otra parte, el acceso a las opciones especficas de la aplicacin almacena-
das en la seccin de nivel superior <appSettings> de los archivos Web.config
puede obtenerse a travs de la coleccin esttica de strings ConfigurationSet-
tings.AppSettings. Por ejemplo:

<trace enabled="true" localOnly="true" pageOutput="false" />
bool nocookies = Session.IsCookieless;
String sqlConnectionString = ConfigurationSettings.AppSettings["sqlConn"];
<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
bsicos de autenticacin y autorizacin de usuarios y perfiles en una aplica-
cin, aspectos ya presentes desde el origen de ASP.NET. A continuacin se
tratan diversos aspectos de seguridad incorporados en ASP.NET 2.0: como el
conjunto de nuevos controles de autenticacin; las herramientas para la
configuracin de la seguridad de un sitio Web, o algunos detalles de la API
de pertenencia para administrar el acceso a las pginas y simplificar el alma-
cenamiento de la informacin de los usuarios.

6.1. Autenticacin y autorizacin

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 autenticacin al acto de determinar la identidad del solicitante. Por lo
general, el usuario deber presentar sus credenciales, como su nombre de
usuario y contrasea, para ser autenticado. Una vez que el usuario ha sido
autenticado, deber determinarse si puede tener acceso a un recurso especfi-
co. Este proceso se conoce como autorizacin.

ASP.NET e IIS colaboran para proporcionar servicios bsicos de autenticacin
y autorizacin a las aplicaciones. Adems, ASP.NET es compatible con el
servicio de autenticacin Microsoft Passport, el cual proporciona servicios
simples de firma y servicios de gestin de perfiles de usuario. ASP.NET tam-
bin proporciona un servicio para aplicaciones que necesitan utilizar auten-
ticacin basada en formularios. La autenticacin basada en formularios utili-
za cookies para autenticar a los usuarios, y permite a la aplicacin realizar su
propia verificacin de credenciales.

Es importante insistir en el hecho de que los servicios de autenticacin de
ASP.NET dependen de los servicios de autenticacin suministrados por IIS.
Por ejemplo, para poder utilizar una autenticacin bsica en una aplicacin,
debe configurarse el uso de la autenticacin bsica para la aplicacin me-
diante el Administrador de servicios de Internet de IIS.

ASP.NET proporciona dos tipos de servicios de autorizacin: comprobaciones
de ACLs para determinar si la cuenta de usuario autenticada tiene o no acce-
so a los recursos; y, autorizacin de URL, la cual autoriza una identidad para
partes del espacio Web.

Microsoft Passport permite
utilizar una direccin de
correo electrnico y una sola
contrasea para iniciar sesin
en cualquier sitio o servicio
Web colaborador de Passport
Network.
Para ilustrar la diferencia considere un escenario en el que una aplicacin
est configurada para permitir acceso annimo mediante la cuenta de usua-
rio IUSR_MIORDENADOR. En el caso de autorizacin va ACL, cuando una solici-
tud de una pgina ASP.NET (como "/default.aspx") recibe autorizacin, se reali-
za una comprobacin 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 automticamente.

Para autorizacin de URL, se comprueba el usuario annimo con los datos de
configuracin obtenidos de los archivos Web.config para la aplicacin (ver
apartado Configuracin de la aplicacin). Si se permite el acceso a la direc-
cin URL solicitada, la solicitud se autoriza. En el ejemplo, ASP.NET com-
prueba si el usuario annimo dispone de acceso a /default.aspx, es decir, la
comprobacin se realiza sobre la propia URL, no sobre el archivo en el que el
servidor Web resuelve la URL en ltima instancia.

sta puede parecer una diferencia sutil, pero permite a las aplicaciones utili-
zar esquemas de autenticacin como los basados en formularios o la autenti-
cacin de Microsoft Passport, en los cuales los usuarios no se corresponden
con un equipo o una cuenta de dominio concretos. Tambin permite la au-
torizacin de recursos virtuales, para los cuales no existe un archivo fsico
subyacente al recurso. Por ejemplo, una aplicacin podra optar por asignar
todas las solicitudes de archivos que terminan en .stk a un controlador que
proporciona cotizaciones de valores segn 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 utilizara la autorizacin de URL para
controlar el acceso al recurso virtual.

La autorizacin de archivo se realiza siempre con la cuenta autenticada su-
ministrada por IIS. Si se permite el acceso annimo, esta cuenta es la cuenta
annima configurada. Las listas ACL de archivos se configuran para un de-
terminado archivo o directorio mediante la ficha Seguridad de la pgina de
propiedades del Explorador. La autorizacin de URL se configura como parte
de una aplicacin ASP.NET Framework (ver apartado Autorizacin).

Como hemos visto anteriormente, para activar un servicio de autenticacin
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 ningn servicio de autenticacin de
ASP.NET, aunque los servicios de autenticacin de IIS pueden estar an pre-
sentes; Windows, para dejar que sea el sistema operativo del servidor quien
realice la autenticacin; Forms, de forma que los servicios de autenticacin
de ASP.NET administran las cookies y desvan a los usuarios no autenticados
a una pgina de inicio de sesin; y Passport, de manera que los servicios de
El mecanismo de ACL (Access
Control List) permite deter-
minar los permisos de acceso
a un objeto del sistema de-
pendiendo de aspectos preci-
sos del proceso que hace la
solicitud.
autenticacin 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. Autenticacin basada en Windows

Cuando se utiliza la autenticacin basada en Windows, ASP.NET asocia un
objeto de la clase WindowsPrincipal a la solicitud en curso, de forma que la auto-
rizacin de direccin URL utiliza dicho objeto para las comprobaciones. Por
otra parte, la aplicacin tambin puede utilizar dicho objeto programtica-
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 aplicacin desea gestionar sus propios perfiles de
usuario puede hacerlo mediante el control del evento WindowsAuthentica-
tion_OnAuthenticate en su archivo Global.asax y la asociacin 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 cmo obtener acceso al nombre de un
usuario ya autenticado. Como se observa, ste est disponible como
User.Identity.Name. La Figura 69 muestra la pgina en ejecucin.

6.1.2. Autenticacin basada en formularios

El servicio de autenticacin basada en formularios de ASP.NET permite a las
aplicaciones ofrecer su propia interfaz de inicio de sesin y hacer su propia
verificacin de credenciales. ASP.NET permite autenticar usuarios y desviar a
los usuarios no autenticados hacia la pgina de inicio de sesin, adems de
realizar todas las tareas de administracin de cookies.

If (User.IsInRole("Administrators")) {
CodigoAEjecutar();
}
// Creacin de una clase que implemente IPrincipal
public class MiPrincipal : IPrincipal {
// Implementa los perfiles propios de la aplicacin
}

// 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 autenticacin, se usa la identidad que IIS proporciona
e.User = new MiPrincipal(e.Identity);
}
Figura 67. Derivando de IPrincipal.

Para que una aplicacin pueda utilizar autenticacin basada en formularios,
se debe configurar el elemento <authentication> del archivo Web.config con la
opcin Forms y denegar el acceso a los usuarios annimos:

El administrador de la aplicacin puede usar este tipo de autenticacin para
configurar el nombre de la cookie a usar, el tipo de proteccin, la URL de la
pgina de inicio de sesin, el tiempo de validez de la cookie y la ruta de acce-
so a la cookie suministrada. La siguiente tabla muestra los atributos vlidos
para el elemento <Forms>, que es un subelemento del elemento <authentication>:

<html>
<body>
<table Width="600" rules="all" bordercolor="Black">
<tr>
<td>Usuario:</td> <td><asp:label id=AuthUser runat=server/>
</tr>
<tr>
<td>Tipo de autenticacin:</td> <td><asp:label id=AuthType runat=server/>
</tr>
</table>
</body>
</html>

En el archivo Ejemplo.aspx.cs
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 autenticacin basada en Windows.
<configuration>
<system.web>
<authentication mode="Forms"/>
<authorization> <deny users="?" /> </authorization>
</system.web>
</configuration>

Figura 69. Ejemplo de uso de la autenticacin basada en Windows: ejecucin.


Atributo Descripcin
loginUrl URL (local o remota) de inicio de sesin a la que se desvan los
usuarios no autenticados.
name Nombre de la cookie que se va a usar para la autenticacin. Si
varias aplicaciones van a usar autenticacin basada en formularios
en un mismo servidor, cada aplicacin deber configurar una
cookie 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 Mtodo utilizado para proteger los datos de las cookies:

All: Utiliza validacin y cifrado de datos para proteger la cookie. Si
est disponible se usa TripleDES. Opcin predeterminada.

None: Se usa con sitios que utilizan cookies slo para personaliza-
cin y que tienen requisitos de seguridad menores.

Encryption: Permite cifrar la cookie mediante DES o TripleDES, pero
no se realiza validacin de datos. Este tipo de cookie puede sufrir
ataques en lo que se refiere a la seleccin de texto sin formato.

Validation: La cookie no est cifrada, pero se valida para comprobar
que no ha sido modificada durante la transmisin.

Una vez configurada la aplicacin debe proporcionarse una pgina de inicio
de sesin. Cuando se ejecuta el ejemplo de la Figura 70 se solicita la pgina
Default.aspx. Las solicitudes no autenticadas se desvan a la pgina de inicio de
sesin Login.aspx, la cual presenta un formulario sencillo que pide una direc-
cin de correo electrnico (master@uoc.edu) y una contrasea (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 pginas durante la ejecucin.

Las cookies de autenticacin pueden ser temporales o permanentes. Las coo-
kies temporales tienen la duracin de la sesin 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 mtodo de cifra-
do de informacin diseado
por IBM en 1975. Considera-
do inseguro por fuerza bruta
desde 1994, ha sido substi-
tuido mayoritariamente por
TripleDES, la aplicacin con-
secutiva de tres cifrados de
tipo 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>
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 sesin" OnClick="Signout_Click" runat="server" id="Button1" />
</form>
</body>
</html>

En el archivo Default.aspx.cs
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) {
// Autenticacin del usuario "master@uoc.edu"-"pwd"
if ((UserEmail.Value == "master@uoc.edu") && (UserPass.Value == "pwd"))
FormsAuthentication.RedirectFromLoginPage(UserEmail.Value, false);
else
Msg.Text = "Credenciales no vlidas, intntelo de nuevo";
}
</script>
<body>
<h3>Inicio de sesin</h3>
<table>
<tr>
<td>Direccin 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>Contrasea:</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 sesin" 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 autenticacin basada en formularios.

6.1.3. Autorizacin

Como ya se ha visto en el apartado Configuracin de la aplicacin,
ASP.NET puede configurarse mediante Web.config para controlar el acceso de
los clientes a determinadas URL. Esto puede hacerse selectivamente para
cada mtodo HTTP que se utilice en la solicitud (GET o POST) y, tambin, 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 marcoa@uoc.edu y Juan, a todos los usuarios que pertenez-
can al perfil Admins y a cualquier usuario autenticado (*) que acceda me-
diante mtodo GET. El mismo fragmento tambin deniega el acceso (directiva
deny) al resto de usuarios sean annimos (?) o no (*).


Figura 71. Ejemplo de uso de la autenticacin basada en formularios: ejecucin.


Los nombres de usuario especiales (? y *) se utilizan comnmente en
aplicaciones que usan autenticacin 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 aplicacin se configure de forma contra-
ria (y suponiendo que el usuario reciba autenticacin y pase la comproba-
cin de ACL para el acceso a los archivos), el acceso se concede.

6.2. Seguridad y el modelo de proveedores

Una de las caractersticas de la seguridad en ASP.NET 2.0 es su simplicidad de
uso, derivada de la adopcin 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 informacin
de una base de datos inmediatamente despus de habilitar la autenticacin
por formularios, sin necesidad de generar tablas de base de datos ni de escri-
bir ningn cdigo.

El modelo de proveedores proporciona un mtodo estndar para conectar los
componentes encargados de implementar los distintos servicios de una apli-
cacin. 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 contraseas, 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-
traseas en una base de datos de Microsoft Access. Esta base de datos se crea
automticamente en la carpeta Data de la aplicacin. Es ms, si la base de
datos de Access se eliminase accidentalmente, se volvera a crear automti-
camente la prxima vez que se intentara la conexin a la base de datos. Si se
desea almacenar informacin de pertenencia a grupo en una base de datos
de Microsoft SQL Server, se puede configurar la aplicacin para que utilice el
proveedor SqlMembershipProvider sin necesidad de volver a escribir el cdigo de
la aplicacin.
<authorization>
<allow users="marco@uoc.edu, Juan "/>
<allow roles="Admins" />
<allow VERB="GET" users="*" />
<deny users="? />
<deny users="*" />
</authorization>
Tambin se puede crear un proveedor de pertenencia a grupo personalizado.
Por ejemplo, se podra desear almacenar la informacin 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-
formacin mediante un servicio Web. Si la intencin es crear un proveedor
de pertenencia a grupo propio, se debern implementar todos los mtodos 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 aplicacin Web destinada a un grupo reducido de usuarios. Si se
precisa crear una aplicacin ms robusta lo recomendable es almacenar los
nombres de usuario y las contraseas en una base de datos escalable como
Microsoft SQL Server.

Para almacenar la informacin 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 aplicacin. Una posibilidad es usar la configura-
cin de la aplicacin. 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 administracin de sitios Web (ver apartado
Herramienta de configuracin 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 especificacin
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 automticamente ejecutando la herramienta aspnet_regsql desde
la lnea 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. Despus de crear la nueva base de datos, ser necesario compro-
bar que la aplicacin 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 caso
de 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" />
</system.web>
</configuration>

6.2.2. Configuracin del proveedor de pertenencia a grupo

Pueden emplearse los atributos del proveedor de pertenencia a grupo para
controlar la forma en la que la informacin de pertenencia a grupo se alma-
cena y recupera de la base de datos. Los valores de los atributos se pueden

Figura 73. Configuracin de SqlMembershipProvider con aspnet_regsql.

Figura 72. Configuracin de proveedores en IIS.

modificar en el archivo Web.config. Tanto AccessMembershipProvider como
SqlMembershipProvider admiten varios atributos de proveedor especficos:

Atributo Descripcin
applicationName Si se precisa alojar varias aplicaciones en el mismo
servidor Web, se puede utilizar esta propiedad para
aislar a los usuarios asociados con las distintas aplica-
ciones.
connectionStringName
Nombre de la cadena de conexin a la base de datos
definida en la seccin connectionStrings del archivo
Web.config.
description Descripcin de la definicin del proveedor.
enablePasswordReset Si vale true, los usuarios pueden restablecer sus con-
traseas y utilizar una generada de forma aleatoria.
enablePasswordRetrieval Si vale true, las contraseas de los usuarios se pueden
recuperar del proveedor de pertenencia a grupo.
passwordFormat
Tiene tres valores posibles: Clear, Encrypted y Hashed. Si
las contraseas tienen el valor hashed, las contraseas
originales no se pueden recuperar del proveedor de
pertenencia a grupo.
requiresQuestionAndAns-
wer
Si vale true, el usuario debe responder a una pregunta
para poder restablecer o recuperar su contrasea.
requiresUniqueEmail Si vale true, se debe asociar una direccin de correo
electrnico exclusiva con cada usuario.

Por ejemplo, el atributo passwordFormat determina cmo se almacenan las
contraseas en la base de datos: como texto sin cifrar (Clear), cifradas (Encryp-
ted) o valores hash de contraseas (Hashed). La ltima opcin es la ms segura
ya que permite almacenar valores hash en la base de datos en lugar de las
contraseas reales. As si la seguridad de la aplicacin resulta comprometida,
un usuario malintencionado no podr robar las contraseas autnticas.

6.3. Herramienta de configuracin de la seguridad

La herramienta de administracin de sitios Web que incluye ASP.NET 2.0
permite configurar una aplicacin 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
pginas de una aplicacin Web.

La interfaz de administracin Web es accesible de diversas formas. Si se desea
crear una aplicacin Web con Visual Studio, se puede abrir la herramienta
seleccionando ASP.NET Configuration en el men Website. Si lo que se
desea es desarrollar una aplicacin Web fuera de Visual Studio, se puede
tener acceso a la herramienta directamente solicitando la pgina especial
WebAdmin.axd. Por ejemplo, si la aplicacin se encuentra en un directorio
virtual llamado MiAppWeb en el equipo local, se puede abrir la herramienta de
administracin de sitios Web para la aplicacin especificando la URL
http://localhost/MiAppWeb/WebAdmin.axd en el navegador.

La herramienta se compone de una serie de pginas ASP.NET que utilizan los
controles de Login estndard (ver siguiente apartado). Estas pginas se ubican
en la carpeta inetpub\wwwroot\aspnet_webadmin. Si por cualquier motivo los
archivos se eliminaran accidentalmente del servidor, podran reinstalarse
automticamente ejecutando la herramienta aspnet_regiis. aspnet_regiis tambin
puede usarse para controlar el acceso a la herramienta de administracin de
sitios Web, por ejemplo restringiendo el acceso slo 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 pginas estndar de registro, de inicio de sesin y de
recuperacin de contraseas sin necesidad de escribir cdigo. Tambin se
emplean para mostrar informacin diferente a los usuarios dependiendo de
sus roles y de su estado de autenticacin. Por ejemplo, el control LoginView
podra usarse para mostrar una informacin 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 modelo
de proveedores. As, si se ha configurado la aplicacin para que utilice Ac-
cessMembershipProvider, los controles de Login realizarn automticamente una
Controles de login en Visual
Studio 2005

Figura 74. Herramienta de administracin de sitios Web.

consulta a la base de datos de Access para recuperar la informacin de la
pertenencia a grupo. Si se habilita SqlMembershipProvider, los controles utili-
zarn 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 autenticacin por formularios
para la aplicacin. Esto puede hacerse tanto desde el archivo Web.config como
desde la herramienta de administracin de sitios Web vista anteriormente.

6.4.1. Control Login

El control Login permite crear una pgina estndar de inicio de sesin agre-
gando una simple etiqueta a una pgina. Por ejemplo:

El control Login genera automticamente una interfaz de inicio de sesin
estndar (ver Figura 75) compuesta por cuadros de texto de nombre de usua-
rio y contrasea, una casilla de verificacin para recordar al usuario la
prxima vez que inicie sesin y un botn para enviar la informacin. Al
enviar el nombre de usuario y la contrasea, el proveedor de pertenencia a
grupo valida las credenciales automticamente.

La lista de propiedades del control Login es muy amplia. La mayora permiten
personalizar la interfaz, pero adems se pueden configurar propiedades como
CreateUserUrl y PasswordRecoveryUrl para crear vnculos a una pgina de registro y
una pgina de recuperacin de contraseas, respectivamente. Otra propiedad
muy utilizada es VisibleWhenLoggedIn, que permite ocultar automticamente el
control Login cuando el usuario ya se ha autenticado. Por ejemplo, si se desea
incluir el control Login en cada pgina de la aplicacin, con la propiedad
VisibleWhenLoggedIn se podr ocultar automticamente el control en cuento el
usuario se haya autenticado.

6.4.2. Control CreateUserWizard

CreateUserWizard permite crear una pgina estndard de registro de usuarios en
la aplicacin agregando una etiqueta tan simple como:
<asp:Login ID="Login1" Runat="server" />

Figura 75. Control Login en tiempo de diseo.


La apariencia exacta del control depender de la configuracin del proveedor
de pertenencia a grupo de la aplicacin. Por ejemplo, los cuadros de texto de
la pregunta y la respuesta para recuperar la contrasea slo 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 ms interesantes que permite hacer el control CreateUserWi-
zard es enviar automticamente un mensaje de correo electrnico de registro
despus 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 contrasea. Tambin se puede configurar el mensaje enviado mediante la
propiedad MailDefinition del control. El siguiente fragmento de cdigo, por
ejemplo, har que el control CreateUserWizard envie el contenido del archivo
EmailDeRegistro.txt como cuerpo del mensaje de correo electrnico de registro
siempre que alguien complete el asistente de registro (CreateUserWizard emplea
el servidor de correo electrnico especificado en la seccin <smtpMail> de
Web.config):

Dentro del archivo EmailDeRegistro.txt pueden emplearse expresiones especiales,
como <% UserName %> y <% Password %>, para sustituir el nombre de usuario y
la contrasea del nuevo usuario registrado.

Figura 76. Control CreateUserWizard en tiempo de diseo.

<asp:CreateUserWizard ID="CreateUserWizard1" Runat="server" />
<asp:CreateUserWizard ID="CreateUserWizard1" Runat="server">
<MailDefinition
BodyFileName="EmailDeRegistro.txt"
From="YourSite@YourDomain.com"
Subject="Gracias por registrarte!">
</MailDefinition>
</asp:CreateUserWizard>
La funcionalidad de correo electrnico del control CreateUserWizard tambin
puede usarse para implementar procedimientos de registro ms complicados,
como aquellos en los que es preciso validar la direccin de correo electrnico
del usuario antes de permitirle el acceso a la aplicacin Web. Si se habilita la
propiedad AutoGeneratePassword del control CreateUserWizard, el control generar
de forma aleatoria una contrasea para el usuario, que puede envirsele me-
diante la funcionalidad de correo electrnico. Si el usuario posteriormente la
utiliza para autenticarse en la aplicacin, se confirmar que el usuario ha
facilitado una direccin de correo electrnico vlida.

6.4.3. Control PasswordRecovery

El control PasswordRecovery permite que los usuarios de la aplicacin puedan
solicitar un mensaje de correo electrnico de recordatorio de su contrasea
(ver Figura 77). Al igual que en el control CreateUserWizard, las propiedades del
mensaje de correo electrnico enviado al usuario se definen mediante la
propiedad MailDefinition. Por ejemplo, la etiqueta siguiente agrega un control
PasswordRecovery a una pgina Web que enva un mensaje de correo electrni-
co desde la cuenta de correo electrnico YourSite@YourDomain.com:

El control PasswordRecovery se comporta de forma distinta dependiendo de la
configuracin del proveedor de pertenencia a grupo predeterminado. Si el
atributo enablePasswordRetrieval es true y el atributo passwordFormat no es Hashed, se
enva la contrasea de texto sin cifrar en el mensaje de correo electrnico.
En cualquier otra combinacin de valores de atributos, la contrasea se res-
tablece en una secuencia aleatoria de caracteres que se enva al usuario.

6.4.4. Control ChangePassword

El control ChangePassword permite a los usuarios cambiar sus contraseas. El
control crea cuadros de texto en los que se puede facilitar la contrasea ori-
ginal y la nueva (ver Figura 78).

Figura 77. Control PasswordRecovery en tiempo de diseo.

<asp:PasswordRecovery ID="PasswordRecovery1" Runat="server">
<MailDefinition
Subject="Recordatorio de contrasea">
</MailDefinition>
</asp:PasswordRecovery>

Al igual que los controles CreateUserWizard y PasswordRecovery, ChangePassword
tambin incluye una propiedad MailDefinition. Cuando se asignan valores a la
propiedad MailDefinition, el control ChangePassword enva automticamente un
mensaje de correo electrnico al usuario cuando se cambia correctamente
una contrasea. 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 electrnico que se enva al usuario. En el
archivo se pueden utilizar expresiones especiales como <% UserName %> y <%
Password %> para mostrar el nombre de usuario y la contrasea.

6.4.5. Controles LoginName y LoginStatus

Los controles LoginName y LoginStatus permiten mostrar informacin sobre el
estado actual de la autenticacin de un usuario. Despus de que un usuario
ha iniciado sesin en la aplicacin, el control LoginName muestra su nombre
de usuario registrado. Si no se emplea autenticacin por formularios el con-
trol LoginName no muestra nada. Puede declararse un control LoginName de la
siguiente manera:

Por su parte, LoginStatus permite que el usuario inicie o cierre sesin en la
aplicacin. El control muestra uno de dos vnculos: si el usuario no se ha
autenticado, se muestra un vnculo a la pgina Login.aspx; si ya se ha autenti-
cado, se muestra un vnculo que le permite cerrar sesin. El control LoginStatus
se declara simplemente como:

Figura 78. Control ChangePassword en tiempo de diseo.

<asp:ChangePassword ID="ChangePassword1" Runat="server">
<MailDefinition
BodyFileName="~/EmailCambioPassword.txt"
Subject="Tu contrasea 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 informacin
distinta en su pgina principal en funcin de si el usuario es nuevo o ya est
registrado. Los nuevos usuarios pueden ver una descripcin general del sitio
Web, mientras que los ya registrados pueden ver la informacin que se ha
creado especficamente para ellos.

El siguiente cdigo muestra cmo se puede utilizar LoginView para mostrar
contenido distinto a un usuario annimo y a un usuario autenticado. El
usuario annimo 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 aplicacin Web, puede
usarse LoginView para mostrar contenido especfico a miembros de determina-
do rol. El siguiente cdigo muestra un ejemplo en el que cierto contenido
slo es visible a los miembros del rol Administrators:

As, los miembros del rol Administrators podrn 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. Slo
es posible ver el contenido de una plantilla en un momento determinado,
incluso cuando ms de una aplica al usuario en cuestin.

<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 podras 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 podras estar disfrutando de grandes contenidos!
</AnonymousTemplate>
</asp:LoginView>

6.5. API de pertenencia a grupo

Aunque los controles de Login y la herramienta de administracin 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 mtodos para la creacin de usuarios, la gestin de contraseas,
etc. Dichos mtodos 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 mtodos ms
relevantes de la clase Membership:

Mtodo Descripcin
CreateUser Permite crear nuevos usuarios.
DeleteUser Permite eliminar usuarios existentes.
FindUsersByEmail Permite recuperar una coleccin de usuarios que coin-
ciden con cierta direccin de correo electrnico.
FindUsersByName Permite recuperar una coleccin de usuarios que coin-
ciden con cierto nombre de usuario.
GeneratePassword Permite generar una contrasea aleatoria.
GetAllUsers Permite recuperar todos los usuarios almacenados en
el proveedor de pertenencia a grupo.
GetNumberOfUsersOnli-
ne
Devuelve el nmero de usuarios que han obtenido
acceso en un momento concreto a la aplicacin.
GetUser Permite recuperar la informacin de pertenencia a
grupo asociada con el usuario actual o con un usuario
que utiliza un nombre de usuario dado.
GetUsernameByEmail Permite recuperar el nombre del usuario que tiene
cierta direccin de correo electrnico.
UpdateUser Permite actualizar la informacin 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 contrasea 12345
de la siguiente forma:

Varios de los mtodos de la tabla anterior, como GetAllUsers y FindUsersByName,
devuelven colecciones de objetos de la clase MembershipUser. Dicha clase re-
presenta informacin sobre un usuario concreto y contiene las siguientes
propiedades y mtodos:

Membership.CreateUser( "Pedro", "12345" );

Propiedad Descripcin
Comment
Comentario asociado al usuario.
CreationDate
Fecha en la que se cre el usuario.
Email
Direccin de correo electrnico del usuario.
IsApproved
Indica si se ha aprobado o no al usuario.
IsOnline
Indica si el usuario est accediendo o no a la
aplicacin en un momento determinado.
LastActivityDate
Fecha del ltimo acceso del usuario a la apli-
cacin.
LastLoginDate
Fecha en la que se autentic por ltima vez al
usuario.
LastPasswordChangedDate
Fecha en la que se cambi por ltima vez la
contrasea de usuario.
PasswordQuestion
Pregunta y respuesta para recuperar la contra-
sea.
Provider
Proveedor de pertenencia a grupo.
Username
Nombre del usuario.
Mtodo Descripcin
ChangePassword
Permite cambiar la contrasea del usuario.
ChangePasswordQuestionAndAns-
wer
Permite cambiar la pregunta y la respuesta
para recuperar la contrasea.
GetPassword
Permite recuperar la contrasea del usuario.
ResetPassword
Permite restablecer la contrasea del usuario.

7. Diseo de la interfaz de usuario
Este apartado se centra en algunos de los aspectos ms relevantes desde el
punto de vista del diseo de interfaces de usuario, tanto a nivel de una pgi-
na, como a nivel de un sitio Web completo. Se empieza con la creacin de
controles de usuario y a continuacin se cubren aspectos como las pginas
maestras, los temas visuales y las Web Parts. Esto ltimos aspectos corres-
ponden a mecanismos incorporados con la versin 2.0 de ASP.NET.

7.1. Controles personalizados

Como se puede ver en el Apndice Controles Web Forms: Referencia,
ASP.NET proporciona un amplio conjunto de controles para construir la
interfaz de usuario de una aplicacin. Al margen de dichos controles, la ma-
yora accesibles directamente desde la caja de herramientas de Visual Studio,
tambin es posible usar controles de terceros. Sin embargo, lo que resulta
ms interesante es la posibilidad de desarrollar controles Web propios, para
posteriormente usarlos en la construccin de interfaces ASP.NET, reutilizar
cdigo de forma inteligente y conseguir aplicaciones mejor estructuradas.
Una posible clasificacin de los distintos tipos de controles Web personaliza-
dos podra ser la siguiente:

Controles de usuario o pagelets. No pueden considerarse controles
ASP.NET propiamente. Se trata de fragmentos de cdigo 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
pgina, 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 cdigo HTML que, almacenado en un archi-
vo, puede reutilizarse como un componente en diversas pginas Web.
Adems, el contenido del componente puede personalizarse para cada pgi-
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 tcnicas de programacin que en la cons-
truccin de cualquier formulario Web de ASP.NET.

Un pagelet se almacena en un archivo con extensin .ascx, lo cual lo identifi-
ca como un control de ASP.NET y, al mismo tiempo, impide que el control
pueda ejecutarse como una pgina Web independiente. El siguiente cdigo
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 pgina 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 cdigo
del pagelet. Si en lugar de un archivo .ascx con cdigo HTML se tratase de un
control almacenado en un ensamblado de .NET, se substituira el parmetro
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 pgina mediante la notacin prefijo:nombre, de la misma forma
que los controles de servidor propios de ASP.NET. As como para insertar un
botn se introduce una marca asp:button, del mismo modo puede introducirse
una marca UOC:copyright en cualquier pgina donde se haya efectuado el re-
gistro para insertar el pagelet anterior, incluido el atributo runat=server:

Aunque la posibilidad de reutilizar en una pgina porciones de cdigo 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 cdigo de script al contenido HTML, declaran-
do un conjunto de variables (con valores por defecto, si se desea), propieda-
des y mtodos pblicos, que se convierten automticamente en variables,
propiedades y mtodos pblicos del control. As pues, podrn 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 direccin postal al usuario. El cdigo declara el string pblico
Titulo al que se le puede asignar un valor o consultarlo tanto declarativa como
programticamente. Tambin se declaran propiedades para exponer algunas
propiedades de los TextBox que forman el control. El control resultante hereda
<%@ Register TagPrefix="UOC" TagName="Direccion" Src="direccion.ascx" %>
<html>
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>
<UOC:Direccion id="DirEnvio" runat="server" Titulo="Direccin de envo"
Direccion="Av. Tibidabo, 45-47" Ciudad="Barcelona" CodPostal="08035" />
<p>
<UOC:Direccion id="DirFactura" Titulo="Direccin de facturacin" 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
public String Titulo = "Direccin";

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> Direccin: </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> Cdigo postal: </td>
<td> <input id="TxtCodPostal" size="5" type="text" runat="server"> </td>
</tr>
</table>
Figura 79. Ejemplo de pagelet con propiedades.
automticamente la capacidad de gestionar el estado de los TextBox que lo
componen. La pgina contiene dos instancias del nuevo control, con Titulo
diferente, asignndole a la primera valores iniciales de forma declarativa. La
Figura 80 muestra dos momentos durante la ejecucin.

Al igual que los controles de servidor, los controles de usuario participan de
todo el periodo de duracin de la ejecucin de una solicitud. Esto significa
que un control de usuario puede controlar sus propios eventos mediante la
encapsulacin de parte de la lgica de la pgina 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 introduccin de la calle y nmero (TxtDireccion), por un control Web de
tipo TextBox, de forma que genere postbacks automticamente. Adems, se
atiende al evento OnTextChanged de forma que al introducirse la calle y el
nmero se asigne un cdigo postal predeterminado al control HTML TxtCod-
Postal. As, al introducir los datos de la calle, el cambio se captura y el cdigo
postal correspondiente se modifica, sin que eso altere a otras instancias del
control de usuario en la misma pgina.
El valor de una variable o
propiedad de un control
puede incluirse en el cdigo
HTML mediante la marca
<%=variable%>, de la forma
habitual en ASP.NET.

Figura 80. Ejemplo de pagelet con propiedades: ejecucin.


Los controles de usuario, como los de servidor, tambin pueden crearse y
aadirse al formulario programticamente. Por ejemplo:

El mtodo LoadControl de la pgina 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 ejecucin de ASP.NET,
segn la convencin nombrearchivo_extension. Si se desea asignar un tipo
diferente al control, puede aadirse 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 mtodo 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-
cin ControlCollection de la pgina base.

Como se ha visto, resulta muy sencillo reutilizar cdigo en forma de contro-
les de usuario. Sin embargo este tipo de controles presenta ciertas desventa-
jas en comparacin con los controles proporcionados por ASP.NET o un
control Web a medida. Los controles de usuario no pueden aadirse a la caja
de herramientas de Visual Studio y tampoco pueden editarse sus propiedades
desde el diseador de formularios. Por otra parte, en necesario distribuir el
archivo .ascx correspondiente con cada aplicacin utilice un determinado
control de usuario, adems de la necesidad de registrar el control en cada
pgina 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 gestin de eventos en el control de usuario de la Figura 79.

Control DireccionEnvio = LoadControl("direccion.ascx");
((DireccionCS) DireccionEnvio).Titulo = "Direccin de envo";
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 cdigo se almacena, ya compilado, en un ensam-
blado (assembly) de tipo DLL de .NET. Este hecho implica una diferencia
fundamental en la distribucin del control, puesto que es suficiente con
agregar dicho ensamblado a la cach global de ensamblados de .NET (GAC)
en el servidor, para que automticamente 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 preciso
enviarlo programticamente 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 algn 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
mtodo Render(), encargado de producir el contenido visual del control. En su
implementacin por defecto Render() est vaco, por lo que es necesario rede-
finirlo en la implementacin de la clase derivada. As pues, para crear un
control a medida sencillo, basta con definir una clase que derive de Control y
redefinir el mtodo Render(). Este mtodo recibe como parmetro un objeto
de la clase HtmlTextWriter, que tiene mtodos como Write() y WriteLine() para es-
cribir en el flujo de salida HTML. El cdigo HTML que el control enviar al
navegador del cliente debe pasarse como parmetro a dichos mtodos. La
Figura 82 y la Figura 83 muestran el control a medida WebCC1 derivado de la
clase Control, as como su inclusin en una pgina Web. El nuevo control
puede insertarse en la pgina tanto de forma programtica como declarativa,
y tambin arrastrndolo desde la caja de herramientas en el diseador de
formularios.

La GAC, cach global de
ensamblados (global assem-
bly cache) es un repositorio
de ensamblados de .NET en
un ordenador al que puede
acceder cualquier aplicacin
.NET, incluidas las aplicacio-
nes ASP.NET. Al margen del
acceso global, una de las
caractersticas fundamentales
de la GAC es la posibilidad de
contener mltiples copias de
un mismo ensamblado, i.e.
con el mismo nombre pero
con distinta informacin de
versin.
En Visual Studio, una bibliote-
ca de controles Web puede
contener una o ms clases,
representando cada una de
ellas un control a medida.
Dichas clases deben ser pbli-
cas y derivar directa o indirec-
tamente de Sys-
tem.Web.UI.Control o,
mejor, de Sys-
tem.Web.UI.WebControls.We
bControl.

Figura 82. Ejemplo de control a medida. Derivando de Control y de WebControl: ejecucin.


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 genricas
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 configuracin de color, tipo de letra y similares, en lugar de
derivar de la clase Control y definir manualmente dichas propiedades, es ms
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 aadir un control a la
caja de herramientas, basta
clicar con el botn derecho
sobre ella, seleccionar la
opcin de aadir y eliminar
elementos, y seleccionar la
DLL que contiene los contro-
les que vayan a aadirse.
Creacin de un proyecto de
biblioteca de controles Web
con Visual Studio.
<%@ 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.cs
using System;
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
{

}

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 diseador de formularios de
Visual Studio, evidenciando la diferencia en el nmero 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 mtodo Render(), desaprovecha-
remos gran parte de la funcionalidad de la clase base. En el ejemplo anterior,
propiedades como BorderColor o Font estn disponibles, pero su modificacin
no altera el resultado visual del control. Esto se debe a que la redefinicin del
mtodo 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 mtodos AddAttributesToRender() y RenderContents(), agregando
los atributos y contenido especficos e invocando despus 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 continuacin 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 parmetro uno de los elementos de la enumeracin
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 ms configurable incluso desde el
diseador 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 diseo 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
pgina, el panel de propiedades muestra todas las propiedades del control y
las clasifica por categoras; algunas propiedades disponen de editores a me-
dida, ms elaborados que la sencilla edicin textual que ofrece el propio
panel de propiedades; etc. Todos estos detalles, que hacen cmodo el uso de
los controles en la fase de diseo, pueden establecerse mediante un conjunto
de atributos. Por ejemplo, para agregar una categora y descripcin a la pro-
piedad Text de los controles de ejemplo de este apartado, bastara con agregar
los atributos siguientes delante de la definicin de la propiedad:

Finalmente, indicar que al margen de los ms de diez atributos predefinidos
disponibles, es posible definir atributos nuevos propios que, por ejemplo,
Archivo WebCustomControl2.cs
using System;
using System.Web.UI.WebControls;

namespace Custom_Control_1
{
public class WebCC3 : WebControl
{

// El constructor llama al constructor base indicando el tipo de marca HTML a insertar
public WebCC3() : base(HtmlTextWriterTag.Div) {
text = "Master .NET UOC";
}

}

// Mtodo para aadir los atributos propios, como la fuente para el texto
protected override void AddAttributesToRender(HtmlTextWriter writer) {
writer.AddStyleAttribute(HtmlTextWriterStyle.FontFamily, "Arial");
// Y dejamos que la clase base aada el resto
base.AddAttributesToRender(writer);
}

// Mtodo para aadir el contenido propio: el texto
protected override void RenderContents(HtmlTextWriter writer) {
writer.Write(Text);
// Y dejamos que la clase base aada el resto
base.RenderContents(writer);
}
}
}
Figura 85. Controles a medida: redefinicin 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. Pginas maestras

Al construir un sitio Web de cierta entidad es habitual el requerimiento de
que todas las pginas 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 pgina con informa-
cin de copyright, etc. Si bien los controles de usuario permiten solventar
algunas de estas situaciones, a menudo acaba siendo inevitable replicar el
cdigo comn usado como punto de partida para cada pgina y aadir el
cdigo especfico a continuacin. Esto, adems de poco productivo, perjudi-
ca a la estructura de la aplicacin y complica el mantenimiento y actualiza-
cin posteriores.

Las pginas maestras permiten reducir tanto el tiempo de diseo como el
posterior mantenimiento del sitio. Una pgina maestra es un archivo inde-
pendiente que aloja los citados elementos comunes y que dispone de reas
reservadas para el contenido especfico, i.e. el que difiere de una pgina a
otra. As, el proceso de construccin de una aplicacin Web con ASP.NET 2.0
consiste en dos partes bien diferenciadas. Primero se disea la pgina maes-
tra que incluye todas las partes comunes que aplicarn a un conjunto de
pginas del sitio, y se establecen tambin las reas de la pgina en las que se
incluirn los contenidos especficos. A continuacin se aaden las pginas de
contenido. Con este mecanismo, las actualizaciones de la pgina maestra
Una pgina maestra define la
estructura y el aspecto perif-
rico comunes a un grupo de
pginas Web.

Figura 86. Mecanismo de pginas maestras.

afectan automticamente al resto de pginas, lo que simplifica considera-
blemente el mantenimiento.

7.2.1. Estructura y controles

Una pgina maestra es como cualquier otra pgina de ASP.NET, i.e. contiene
una combinacin de cdigo HTML y controles de servidor. Sin embargo se
almacena en un archivo con extensin .master, en lugar de la habitual exten-
sin .aspx, lo que designa el archivo como pgina maestra y no como pgina
ASP.NET accesible directamente. Adicionalmente, la cabecera de una pgina
maestra utiliza la directiva <%@ master %> en lugar de la directiva <%@ page %>.

Los atributos con que puede contar la directiva master son, bsicamente, los
mismos que tiene cualquier otra pgina, indicando el lenguaje de programa-
cin base (Language), el archivo donde se encuentra el cdigo (CodeFile), el
nombre de la clase que generar la pgina (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-
cin/implementacin dividida en varios archivos.

Una pgina maestra puede contener HTML esttico, componentes de servi-
dor y, en general, cualquier otro contenido que pueda existir en una pgina
ASP.NET. La estructura es la de una pgina completa, incluyendo la declara-
cin de tipo de documento y marcas como <html>, <head> y <body>. Lo que
distingue a la pgina maestra de las otras, aparte de la extensin y la directi-
va, es la aparicin como parte del contenido de uno o ms componentes de
tipo ContentPlaceHolder, en los que posteriormente se aadir el contenido
especfico de cada pgina.

Para aadir una pgina 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 diseador
idntico al de las pginas .aspx convencionales. En consecuencia, sobre el
espacio de diseo pueden arrastrarse controles, editar el cdigo HTML, etc.
Igualmente puede escribirse cdigo en un fichero asociado para atender a los
eventos disponibles, definir mtodos propios de la pgina, etc. La Figura 88
muestra el aspecto del diseador de pginas maestras en Visual Studio. La
pgina maestra contiene una cabecera y un pie de pgina con informacin
de copyright, as como un men lateral con enlaces a diversas pginas. La
zona central en color gris corresponde al ContentPlaceHolder donde, en cada
caso, deber proveerse el contenido especfico 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 bsicamente sirve para reservar un rea en la pgina
maestra. Es decir, que aparecern como controles en el archivo .master. Pues-
to que ContentPlaceHolder tambin 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 pgina
ASP.NET no aporte un contenido especfico. La propiedad ms 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 pgina .aspx
que insertar el contenido.

Figura 87. Plantillas disponibles: pginas maestras.

Figura 88. Ejemplo de pgina maestra: aspecto visual.

Al igual que ContentPlaceHolder, el control Content es tambin un contenedor y
est derivado de System.Web.UI.Control. La diferencia es que Content se utiliza en
las pginas .aspx para alojar el contenido especfico, vinculndose con un
determinado ContentPlaceHolder mediante la propiedad ContentPlaceHolderID del
primero. La Figura 89 muestra el cdigo resultante para el diseo de la pgi-
na maestra de la Figura 88.

7.2.2. Uso de pginas maestras

Los archivos .master no pueden visualizarse directamente por un navegador
como si fuesen pginas ASP.NET convencionales, sino que estn diseados
para que se haga referencia a ellos desde las pginas que aportarn los conte-
nidos especficos. Para ello se dispone de la propiedad MasterPageFile, en la que
se indica el nombre del archivo de pgina maestra, que aparecer como atri-
buto en la directiva Page de aquellas pginas 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
<li> <asp:LinkButton ID="LinkButton3" PostBackUrl="PizzaPricer.aspx" runat="server">
Prctica
</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>
</form>
</body>
</html>
Figura 89. Ejemplo de pgina maestra: cdigo.


Incluir el atributo MasterPageFile en la directiva Page implica la insercin en la
pgina ASP.NET de los elementos comunes presentes en la pgina maestra,
as como la vinculacin 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 combinacin de contenidos (ver Figura 86), en for-
ma de una nica pgina cuya URL correspondera a la del archivo .aspx, es
decir, la pgina ASP.NET que hace referencia a la pgina maestra. Es impor-
tante tener esto en cuenta, ya que el contexto de ejecucin del cdigo en el
servidor lo establece la pgina que aporta el contenido especfico, no la pgi-
na maestra. Por tanto, los elementos de sta deben tener en cuenta que las
rutas y otras variables de contexto sern las de la pgina en que est utilizn-
dose en ese momento, no la relativa al lugar donde se encuentre la propia
pgina maestra. La Figura 90 muestra el formulario principal de la aplicacin
PizzaPricer incrustado como contenido especfico de la pgina PizzaPrice-
rUOC.aspx que emplea la pgina maestra de la Figura 89.

7.2.3. Pginas maestras globales y anidadas

Como hemos visto, para aplicar una pgina maestra prcticamente basta con
utilizar el atributo MasterPageFile en la directiva Page de la pgina de contenido.
Aunque esto parece simple, cuando el nmero de pginas es elevado el pro-
ceso resulta tedioso y el sitio resultante resulta difcil 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 pgina de contenido a la que aplica la pgina maestra.

existe un mtodo alternativo segn el cual es posible aplicar una pgina ma-
estra a todas las pginas de contenido de un directorio, o incluso de toda la
aplicacin. Para ello basta con modificar el archivo de configuracin
Web.config aadiendo el atributo MasterPageFile a la seccin pages:

De este modo todas las pginas .aspx afectadas por el archivo Web.config adop-
tarn automticamente la estructura y contenidos definidos en la pgina
maestra indicada. Puesto que cada directorio de la aplicacin puede disponer
de su propio archivo Web.config, las pginas contenidas en los diversos direc-
torios pueden definirse en base a pginas maestras diferentes.

Adicionalmente, las pginas maestras pueden anidarse. Esto es, una pgina
maestra puede utilizar como base para su definicin otra pgina maestra ya
definida. Para ello basta con establecer el atributo MasterPageFile indicando la
pgina maestra que se quiere usar como base.

Las pginas maestras anidadas suelen usarse para definir la estructura general
del sitio en una pgina maestra principal, y usar las pginas maestras de se-
gundo nivel para particularizar nicamente ciertos tipos de pginas 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 creacin de pginas maestras anidadas,
por lo que esto debe hacerse manualmente desde la vista de cdigo 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 botn se
espera que suceda determinada accin, o en una lista de seleccin se espera
poder escoger una o ms opciones. Igualmente estamos acostumbrados a que
el aspecto visual de dichos componentes no sea siempre el mismo, depen-
diendo este hecho de la aplicacin, del sistema operativo, de cuestiones de
diseo, etc. En consecuencia cualquier sistema de construccin de interfaces
grficas 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 opcin. Ya
desde ASP.NET 1.x se podan 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 mscaras o skins, i.e.
aplicacin 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 efecta
en el cliente, facilitando al navegador del usuario una referencia de los estilos
que debe emplear al procesar una pgina Web.

Finalmente, no hay que confundir los temas visuales con las pginas maes-
tras. Con stas se configura el aspecto global y la distribucin de los conteni-
dos en las pginas 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 aadir 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 ms archivos de mscara
con la extensin .skin junto con los recursos necesarios, i.e. archivos de im-
genes y hojas de estilo CSS (con extensin .css). Todos ellos se almacenan en
un directorio con el nombre del tema visual en cuestin. A su vez, los direc-
torios de temas se almacenan en un directorio llamado App_Themes que se
aloja en el directorio raz de la aplicacin. Al aadir el primer tema visual al
proyecto, para lo cual Visual Studio dispone de un men especial (ver Figura
92), no slo se crea el directorio correspondiente al tema sino tambin el
directorio App_Themes, si es que no exista ya.

En el archivo con extensin .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 configuracin del tema
visual 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 pgina 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
causara 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 ms de un archivo .skin, de manera
que es posible organizar las diferentes configuraciones segn diferentes crite-
rios: tipos de controles, estilos, etc.

7.3.2. Creacin 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 almacenarn los archivos
del tema. Seguidamente, mediante el men contextual del directorio recin
creado, agregaremos una hoja CSS y un archivo .skin. El archivo .css, que es-
tar vaco por defecto, puede editarse manualmente usando la sintaxis
estndar 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 mostrarn en color amarillo, a no
ser que se vean afectados por una definicin 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 creacin de archivo .skin,
existe una forma sencilla de crearlos sin necesidad de escribir manualmente
todo el cdigo. Basta con crear una pgina ASPX vaca y que no ser accesi-
ble desde la aplicacin, y arrastrar y configurar en su diseo una instancia de
los controles para los que necesitemos definir un aspecto visual. Posterior-
mente podemos copiar en el archivo .skin el cdigo 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. Adems, 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 dems 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 caractersticos 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. Aplicacin de temas visuales

Utilizar uno de los temas visuales definidos en un proyecto, tanto para pgi-
nas individuales como para todo el sitio completo es tarea sencilla. Al hacer
clic sobre el fondo de una pgina, el panel de propiedades muestra las co-
rrespondientes al elemento DOCUMENT. Entre ellas hay dos relacionadas con
la aplicacin 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 because
duplicate 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 default
control 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: cdigo 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 tendrn prioridad sobre los atributos de los controles definidos en la
pgina, mientras que si se usa StyleSheetTheme la prioridad es la inversa. Estas
propiedades se traducen en la aparicin del atributo correspondiente en la
cabecera de la pgina:

Por lo que tambin puede aadirse directamente este atributo en el editor de
cdigo, en lugar de recurrir a la ventana de propiedades del diseador. Al
seleccionar un tema, se aplicarn las plantillas por defecto a los controles que
correspondan, a no ser que los controles en la pgina hagan referencia a una
plantilla concreta mediante el atributo SkinId.

La Figura 94 muestra el formulario principal de la aplicacin PizzaPricer al
que hemos aplicado las pginas 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 excepcin de
aquellos controles (los controles de tipo Label) para los que la plantilla del
tema visual indica otro color. Puede apreciarse adems 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 todas
las pginas de un sitio, no es preciso asignar individualmente el atributo
nicamente los controles con
la propiedad EnableTheming
a True se ven afectados por
los temas visuales.

Figura 94. Tema visual de la Figura 93 aplicado PizzaPricer con pginas maestras .

<%@ Page Theme=TemaUOC ...>
Theme de cada una de ellas. Puede usarse la seccin <system.web> del archivo
Web.config del proyecto para incluirlo:

7.4. Web Parts

Cada vez es ms habitual encontrar sitios Web en los que la interfaz de usua-
rio es dinmica y personalizable. Estos sitios permiten al usuario personalizar
los elementos visuales y su disposicin 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-
cin en el servidor, cdigo de script para los navegadores, etc.

ASP.NET 2.0 incorpora un mecanismo que simplifica considerablemente el
proceso de personalizacin. Un conjunto de nuevos controles, a los que se
denomina genricamente Web Parts, permite la construccin de pginas con
layout modular y dinmico as como contenido personalizable desde la pro-
pia pgina 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. Adems es posible esta-
blecer conexiones entre esos objetos, incluir catlogos de seleccin y distri-
bucin y editores para alterar prcticamente cualquier aspecto de la interfaz.

7.4.1. Estructura de la pgina

Una pgina personalizable mediante Web Parts debe incluir una serie de
elementos indispensables, a los que pueden aadirse otros opcionales segn
convenga. Es indispensable que la pgina 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 ms usuales
CatalogZone, PageCatalogPart, EditorZone y los distintos editores de apariencia
(AppearanceEditorPart), comportamiento (BehaviorEditorPart) y posicionamiento
(LayoutEditorPart).

Lo primero que debe incluirse en una pgina que va a ser personalizable es el
componente WebPartManager. Su funcin es la de ocuparse de la comunicacin
entre los distintos Web Parts que finalmente haya en la pgina, as como
gestionar su visualizacin en funcin del modo que est activo en cada mo-
mento. Seguidamente debern delimitarse las reas personalizables de la
pgina, utilizando para ello los controles WebPartZone deseados. Cada uno de
ellos puede contener varios elementos: mens, listas, cuadrculas, calenda-
rios y, en general, cualquier control visual, que al ser introducido en el Web-
PartZone se convertir automticamente en un Web Part.
Controles Web Part en Visual
Studio 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 aadir al objeto. Adicionalmente, el
usuario podr llevar cada objeto desde una zona a otra simplemente
arrastrndolo. Los objetos cerrados no podrn volver a abrirse a menos que
la pgina incluya una zona de catlogo (control CatalogZone) y una lista de los
Web Parts disponibles (control PageCatalogPart).

La Figura 95 muestra la estructura, a nivel de cdigo, de la pgina personali-
zable mediante Web Parts ms 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 pgina .aspx en la que insertaremos un WebPartManager, segui-
do de dos controles WebPartZone a cuya derecha existir un rea de conteni-
dos. La distribucin en la pgina puede efectuarse con una tabla HTML, por
ejemplo. Podemos editar la propiedad HeaderText de los WebPartZone para dar-
les un ttulo y establecer los nombres de las opciones del men asociado, con
las propiedades CloseVerb, MinimizeVerb y similares. Debajo de los WebPartZone
insertaremos un botn cuyo fin ser habilitar la personalizacin. La primera
de 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 pgina en Visual Studio.

Con lo hecho hasta el momento obtendremos una pgina (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 pgina en ejecucin,
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>
</form>
</body>
</html>
Figura 95. Pgina personalizable mediante Web Parts: cdigo.


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 pgina.
Para facilitar la reapertura de los objetos cerrados, y en general su asociacin
con una WebPartZone u otra, puede usarse un control CatalogZone y, dentro de
ste, un control PageCatalogPart. La Figura 98 muestra el diseo de la pgina
con los nuevos componentes en Visual Studio.

Figura 96. Ejemplo de uso de Web Parts: distribucin de componentes.

Figura 97. Ejemplo de uso de Web Parts: Web Part minimizado.


Estos nuevos componentes no sern visibles por defecto. En el ejemplo, usa-
remos el botn para activar su visualizacin, aadiendo el siguiente cdigo al
mtodo de atencin 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: catlogo visible.

Lo que conseguiremos es cambiar del modo de visualizacin del catlogo, de
forma que se active al hacer clic en el botn. En ese momento aparecer la
zona de configuracin, permitiendo marcar los objetos a aadir y su destino.
La Figura 99 muestra el nuevo aspecto de la pgina.

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 aadida al catlogo.

Por otra parte, la Figura 101 muestra cmo al cerrar un Web Part, ste apare-
ce indexado en el elemento catlogo, desde donde es posible volver a inser-
tarlo en cualquiera de las zonas de Web Parts definidas en la pgina.

Finalmente es interesante destacar que el aspecto final de la pgina, que es-
tablece la configuracin preferida por el usuario, se almacena no solamente
para la sesin actual, sino que en posteriores visitas el usuario seguir viendo
la pgina tal como la dej. Para ello, ASP.NET emplea el directorio App_Data
de la aplicacin donde crea una base de datos de SQL Server (puede ser la
versin Express) que almacena en todo momento el estado de las configura-
ciones de todas las pginas del sitio y para todos los usuarios.

I. Controles Web Forms: Referencia
Este apartado presenta una descripcin detallada de las clases ms importan-
tes de ASP.NET en lo referente a la construccin de interfaces de usuario: la
clase Control, la clase WebControl y la clase Page. Conocer estas clases es impor-
tante dado que la prctica totalidad de las funcionalidades que ofrecen los
diversos controles disponibles viene heredada de alguna de estas clases.

Se incluye adems una breve referencia a los controles de servidor disponi-
bles en las diversas libreras 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 validacin. 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 gua 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 aplicacin.

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 creacin 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 ms sofisticados y abstractos.

Figura 102. Espacios de nombres y jerarqua de controles de ASP.NET.

I.2. La clase System.Web.UI.Control

Esta clase define las propiedades, los eventos y los mtodos que son comunes
a todos los controles de servidor de ASP.NET. En consecuencia es la clase
primaria de donde se deriva para la construccin de controles personaliza-
dos. Sin embargo, puesto que Control no ofrece ningn tipo de interfaz de
usuario, no es la mejor candidata para derivar determinados controles, a no
ser que se desee conseguir el mximo grado de personalizacin.

Una pgina Web de ASP.NET se implementa a partir de la clase Page, derivada
de Control. Tambin 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 continuacin se muestra una tabla con las propiedades ms habituales de
la clase Control junto con su descripcin.

Controls
Obtiene un objeto ControlCollection que representa los
controles (secundarios) que estn contenidos dentro
del control.
EnableViewState
Booleano que indica si el control debe mantener su
estado 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 pgina que contiene
al control.
UniqueID
Obtiene un string identificador nico cualificado jerr-
quicamente del control.
Visible
Booleano que indica si el control es visible o no.

I.1.2 Eventos comunes

A continuacin se muestra una tabla con los eventos ms habituales de la
clase Control junto con su descripcin.

Evento Descripcin
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 Mtodos comunes

A continuacin se muestra una tabla con los mtodos ms habituales de la
clase Control junto con su descripcin. Los mtodos heredados de la clase
Object (Equals, GetHashCode, GetType y ToString) se han obviado.

Mtodo Descripcin
DataBind
Enlaza el control y sus controles secundarios con un origen de
datos.
Dispose
Habilita el control para que realice limpieza de su contenido
antes 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 otros
controles.
RenderControl
Enva 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 mtodos que son comunes
a todos los controles del espacio de nombres System.Web.UI.WebControls. De esta
clase derivan la mayora de los controles Web de servidor, excepto Literal,
PlaceHolder, Repeater y XML, que poseen funcionalidades bien diferenciadas. As
pues, la mayora de las propiedades de apariencia visual y de comportamien-
to de dichos controles se definen en esta clase.

I.1.4 Propiedades comunes

la clase WebControl junto con su descripcin. Las propiedades heredadas de la
clase Control se han obviado.

AccessKey
Establece la letra subrayada que permite desplazarse instant-
neamente al control.
Attributes
Obtiene la lista de atributos relacionados con el dibujado del
control 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 por
defecto es true.
Font
Obtiene las propiedades de la fuente tipogrfica usada por el
control.
ForeColor
Obtiene o establece el color de primer plano (tpicamente el del
texto) del control.
Height
Obtiene o establece la altura del control.
Style
Obtiene una coleccin de atributos de texto que se procesan
como un atributo de estilo en la marca ASP.NET del control.
TabIndex
Obtiene o establece el ndice de tabulacin del control.
ToolTip
Obtiene o establece el texto que se muestra cuando el puntero
del ratn 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 Mtodos comunes

La mayora de los mtodos de la clase WebControl, incluso los heredados de
Object, son exactamente los mismos que los de la clase control. El resto de
mtodos (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 extensin .aspx. Estos archivos
se compilan en tiempo de ejecucin en forma de objetos Page y se almacenan
en la cach del servidor.

Page es la clase base para la creacin de formularios Web mediante la tcnica
de code-behind y code-beside.

La case Page sirve tambin como contenedora de los controles de servidor de
una pgina Web ASP.NET.

I.1.7 Propiedades

la clase Page junto con su descripcin. Las propiedades heredadas de la clase
Control se han obviado.

Application
Obtiene el objeto Application para la solicitud en curso.
Cache
Obtiene el objeto Cache asociado a la aplicacin a la cual per-
tenece la pgina.
ClientTarget
Obtiene o establece un valor que permite reemplazar la detec-
cin automtica de capacidades del navegador y especificar
cmo se procesa una pgina en un navegador concreto.
EnableViewSta-
te
Booleano que indica si la pgina debe mantener su estado de
vista y el de los controles que contiene.
ErrorPage
Obtiene o establece la pgina de error a la que se redirecciona
el navegador en caso de error.
ID
Obtiene o establece un string identificador de la pgina.
IsPostBack
Obtiene un booleano que indica si la pgina se est cargando
como respuesta a un valor devuelto por el navegador, o si es la
primera vez que se carga la pgina.
Request
Obtiene el objeto HttpRequest para la pgina solicitada.
Response
Obtiene el objeto HttpResponse para la pgina solicitada.
Session
Obtiene el objeto Session asociado a la solicitud en curso.
User
Obtiene informacin sobre el usuario que hace la solicitud.
Validators
Obtiene la coleccin de controles de validacin en la pgina.
Visible
Obtiene o establece un booleano que indica si la pgina es
visible 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 Descripcin
AbortTransaction
Se produce cuando el usuario interrumpe una transaccin.
CommitTransac-
tion
Se produce cuando se completa una transaccin.
Error
Se produce cuando se lanza una excepcin no controlada.

I.1.9 Mtodos

A continuacin se muestra una tabla con los mtodos ms habituales de la
clase Page junto con su descripcin. Los mtodos 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 mtodos heredados
de la clase TemplateControl, como LoadControl y ParseControl.

Mtodo Descripcin
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
pgina o el control de usuario.
Register-
ViewState-
Handler
Establece que el view state de la pgina sea persistente.
Validate
Indica a cada control de validacin incluido en la pgina que
valide el contenido al que est vinculado.

I.5. Controles HTML de servidor

En una pgina 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 programticamente, simplemente debe
aadrsele el atributo runat="server". Adems, como sucede con el resto de
controles, todos los controles HTML de servidor en una pgina 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-
cin, los controles HTML de servidor se engloban dentro del espacio de
nombres System.Web.UI.HtmlControls. La Figura 103 muestra la jerarqua de clases
correspondiente a estos controles.

Figura 103. Espacios de nombres y jerarqua 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-
putButton en su forma <Input type=button>. Proporciona botones clicables
para los formularios. Ver ms 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 botn que,
al clicarse, limpia el contenido de los campos del formulario dejndolos
con sus valores por defecto. Ver ms en

El control SubmitButton se basa en la clase
HtmlInputButton en su forma <Input type=submit>. Proporciona un botn que
al clicarse causa en el envo del formulario al servidor. Ver ms 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 ms 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 seleccin y carga de un archivo
desde el navegador del usuario al servidor. Ver ms 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 ms 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 opcin
seleccionable (o no) en un formulario. Ver ms 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 botn
de opcin. Ver ms 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, informacin en el formulario, que se enviar al servidor en el
prximo postback. Ver ms 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 mltiples lneas en el formulario.
Ver ms 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 programticamente agregando controles HtmlTable-
Row a la coleccin Rows de la tabla y controles HtmlTableCell a la coleccin
Cells de la fila. Puede agregarse contenido a una celda programticamente
agregando controles a la coleccin Controls de la celda. Ver ms 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 ms 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 seleccin simple. Ver ms 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 ms 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 slo
se incluyen controles de tipo formulario, como botones y cuadros de texto,
sino controles de propsito general, como calendarios.

Desde el punto de vista de la programacin, los controles Web de servidor se
engloban dentro del espacio de nombres System.Web.UI.WebControls. La Figura
104 muestra la jerarqua de clases correspondiente a estos controles.

Seguidamente se describen brevemente todos los controles Web de servidor

El control Label permite visualizar un texto,
que adems puede cambiarse programticamente durante la ejecucin.
Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/label.aspx.

El control TextBox permite que el usuario
pueda introducir un texto en el formulario. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/textbox.aspx.

El control Button proporciona botones cli-
cables para los formularios. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/button.aspx.

El control LinkButton proporciona un botn
con el que devolver el formulario al servidor. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/linkbutton.aspx.

Figura 104. Espacios de nombres y jerarqua de controles Web de servidor de ASP.NET.

El control ImageButton permite crear boto-
nes clicables a partir de una imagen. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/imagebutton.aspx.

El control HyperLink permite incrustar URLs
en un formulario, i.e. enlaces a otras pginas Web. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/hyperlink.aspx.

El control DropDownList proporciona una
lista desplegable de seleccin simple. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/dropdownlist.aspx.

El control ListBox permite crear listas des-
plegables de seleccin simple o mltiple. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/listbox.aspx.

El control CheckBox muestra una opcin
seleccionable (o no) en un formulario. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/checkbox.aspx.

El control CheckBoxList agrupa un conjunto
de opciones seleccionables. La seleccin puede ser mltiple. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/checkboxlist.aspx.

El control RadioButton permite crear un
botn de opcin. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/radiobutton.aspx.

El control RadioButtonList permite crear gru-
pos de botones de seleccin, en los que slo uno puede estar seleccionado
en un momento dado. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/radiobuttonlist.aspx.

El control Image permite visualizar una
imagen en el formulario. Ver ms 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
ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/imagemap.aspx.

El control Table permite mostrar informa-
cin en forma de tablas. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/table.aspx.

El control BulletedList permite crear listas
con el formato habitual de un documento de texto. Ver ms 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 ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/hiddenfield.aspx.

El control Literal muestra contenido esttico
al que no se pueden aplicar estilos visuales. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/literal.aspx.

El control Calendar muestra un calendario
mensual en el que es posible seleccionar fechas. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/calendar.aspx.

El control AdRotator permite visualizar una
secuencia de imgenes. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/adrotator.aspx.

El control FileUpload permite enviar un fi-
chero al servidor. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/fileupload.aspx.

El control Wizard permite crear asistentes
para llevar al usuario a travs de una serie de pasos y recoger informacin.
Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/wizard.aspx.

El control Xml permite generar documen-
tos XML a partir de una transformacin XSL. Ver ms 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 ms 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 ms 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 aaden dinmicamente desde el cdigo de
la aplicacin. Ver ms 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 ejecucin. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/multiview.aspx.

El control Substitution ofrece un mecanism
oavanzada para la insercin de contenido dinmico en la pgina Ver ms
en http://www.asp.net/QuickStart/aspnet/doc/ctrlref/standard/substitution.asp.

I.7. Controles de validacin de servidor

Los controles de validacin de servidor se engloban dentro del espacio de
nombres System.Web.UI.WebControls por lo que pueden considerarse controles
Web de servidor. Sin embargo su funcionalidad no est enfocada al diseo
visual de interfaces de usuario sino a la validacin de los datos introducidos
a travs del resto de controles. En caso de no validacin estos controles pue-
den encargarse de visualizar mensajes de error.

Seguidamente se describen brevemente todos los controles de validacin de
servidor disponibles en la caja de herramientas de Visual Studio 2005.

El control CompareValidator valida el conte-
nido de un control comparndolo con el valor de otro control, o con el
valor explcito de la propiedad ValueToCompare del control. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/validation/comparevalidator.as
px.

El control CustomValidator permite realizar
validaciones personalizadas mediante la invocacin a una funcin espec-
ficamente diseada para ello. Ver ms 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 ms
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 patrn definido por una
expresin regular. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/validation/regularexpressionval
idator.aspx.

El control RequiredFieldValidator permite veri-
ficar si se han introducido datos en un campo del formulario. Ver ms 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 pgina. Ver ms 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 informacin pro-
veniente de una fuente de datos en formato de tabla y, opcionalmente,
admite la seleccin, ordenacin, paginacin y edicin de los datos. Ver
ms 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 seleccin y
edicin de elementos. El contenido y diseo de los elementos de la lista
de DataList se define utilizando plantillas. Ver ms 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 ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/detailsview.aspx.

El control FormView es muy similar a DetailsView
a excepcin de que la interfaz de usuario se especifica mediante plantillas
y no es tan esttica. Ver ms 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 ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/repeater.aspx.

El control SqlDataSource corresponde a una
conexin con un proveedor de ADO.NET para una base de datos SQL. Ver
ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/sqldatasource.aspx.

El control AccessDataSource corresponde a una
conexin con un proveedor de ADO.NET para una base de datos Micro-
soft Access. Ver ms 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 conexin sino una clase con
la que se realizan las operaciones de acceso. Ver ms 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 ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/data/xmldatasource.aspx.

El control SiteMapDataSource establece una
fuente de datos para el mapa de navegacin en un sitio Web. Ver ms 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 ms 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 ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/login/loginview.aspx.

El control PasswordRecovery proporciona una
interfaz para recuperar el password de un usuario de un sitio Web. Ver
ms 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 pginas del sitio. Ver ms 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 ms 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 ms 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 ms
en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/login/changepassword.aspx.

I.10. Controles de navegacin

Seguidamente se describen brevemente todos los controles de navegacin
El control SiteMapPath muestra una lista de
enlaces que representan la posicin de la pgina que est visionando el
usuario en la estructura jerrquica de un sitio Web. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/navigation/sitemappath.aspx.

El control Menu permite construir mens de
navegacin estticos o dinmicos en un sitio Web. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/navigation/menu.aspx.

El control TreeView permite visualizar estructu-
ras jerrquicas estticas o dinmicas en forma de rbol. Ver ms 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 ms
en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/webpartmanager.asp
x.

El control ProxyWebPartManager permite especi-
ficar estticamente los datos de conexin en una pgina cuando WebPart-
Manager se especifica en una pgina maestra. Ver ms 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
ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/webpartzone.aspx.

El control CatalogZone se emplea para alojar
controles del tipo CatalogPart. Slo es visible cuando el usuario activa el
modo CatalogDisplayMode en la pgina que est visionando. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/catalogzone.aspx.

El control DeclarativeCatalogPart proporciona un
mecanismo para aadir declarativamente controles de servidor a un cat-
logo en una pgina Web. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/declarativecatalogpa
rt.aspx.

El control PageCatalogPart sirve como catlogo
para contener aquellos controles aadidos a la pgina que el usuario haya
minimizado, de forma que puedan recuperarse ms tarde. Ver ms 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 configuracin de una Web Part o
un control de servidor que el usuario desea aadir a la pgina. Ver ms 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 pginas y almacenar sus preferencias. Ver
ms 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 ms 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 ms 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 ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/layouteditorpart.asp
x.

El control PropertyGridEditorPart proporciona una
interfaz genrica para editar las propiedades personalizadas (no de inter-
faz de usuario) de los controles de tipo Web Part. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/propertygrideditorpa
rt.aspx.

El control ConnectionsZone posibilita la interco-
nexin de Web Parts dinmicamente. Ver ms en
http://www.asp.net/QuickStart/aspnet/doc/ctrlref/webparts/connectionszone.asp
x.

II. Instalacin del servidor Web IIS
Para poder servir aplicaciones ASP.NET o de cualquier otro tipo basadas en
un motor de pginas de servidor, es necesario disponer de un ordenador con
un servidor Web instalado y en ejecucin. Si el servidor tiene asociada una IP
pblica, las aplicaciones alojadas en l podrn ejecutarse desde cualquier
lugar de Internet. De otro modo slo podrn 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
direccin IP, si no se ha registrado en DNS. Finalmente recordemos que todo
ordenador recibe la direccin IP privada 127.0.0.1 y el nombre localhost. As
pues podremos usar esta direccin 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 tecnologa de Microsoft, el servidor Web por
defecto es IIS (Internet Information Services), actualmente en la versin 6.0.
IIS se incluye como un componente de los sistemas operativos Windows
2000 Server, Windows XP Profesional y Windows 2003 Server. A continua-
cin veremos algunos de los aspectos relacionados con la instalacin y con-
figuracin de IIS y el motor de ASP.NET para los sistemas ms 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 instalacin del sistema y seguiremos
los siguientes pasos:
Abrir el Panel de Control de Windows y seleccionar la opcin Agregar o
quitar programas.
Hacer clic sobre el botn 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 botn Siguiente, con lo que se completa la
instalacin.

Si instalamos los componentes de la plataforma .NET con posterioridad a la
instalacin de IIS, no ser necesario realizar ningn paso adicional.


Si el orden de la instalacin ha sido el inverso, el filtro ISAPI de ASP.NET no
estar configurado correctamente para IIS. La configuracin puede comple-
tarse desde la lnea de comandos ejecutando el programa asp_regiis.exe con la
opcin i . Dicho programa se encuentra alojado en el directorio
C:\Windows\Microsoft.NET\Framework\vXXXX, donde XXXX corresponde a la versin
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 a
continuacin Servicios de Internet Information Server (ver Figura 107).
Figura 106. Instalacin de IIS en Windows XP Profesional (2).


En el rbol desplegable de la consola de administracin abrimos la rama
Sitios Web.
Hacemos clic con el botn secundario del ratn sobre el Sitio Web prede-
terminado y elegimos la opcin Propiedades.
En la ventana que nos aparece seleccionamos la pestaa Directorio parti-
cular y hacemos clic en el botn Configuracin de la parte inferior.
En la primera pestaa de la ventana que se abre vemos una lista con to-
das las asignaciones de aplicacin. 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 ejecucin de apli-
caciones ASP.NET. Concretamente lleva preinstalados tanto el servidor IIS
6.0 como el .NET Framework. Sin embargo, la instalacin por defecto del
sistema no activa ni IIS ni ASP.NET. Con el CD de instalacin del sistema a
mano, seguiremos los siguientes pasos:


En las Herramientas administrativas seleccionamos la opcin Administre
su servidor.
Hacemos clic en el enlace Agregar o quitar funcin. Se lanza el asistente
de configuracin donde elegimos la opcin Servidor de aplicaciones (IIS,
ASP.NET) y hacemos clic en el botn Siguiente (ver Figura 111).
En la ventana de opciones del servidor marcamos la opcin Habilitar
ASP.NET y procedemos con la instalacin (ver Figura 112).

Al finalizar la instalacin podemos comprobar si ASP.NET est en funciona-
miento:
Figura 112. Instalacin de IIS en Windows 2003 Server (2).


En el Panel de Control seleccionamos Herramientas administrativas y a
continuacin Administracin de Internet Information Server (IIS).
En la pestaa 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 opcin si finalmente la aplicacin
ha de alojarse en un servidor para su explotacin.

Cassini, un servidor Web desarrollado como ejemplo de programacin de
servicios de .NET, es otra opcin posible. Est escrito en C# y su cdigo fuen-
te est disponible en Internet. Webmatrix, una herramienta gratuita de desa-
rrollo de aplicaciones ASP.NET, incorpora Cassini. Igualmente, Visual Studio
tambin 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, slo ser necesario instalar IIS para
las pruebas finales previas a la explotacin de la aplicacin.


Actividades
Todas las actividades que se plantean a continuacin hacen referencia a la
aplicacin PizzaPricer del apartado Primera aplicacin ASP.NET. Cada acti-
vidad plantea un objetivo bsico que pretende dar pie a la experimentacin.

1
Aade un control de tipo RequiredFieldValidator asociado al RadioButtonList PizzaSi-
zes. Si la validacin no es satisfactoria la aplicacin deber mostrar un aste-
risco de color rojo junto a la etiqueta Elige el tamao de la pizza:. El obje-
tivo es forzar que la aplicacin no pueda solicitar el precio de la pizza sin que
el usuario haya seleccionado el tamao de la misma.

2
Aade un control de tipo CustomValidator. Programa una funcin de validacin
personalizada de forma que no se produzca la validacin si el tamao de la
pizza es Grande y no se ha elegido ningn complemento. Si la validacin
no es satisfactoria la aplicacin deber mostrar un asterisco de color rojo
junto a la etiqueta Elige los complementos:.

3
Aade un control de tipo ValidationSummary que permita mostrar mensajes de
error personalizados para los casos de no validacin de las dos actividades
anteriores. Los mensajes debern aparecer en las lneas posteriores al botn
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 informacin conteni-
da en dicho archivo.

5
Utiliza el archivo Global.asax para detectar el inicio de la sesin y mostrar un
mensaje en la pgina indicando el tipo de navegador del usuario.

6
7 Utiliza el objeto Application para almacenar datos de cuntas pizzas de cada
uno de los tres tamaos han sido solicitadas a lo largo del tiempo. Aade un
botn al formulario principal que permite consultar la estadstica.

8
Utiliza el objeto Session para almacenar el color de fondo de todas las pginas
de una sesin. El color se debe asignar de forma aleatoria al inicio de la se-
sin y debe mantenerse a lo largo de toda ella en todas las pginas visitadas.

9
Escribe un control de usuario consistente en un recuadro con una lnea de
texto en su interior. El control debe ofrecer propiedades para cambiar el tipo
de lnea 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 pgina.

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
(cdigo 404) en los directorios de la aplicacin, hacia una pgina de error
personalizada.

12
Construye un sistema de autenticacin de usuarios basada en formularios. La
aplicacin debe ofrecer una primera pgina donde autenticarse o darse de
alta si todava no se es un usuario registrado. Una vez autenticado el usuario,
la aplicacin debe mostrar el formulario principal. Puedes almacenar los
nombres de usuario y las contraseas en un archivo XML, por ejemplo.
Prueba a usar encriptacin (System.Security.Cryptography) para las contraseas.

Bibliografa
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

Teoria ASP

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Teoria ASP

Cargado por

Copyright:

Formatos disponibles

ASP.

También podría gustarte