2. Agenda
ASP.NET 2.0
Introducción
Modelo de Código de Página Web ASP.NET
Manejo de Estado
Controles WebControls & HTMLControls
UserControls & CustomControls
CallBacks en Clientes
Acceso de Datos
3. Agenda
ASP.NET 2.0
Introducción
Modelo de Código de Página Web ASP.NET
Manejo de Estado
Controles WebControls & HTMLControls
UserControls & CustomControls
CallBacks en Clientes
Acceso de Datos
4. Client-Side Event Procedures
Típicamente usado solo con controles HTML
Interpretado por el explorador y ejecutado sobre
el cliente
No tiene acceso a los recursos de servidor
Usa <SCRIPT language="language">
Internet .HTM
Pages
ASP.NET 2.0
5. Server-Side Event Procedures
Usado con controles de servidor Web y HTML
El código es compilado y ejecutado sobre el servidor
Se tiene acceso a los recursos del servidor
Usa <SCRIPT language="vb" runat="server"> o
<SCRIPT language=“cs" runat="server">
Internet .ASPX
Pages
ASP.NET 2.0
6. Entendiendo el ciclo de vida de una pagina
Page_Init
Page_Init
Page_Load
Page_Load
Control events
Evento Change Textbox1_Changed
Textbox1_Changed
Evento Action Button1_Click
Button1_Click
Page_Unload
Page_Unload
ASP.NET 2.0
La pagina es desechada
8. ASP.NET Web Application
ASP.NET Web Server
Clients
Web
Forms
Web.
Output Cache
Page1.
aspx Code- config
behind
Page2. pages
Internet machine.
Internet aspx config
global.
asax
Web XML
Database Components
Services Data
ASP.NET 2.0
10. Las aplicaciones Web ASP.NET
componentes
Formularios Web o páginas .ASPX: Proveen de la
interfase visual. No tienen código ejecutable.
Páginas de Código por detrás: Están asociadas con cada
formulario y son las que proveen del código ejecutable.
Archivos de Configuración: Son archivos que permiten
configurar la aplicación, por ejemplo el archivo
Web.config y el servidor por ejemplo el archivo
machine.config.
Global.asax: Es un archivo que contiene código. Este
código responde a eventos que se disparan en la
aplicación Web.
ASP.NET 2.0
11. Proyecto Web
Formulario Web ASP.NET (.aspx): Es la interfase visual de la aplicación
Web. Puede tener código por detrás., cuyo nombre es
Formulario.aspx.vb o Formulario.aspx.cs
Clases y código por detrás (.cs y .vb): Son las clases que utiliza el
proyecto y el código de soporte de los formularios y los servicios.
Clase Global (.asax): Es un archivo que contiene código de eventos a
nivel de aplicación.
Web.config: Es un archivo XML con información de configuración.
Archivos ensamblados del proyecto (.dll): Todas las paginas de código
por detrás de una aplicación son compilados en un solo DLL que se
guarda en el directorio /bin con el nombre de NombreDeProyecto.dll
VsProj o CsProj: Vs Proj es la extensión de un proyecto si usted
escribió la aplicación en Visual.NET. CsProj es la extensión si utilizo
c#
ASP.NET 2.0
12. Que es un Web Form?
Extensión .aspx
Atributos de pagina
Directiva @ Page
Atributos de Body
Atributos de Formularios
<%@ Page Language="vb" Codebehind="WebForm1.aspx.vb"
SmartNavigation="true"%>
<html>
<body ms_positioning="GridLayout">
<form id="Form1" method="post" runat="server">
</form>
</body>
ASP.NET 2.0
</html>
13. Web.config
Repositorio central de configuración de la
aplicación Web
Definición de settings personaliados
Configuración de Autorización y
Autenticación
ASP.NET 2.0
14. Creando un Web Form con Visual
Studio .NET - Demo
Creación de nuevos Web Form
Agregar nuevos Web Forms desde el
explorador de soluciones
Actualizar paginas HTML existentes
dentro de Web Forms
ASP.NET 2.0
15. Modelo de Código de Página Web
Una Página Web ASP.NET consta de dos
partes:
Elementos visuales, que incluyen
controles del servidor y texto estático.
Programación lógica para la página, que
incluye manejador de eventos y el resto
del código.
Modelos de Página
Modelo de Página Single-File
ASP.NET 2.0
Modelo de Página Code-Behind
16. El modelo Code-Behind
Toma ventajas del nuevo Partial Classes
El archivo Code-behind no es una definición completa de
clase.
Un archivo code-behind podría ser el siguiente
using System;
public partial class SamplePage_aspx
{
void Button1_Click(Object sender, EventArgs e)
{
Label1.Text = "Clicked at " +
DateTime.Now.ToString();
}
}
ASP.NET 2.0
Directiva @ Page
<%@ page language="C#" CodeFile="SamplePage.aspx.cs"
Inherits="SamplePage" %>
17. El Modelo Code-Behind
El archivo code-behind es más simple.
Incluye controles de usuario en una página, sin
tener que crear explícitamente las variables para
ellos.
Más fácil de separar el desarrollo del markup y
del código.
ASP.NET 2.0
18. Que es el View State
Técnicas utilizadas por ASP.NET para
mantener el estado de los controles.
Problemas comunes al uso de View State
Incremento en el tiempo de la carga de la pagina
Incremento en el tamaño de la pagina.
ASP.NET 2.0
19. Solución de problemas de rendimiento en
View State
Desactivar la propiedad EnableViewState para
el control correspondiente.
Desactivar la propiedad EnableViewState en
la directiva @Page
Guardar el View State en archivos del sistema
del servidor en lugar de campos ocultos
ASP.NET 2.0
20. Que es el Control State
Reemplaza el private use de View State
Private use de view state ocurre cuando
un control almacena propiedades no
publicas en view state
Las aplicaciones no pueden acceder a
propiedades no publicas por problemas
de protección
ASP.NET 2.0
21. Session State
Definición de almacenes
personalizados de session state.
Nuevo modelo extensible
Personalización del modelo de session
state
ASP.NET 2.0
22. Cache
La clase CacheDependency encapsula
mecanismos de dependencia de cache
Representa un archivo o carpeta o
conjunto de archivos y carpetas que
almacenan ítems relacionados a un ítem
agregado a la cache
ASP.NET 2.0 tiene soporte para
dependencias personalizadas
ASP.NET 2.0
23. Controles
HTML vs. Server Controls
User controls
Custom controls
ASP.NET 2.0
24. HTML vs. Server Controls
HTML Server Controls
(HTMLControls) (WebControls)
Más livianos Modelo de
Modelo de programación
programación HTML orientado a objetos
Menor
Mayor funcionalidad
funcionalidad Más pesados
ASP.NET 2.0
25. Que es un control de usuario?
User controls simplifica la reutilización del código y
los componentes de la UI con una aplicación Web
Un user control es un control Web server definido por
el usuario con extensión .ascx
Contiene HTML, pero no el <HTML>, <BODY>, o las
etiquetas <FORM>
<%@ Control Language="vb" %>
o
<%@ Control Language="c#" %>
Contiene código para administrar sus propios
eventos
ASP.NET 2.0
26. Que es un control de usuario?
Similar a una página Web Form completa
Tiene una página de interfaz de usuario y un archivo
de código subyacente
Directiva @Control
Extensión .ascx
No tiene elementos <HTML>, <BODY> y <FORM>
Contiene código para manejar sus propios eventos
Hay dos maneras de crear un Control de Usuario:
Crear un nuevo Control de Usuario
Convertir una página ASP.NET existente a un Control de
Usuario
ASP.NET 2.0
27. Que es un control de usuario?
Registre el control de usuario al comienzo de la
página del Web Formscontenedor con la directiva
@Reference2.
Cree una instancia del control de usuario, ya sea en
el archivo de la clase del código subyacente o en el
bloque de declaración de código del archivo
contenedor .aspx
<%@ ReferenceControl=“myUserControl.ascx" %>
Control userControl1= LoadControl(“myUserControl.ascx");
((myUserControl)userControl1).Color = “red";Page.Controls.Add(userControl1);
ASP.NET 2.0
30. Custom Controls
Los controles pueden ser reutilizables
Se pueden generar nuevos controles
ASP.NET 2.0
31. Creando Custom Controls
Diferentes maneras de crear Controles
Personalizados
Compilar un control que combine la
funcionalidad de dos o más controles
existentes
Personalizar un Control existente
derivando de este y reemplazando
(overriding) sus características
Crear un control personalizado al derivar
ASP.NET 2.0
de la clase base Control
32. UserControls vs CustomControls
Controles de Usuario
Mas fáciles de crear
No pueden ser agregados a la Caja de
Herramientas de Visual Studio
Buenos para contenidos estáticos
Controles Personalizados
Mas difíciles de crear
Pueden ser agregados a la Caja de
ASP.NET 2.0
Herramientas de Visual Studio
Buenos para contenidos dinámicos
33. Callbacks en Clientes
Postbacks "Ligeros"
El administrador de Callbacks del cliente transmite
peticiones asincrónicas de XML-HTTP al servidor
El servidor recibe y procesa la petición, pero no
renderiza la página
El administrador de Callbacks del cliente recibe la
respuesta y notifica al cliente a través de un CallBack
registrado
Requiere Internet Explorer 5.0 o superior
Gran manera de mejorar la respuesta de la UI
ASP.NET 2.0
34. Como trabajan los CallBacks en
Cliente
Cliente Servidor
Cliente
11 Administra- 22 Página
El cliente inicia el dor de El administrador
CallBack llamando Llamadas de de CallBacks lanza
por a un Respuesta la llamada
GetCallback- asincrónica XML-
EventReference HTTP al servidor.
33
Se llama al
método
RaiseCall-
backEvent
55 44
ASP.NET 2.0
El cliente es El administrador
notificado que la de CallBacks es
llamada se notificado que la
completó y el llamada se
resultado fue completó
entregado
36. Acceso de Datos
Controles de la Fuente de Datos
Declarativas bidireccionales de data
binding
Controles de Datos
GridView- Como DataGrid, pero mejor
DetailsView – Acompaña la GridView
ASP.NET 2.0
37. ASP.NET 2.0 Data Binding
Usando SqlDataSource
<asp:SqlDataSource ID="Titles" RunAt="server"
ConnectionString="server=localhost;database=pubs;integrated
security=true"
SelectCommand="select title_id, title, price from titles" />
<asp:DataGrid DataSourceID="Titles" RunAt="server" />
ASP.NET 2.0
38. ASP.NET 2.0 Data Binding
Propiedades clave de SqlDataSource
Nombre Descripción
La secuencia de conexión es usada para conectarse al origen
ConnectionString
de datos
SelectCommand Comando utilizado para efectuar consultas
InsertCommand Comando utilizado para realizar inserts
UpdateCommand Comando utilizado para realizar actualizaciones
DeleteCommand Comando utilizado para efectuar cancelaciones
DataSourceMode Especifica si el DataSet o el DataReader es utilizado
ASP.NET 2.0
(default = DataSet)
ProviderName Especifica el Proveedor (default = Proveedor SQL Server .NET)
39. ASP.NET 2.0 Data Binding
Comandos Parametrizados
Las propiedades XxxParameters permiten que
los comandos de base de datos sean
parametrizados.
Nombre Descripción
SelectParameters Especifica los parámetros para SelectCommand
InsertParameters Especifica los parámetros para InsertCommand
UpdateParameters Especifica los parámetros para UpdateCommand
ASP.NET 2.0
DeleteParameters Especifica los parámetros para DeleteCommand
FilterParameters Especifica los parámetros para FilterExpression
40. ASP.NET 2.0 Data Binding
Parámetro de Control
Ata un parámetro reemplazable a una
propiedad de control
<asp:SqlDataSource ID="Countries" RunAt="server"
<asp:SqlDataSource ID="Countries" RunAt="server"
ConnectionString="server=localhost;database=northwind;..."
ConnectionString="server=localhost;database=northwind;..."
SelectCommand="select distinct country from customers order by
SelectCommand="select distinct country from customers order by
country" />
country" />
<asp:SqlDataSource ID="Customers" RunAt="server"
<asp:SqlDataSource ID="Customers" RunAt="server"
ConnectionString="server=localhost;database=northwind;..."
ConnectionString="server=localhost;database=northwind;..."
SelectCommand="select * from customers where country=@Country">
SelectCommand="select * from customers where country=@Country">
<SelectParameters>
<SelectParameters>
<asp:ControlParameter Name="Country" ControlID="MyDropDownList"
<asp:ControlParameter Name="Country" ControlID="MyDropDownList"
PropertyName="SelectedValue" />
PropertyName="SelectedValue" />
ASP.NET 2.0
</SelectParameters>
</SelectParameters>
</asp:SqlDataSource>
</asp:SqlDataSource>
<asp:DropDownList ID="MyDropDownList" DataSourceID="Countries"
<asp:DropDownList ID="MyDropDownList" DataSourceID="Countries"
DataTextField="country" AutoPostBack="true" RunAt="server" />
DataTextField="country" AutoPostBack="true" RunAt="server" />
<asp:DataGrid DataSourceID="Customers" RunAt="server" />
<asp:DataGrid DataSourceID="Customers" RunAt="server" />
41. ASP.NET 2.0 Data Binding
XmlDataSource
Data binding declarativo a datos XML
Soporta cacheo y transformaciones XSL
Data binding unidireccional solamente; sin
actualizaciones
<asp:XmlDataSource ID="Rates" DataFile="Rates.xml" RunAt="server" />
<asp:XmlDataSource ID="Rates" DataFile="Rates.xml" RunAt="server" />
<asp:TreeView ID="MyTreeView" DataSourceID="Rates" RunAt="server" />
<asp:TreeView ID="MyTreeView" DataSourceID="Rates" RunAt="server" />
ASP.NET 2.0
43. Control GridView
Control DataGrid mejorado
Renderiza conjuntos de registros como
tablas HTML
Clasificación, paginado, selección,
actualización y soporte de borrado
incorporados.
Declarado en elementos <Columns>
UI altamente personalizable
ASP.NET 2.0
44. Control GridView
<asp:SqlDataSource ID="Employees" RunAt="server"
ConnectionString="server=localhost;database=northwind;..."
SelectCommand="select lastname, firstname, title from
employees" />
<asp:GridView DataSourceID="Employees" Width="100%"
RunAt="server" />
ASP.NET 2.0
45. Control GridView
Nombre Descripción
BoundField Renderiza columnas de texto de campos en data source
ButtonField Renderiza columna de botones (push button, image, or link)
CheckBoxField Renderiza Booleanos como check boxes
CommandField Renderiza controles para seleccionar y editar datos de GridView
HyperLinkField Renderiza columnas de hyperlinks
ImageField Renderiza columnas de imágenes
TemplateField Renderiza columnas usando plantillas HTML
ASP.NET 2.0
47. Control DetailsView
Renderiza registros individuales
En conjunto con GridView para las vistas master-
detail
O uso sin GridView para mostrar registros
individuales
Paginado, altas, actualización y borrado incorporados
Utiliza los mismos tipos de campo que GridView
Declarado en elementos <Fields>
UI altamente personalizable
ASP.NET 2.0
49. Alta, Actualización, y Borrado
Los controles de datos proveen UIs
editables
Propiedades AutoGenerateXxxButton
Propiedades Insert/EditRowStyle
Controles de Data source proveen lógica de
edición
Propiedades Insert/Update/DeleteCommand
Propiedades Insert/Update/DeleteParameters
Eventos Inserting/ed, Updating/ed, Deleting/ed
ASP.NET 2.0
Client-side event procedures son eventos que son administrados sobre la computadora que peticiona el Web Form (el cliente). Cuando un evento es generado, la información no es enviada al servidor. En su lugar, el explorador del cliente interpreta el código y también realiza la acción. Además, Client-side event procedures nunca tienen acceso a los recursos del servidor. Por ejemplo, no se puede utilizar un client-side script para acceder a una base de datos SQL. Client-side event procedures son muy útiles para eventos que usted quiere que ocurran inmediatamente, porque no requiere el acceso al Web Server (enviando información al servidor Web y esperando una respuesta). Por ejemplo, usted desea validar información en un text box antes de acceder a un servidor. Usted puede usar client-side script para validar información rápida y efectivamente antes de enviar información al Web Server para que sea procesada. Para especificar que el evento ocurra del lado del cliente puede utilizar el siguiente código: <SCRIPT language=“javascript”>
A diferencia de los Client-side event procedures, Server-side event procedures requiere de información para ser enviada al Web Server para ser procesada. Aunque hay un costo en tiempo usando Server-side event procedures, estos son mas poderosos que Client-side event procedures. Server-side event procedures consiste de código compilado que reside sobre el Web Server. Server-side event procedures puede ser usado para administrar eventos que son generados desde controles Web y HTML. Server-side event procedures tienen acceso a recursos de servidor que normalmente no están disponibles para Client-side event procedures. Usted puede utilizar Server-side event procedures especificando el atributo runat=“server” en el script tag. En ejemplo de esto podría ser: <SCRIPT language=“vb” runat=“server”> Porque Server-side event procedures requieren de envió de información al Web Server, hay un numero limitado controles de eventos que son soportados.
Cuando una pagina ASP.NET es pedida, hay una serie de eventos que ocurren. Estos eventos siempre ocurren en el mismo orden, los cuales están referidos como ciclos de vida de la pagina. El ciclo de vida de la pagina ocurren en el siguiente orden: Page_Init : este evento de pagina inicializa la pagina creando e inicializando los Web Server controls sobre la pagina. Page_Load : este evento de pagina ocurre cada vez que la pagina es peticionada Control events : este evento de pagina incluye los eventos change (por ejemplo, TextBox1_Changed) y los eventos action (por ejemplo: Button1_Click) Page_unload : este evento de pagina ocurre cuando la pagina es cerrada o cuando el control es pasado a otra pagina. El final del ciclo de vida de la pagina incluye la descarga de la pagina de memoria. La mayoría de los eventos no ocurren hasta que el Web Form realiza un postback al servidor. Por ejemplo, el evento Change es administrado en un orden aleatorio sobre el servidor después que el formulario es posteado. Inversamente, los eventos Click pueden causar el envió inmediato al servidor. Si, por ejemplo, un usuario ingresa texto en un numero de controles sobre un formulario y luego hace un clic en el botón Submit, el evento Change para los controles TextBox no serán procesados hasta que el formulario sea enviado al servidor a través del evento Click
En ASP.NET, los formularios son diseñados para enviar información al servidor para ser procesada. Este proceso es llamado postback. Postbacks deberían ocurrir con ciertas acciones de los usuarios. Por defecto, solo el evento clic de un botón causa que el formulario realice un postback al servidor. Sin embargo, si usted configuro la propiedad AutoPostBack de un control a True, el postback es forzado para eventos del control.
Una aplicación Web con ASP.NET contiene diferentes partes y componentes. La creación de aplicaciones Web con ASP.NET involucra el uso y trabajo con estas partes y componentes. Las partes que una aplicación Web con ASP.NET incluyen son las siguientes: Web forms o paginas aspx : los Web forms o paginas aspx proveen la UI para la aplicación Web. Paginas Code-behind : son paginas asociadas con Web Forms y contienen el código Server-side para el Web form. Archivos de configuración : son archivos XML que contienen la configuración por defecto para la aplicación Web y el servidor Web. Cada aplicación Web tiene un archivo de configuración llamado Web.config. Además cada servidor Web un archivo llamado machine.config Archivo Global.asax : dicho archivo contiene el código que necesita para responder a los eventos de aplicación que son levantados por ASP.NET Vínculos XML Web Service : estos vínculos permiten a la aplicación Web enviar y recibir datos desde un XML Web service. Conectividad de base de datos : permite a la aplicación Web transferir datos desde y hacia la base de datos Caching : permite a las aplicaciones retornar Web forms y datos mas rápidamente luego de la primer petición.
Cuando un cliente peticiona por primera vez una pagina Web, ocurren los siguientes eventos: El cliente desde su explorador emite una petición GET HTTP al servidor El parser de ASP.NET interpreta el código Si el código no esta actualmente compilado dentro de una librería (DLL), ASP.NET invoca al compilador El runtime carga y ejecuta el código intermedio (MSIL – Microsoft intermediate language) Cuando el cliente peticiona por segunda vez la misma pagina Web, lo siguiente ocurre: El cliente emite una petición GET HTTP al servidor Runtime carga e inmediatamente ejecuta el código MSIL que ya fu compilado durante la primer petición.
Las páginas de formularios Web Forms pueden usarse para crear páginas Web programables que sirvan como interfaz de usuario de las aplicaciones Web. Este tipo de páginas presenta la información al usuario en cualquier explorador o dispositivo cliente e implementa lógica de aplicación mediante el código de la parte servidor. La salida de las páginas de formularios Web Forms puede contener casi cualquier lenguaje compatible con HTTP, incluidos HTML, XML, WML y ECMAScript (JScript, JavaScript). Las páginas de formularios Web Forms reúnen las siguientes características: Se basan en la tecnología Microsoft ASP.NET, en la que el código que se ejecuta en el servidor genera de forma dinámica salida de páginas Web en un explorador o dispositivo cliente. Para obtener información detallada sobre ASP.NET, vea Información básica sobre tecnología ASP.NET . Compatible con cualquier explorador o dispositivo móvil. Las páginas de formularios Web Forms presentan automáticamente el código HTML adecuado al explorador para funciones tales como estilos, diseño, etc. Como alternativa, se pueden diseñar las páginas de formularios Web Forms para ejecutarse en un explorador determinado, como Microsoft Internet Explorer 5 y aprovechar así todas las funciones de un cliente de explorador de nivel superior. Admiten cualquier lenguaje compatible con Common Language Runtime de .NET, incluidos Microsoft Visual Basic, Microsoft Visual C# y Microsoft JScript.NET. Se crean en el entorno Microsoft .NET Framework. Esto proporciona todos los beneficios del marco de trabajo, incluidos un entorno administrado, seguridad de tipos y herencia. Respaldadas en Visual Studio por eficaces herramientas de desarrollo rápido de aplicaciones (RAD, Rapid Application Development ) destinadas al diseño y la programación de los formularios. Extensibles mediante controles que proporcionan posibilidades RAD al desarrollo Web, lo que permite crear con rapidez interfaces de usuario enriquecidas. Flexibles gracias a la posibilidad de incorporar a ellas controles creados por los usuarios y de otros fabricantes. Componentes de los formularios Web Forms En las páginas de formularios Web Forms, la programación de la interfaz de usuario se divide en dos partes independientes: el componente visual y el lógico. Si ha trabajado con herramientas como Visual Basic y Visual C++ anteriormente, reconocerá esta división entre la parte visible de un formulario y el código que se oculta detrás y que interactúa con él. El elemento visual se conoce como la página de formularios Web Forms, y se compone de un archivo que contiene código HTML estático, o controles de servidor ASP.NET o ambos de forma simultánea. La página de formularios Web Forms funciona como un contenedor del texto y los controles estáticos que se desea mostrar. Si se usa el Diseñador de Web Forms de Visual Studio junto con controles de servidor ASP.NET, se pueden diseñar los formularios igual que se haría en cualquier aplicación de Visual Studio. Para obtener más información, vea Controles que se pueden usar en páginas de formularios Web Forms . La lógica de las páginas de formularios Web Forms se compone del código creado para interactuar con el formulario. La lógica de programación reside en un archivo independiente del archivo de la interfaz de usuario. Este archivo se conoce como el archivo de "código subyacente" y adopta la extensión ".aspx.vb" o ".aspx.cs". La lógica escrita en el archivo de código subyacente puede estar en Visual Basic o en Visual C#. Los archivos de código subyacente de todas las páginas de formularios Web Forms de un proyecto se compilan en el archivo de biblioteca de vínculos dinámicos (.dll) del proyecto. El archivo de página .aspx también se compila, pero de un modo distinto. La primera vez que un usuario examina la página .aspx con el explorador, ASP.NET genera automáticamente un archivo de clase .NET que representa a la página y que la compila en un segundo archivo .dll. La clase generada para la página .aspx hereda de la clase del código subyacente que se compiló en el archivo .dll del proyecto . Cuando un usuario solicita la dirección URL de la página Web, los archivos .dll se ejecutan en el servidor y producen de forma dinámica la salida HTML de la página. Para obtener más información, vea Procesamiento de páginas de formularios Web Forms . Para obtener más información sobre cómo se construyen las páginas de formularios Web Forms, vea Modelo de código de formularios Web Forms. Ventajas que aportan las páginas de formularios Web Forms La programación de aplicaciones Web presenta retos que no surgen normalmente en la programación tradicional de aplicaciones basadas en clientes. Entre estos retos se encuentran los siguientes: Implementar una interfaz de usuario Web enriquecida. Una interfaz de usuario con un diseño complejo, una gran cantidad de contenido dinámico y llena de objetos interactivos y plenos de funcionalidad puede resultar difícil y tediosa de diseñar e implementar si se utilizan herramientas HTML básicas. Resulta particularmente difícil crear una interfaz de usuario enriquecida para aplicaciones que deban ejecutarse en muchos exploradores y plataformas de dispositivos clientes distintos. Separación entre cliente y servidor. En las aplicaciones Web, el cliente (explorador) y el servidor son programas distintos que a menudo se ejecutan en equipos distintos e, incluso, en sistemas operativos diferentes. Por lo tanto, las dos mitades de la aplicación comparten muy poca información; se pueden comunicar, pero normalmente intercambian sólo pequeñas porciones de información simple. Ejecución independiente. Cuando un servidor Web recibe una petición de una página, la busca, la procesa y la envía al explorador y, a continuación, desecha toda la información sobre dicha página. Si el usuario solicita la página de nuevo, el servidor repite la secuencia completa, volviendo a procesar la página desde el principio. En otras palabras, los servidores no tienen memoria de las páginas que han procesado. Por lo tanto, si una aplicación necesita mantener información sobre una página, esto se convierte en un problema que tiene que resolverse en el código de la aplicación. Posibilidades desconocidas del cliente. En muchos casos, las aplicaciones Web resultan accesibles a usuarios que poseen exploradores de distintos fabricantes y que, por tanto, ofrecen distinta funcionalidad, lo que hace muy difícil crear una aplicación que se ejecute con la misma calidad en todos ellos. Complicaciones con el acceso a los datos. La lectura de los datos de un origen de datos y la escritura en el mismo puede resultar complicada con las aplicaciones Web tradicionales y hacer un gran uso de los recursos. Complicaciones con la escalabilidad. En muchos casos las aplicaciones Web diseñadas con los métodos existentes no pueden cumplir los objetivos de escalabilidad debido a la falta de compatibilidad entre sus distintos componentes. Este es a menudo el único origen de los errores en aplicaciones sometidas a un ciclo de crecimiento intenso. Atajar estos retos de las aplicaciones Web puede requerir un tiempo y esfuerzo importantes. Las páginas de formularios Web Forms y el marco de trabajo de páginas ASP.NET tratan de solucionar estos temas de los modos siguientes: Modelo de objetos coherente e intuitivo. El marco de trabajo de páginas ASP.NET presenta un modelo de objetos que permite concebir los formularios como una unidad, no como partes cliente y servidor independientes. En este modelo, se puede programar el formulario de un modo más intuitivo que en las aplicaciones Web tradicionales, ya que se incluye la capacidad de establecer las propiedades de los elementos del formulario y de responder a los eventos. Además, los controladores de servidor ASP.NET son una abstracción del contenido físico de una página HTML y de la interacción directa entre el explorador y el servidor. En general, se pueden usar los controles de servidor del mismo modo que se haría con los controles en una aplicación cliente, pero sin tener que preocuparse por crear el código HTML para presentar y procesar los controles y su contenido. Modelo de programación controlado por eventos. Las páginas de formularios Web Forms aportan a las aplicaciones Web un modelo familiar que permite escribir controladores para los eventos que se producen en el cliente o en el servidor. El marco de trabajo de páginas ASP.NET compendia este modelo de tal modo que el mecanismo subyacente de captura de los eventos en el cliente, su transmisión al servidor y la llamada al método apropiado se realiza de modo automático e invisible para el implementador. El resultado es una estructura de código clara y escrita con facilidad, compatible con el desarrollo controlado por eventos. Administración intuitiva de los estados. El marco de trabajo de páginas ASP.NET gestiona automáticamente las tareas de mantenimiento del estado del formulario y sus controles, y proporciona modos explícitos de mantener el estado de la información específica a la aplicación. Esto se logra sin una utilización abusiva de los recursos del servidor y puede implementarse tanto enviando como no enviando cookies al explorador. Aplicaciones independientes del explorador. El marco de trabajo de páginas ASP.NET permite crear toda la lógica de la aplicación en el servidor, lo que elimina la necesidad de confeccionar código explícito para las diferencias de los exploradores. Sin embargo, facilita el aprovechamiento automático de las funciones específicas de cada explorador al escribir código para la parte cliente con el fin de mejorar el rendimiento y de proporcionar una experiencia más enriquecedora en la parte cliente. Compatibilidad con Common Language Runtime de .NET Framework. El marco de trabajo de páginas ASP.NET es una tecnología de ASP.NET. ASP.NET se basa en .NET Framework, por lo que todo el marco de trabajo está disponible para cualquier aplicación ASP.NET. Las aplicaciones pueden crearse en cualquier lenguaje compatible con CLR, entre ellos Microsoft Visual Basic, Visual C# y JScript .NET. Además, el acceso a datos se ha simplificado mediante la infraestructura de acceso a datos que ofrece .NET Framework, incluido ADO.NET. Rendimiento de servidor escalable de .NET Framework. El marco de trabajo de páginas ASP.NET permite escalar las aplicaciones Web de un equipo con un único procesador a una "batería de servidores Web" con varios equipos limpiamente y sin cambios complicados en la lógica de la aplicación.
El web.config sirve para configurar la aplicación ASP.NET o parte de ella. Puede existir un web.config en cada carpeta de la aplicación y configurará opciones para todas las subcarpetas de la misma, a menos que exista un web.config que en alguna de ellas, que sobrescriba los valores definidos por el web.config exterior. Normalmente se tiene un web.config en el root del site ASP.NET. En el web.config de definen los roles de acceso, membresías, conexión a base de datos y las variables propias de la aplicación entre otras configuraciones. En tiempo de ejecución se pueden obtener los valores aquí definidos, mediante las clases que forman parte de la librería del Framework y se encuentran en el namespace System.Configuration .
Para crear nuevos Web forms en aplicaciones ASP.NET nuevas, es muy sencillo : En la pagina de inicio de Visual Studio .NET, clic en nuevo proyecto En la caja de diálogos del proyecto nuevo, ingrese el nombre del nuevo proyecto y luego clic en OK Visual Studio crea una nueva aplicación Web y un Web Form llamado WebForm1.aspx Creación de nuevos Web Forms a un proyecto existe : En el Explorador de Soluciones, clic derecho en el nombre del proyecto Luego clic en Agregar Web Form, ingresar el nombre del nuevo Web form y clic en OK Actualizar paginas HTML existentes : En el explorador de soluciones, clic derecho sobre el proyecto, posicionarse en Agregar, y luego en Agregar Elemento existente En la caja de diálogos de Nuevo Elemento Existente, posicionarse en donde se encuentra el archivo HTML, y clic en abrir. Renombrar el archivo nombre.htm a nombre.aspx y clic en SI, cuando aparezca la advertencia de cambio de extensión. Cuando se le pregunta por la creación de un archivo de clases, se debe aprobar.
ASP.NET provee dos modelos para administrar los elementos visuales y el código – un modelo single-file y otro modelo llamado code-behind. Los dos modelos funcionan iguales y usted puede usar los mismos controles y códigos en ambos modelos. En el modelo single-file, el HTML y el código de programación se almacena en el mismo .aspx. El código de programación es un bloque que contiene el atributo runat=“server”, para marcar al código como código ejecutable por ASP.NET En el modelo code-behind, el HTML esta en un archivo .aspx y el código de programación en otro archivo .aspx. En la versión 2.0, hay cambios significativos que hacen que el modelo code-behind sea mas robusto y mas fácil de trabajar.
El modelo code-behind para el .NET Framework 2.0 toma ventaja de una nueva característica llamada Partial Classes. El archivo code-behind para la pagina no posee la definición completa de la clase. En su lugar, este incluye solo lo que sea necesario. El code-behind partial class no necesita instanciar variables o eventos explícitamente. El vinculo entre el archivo .aspx y el archivo code-behind es similar al vinculo usado en el anterior modelo code-behind. Sin embargo, la directiva @ Page usa un nuevo atributo “CodeFile” en lugar del atributo “Code-behind” o “Src”. Además, la directiva incluye un atributo de herencia para especificar una class name para la pagina.
El modelo code-behind introducido en el .NET Framework 2.0 ofrece nuevas mejoras que la versión anterior: El archivo code-behind es mas simple. Este incluye solo el código escrito por usted mismo y casi ningún código generado. El archivo code-behind solo incluye el código que es necesario para soportar al diseño implementado. Usted puede incluir controles de usuarios sin tener que crear variables instanciadas explícitamente para el code-behind class. La pagina code-behind no puede ser sincronizado con los controles declarado en el HTML. Porque los eventos pueden ser deducidos desde los controles declarados, usted no necesita declarar nada en el método reservado InitializeComponent. Nota: Si usted esta creando controles y agregándolos a la pagina, usted necesita mantener vínculos explícitamente creados. El modelo code-behind crea controles con instancias y eventos solo para los controles que están declarados en el HTML Mejor separación de código y contenido El nuevo modelo de code-behind hace mas fácil la separación del código y del HTML. En el modelo anterior de code-behind, no era practico agregar controles en el HTML sin tener que acceder al code-behind para agregar una variable instanciada al mismo tiempo. En el nuevo modelo usted puede crear paginas en capas sin necesitar tener que acceder a la pagina de code-behind
Los controles de servidor de ASP.NET heredan de Control una propiedad denominada ViewState que les permite participar fácilmente en el mantenimiento del estado. El tipo de ViewState es System.Web.UI.StateBag, que es un diccionario en el que se almacenan pares de nombre y valor. El área de trabajo de la página ASP.NET conserva ViewState en una variable de cadena que se envía al cliente y se recibe de vuelta de él como variable oculta. Cuando se produce la devolución, el área de trabajo de la página analiza la cadena de entrada de la variable oculta y establece la propiedad ViewState de cada control. Si en lugar de un campo privado un control utiliza ViewState para datos de propiedad, la propiedad se conservará automáticamente entre los trayectos de ida y vuelta hacia el cliente. Si una propiedad no se conserva en ViewState , es recomendable especificar su valor predeterminado en la devolución. Los programadores de controles deben tener en cuenta que todos los datos contenidos en ViewState recorren automáticamente un trayecto de ida y vuelta hasta el cliente. Estos trayectos suponen una carga adicional para el rendimiento, por lo que es importante hacer un uso razonable de ViewState . Si varias propiedades dependen de datos comunes, para optimizar el rendimiento puede conservar en ViewState únicamente los elementos clave. Cada control hereda de Control una propiedad denominada EnableViewState que permite a sus consumidores habilitar o deshabilitar la conservación de su ViewState .
Enviar gran cantidad de datos a través de Internet puede generar grandes problemas en los tiempos y en el ancho de banda. Para solucionar estos problemas tenemos algunas opciones: Deshabilitar el View State de los controles Web que sean necesarios configurando la propiedad EnableViewState en falso. Deshabilitar el View State para la pagina entera configurando la propiedad EnableViewState a falso en al directiva @Page. Guardar el View State en el servidor en lugar de ocultarlo en campo de formularios.
En un alto nivel de abstracción, control state y view state son similares. En ASP.NET 2.0, una de las mayores diferencias es que el control administra el control state. Las configuraciones a nivel aplicación o pagina no pueden afectar la estructura, el almacenamiento o la disponibilidad del control state. El control state es el private view state del control. El control state reemplaza el private view del view state. Pocos controles de servidor hacen un uso privado del view state y hay algunas limitaciones en algunas características particulares. El private use del view state ocurre cuando un control almacena el contenido de propiedades no publicas en el view state. La aplicación no puede acceder a dichas propiedades por el nivel de protección y no puede restaurar los valores almacenados. Almacenando las propiedades internas en el view state, el control usa al view state en forma privada. Cuando el view state esta deshabilitado, esta acción se torna peligrosa.
Un session state es definido como un periodo de tiempo en el cual un usuario interactúa con la aplicación Web. En ASP.NET 2.0, usted puede definir almacenes de datos personalizados para el session state. Por ejemplo, si usted necesita robustecer una solución de base de datos, pero trabaja con Oracle, no necesita instalar SQL Server, puede soportar la sesión de datos de Oracle mientras esté usando la misma sesión, semántica y clases. El nuevo modelo extensible del session state ofrece dos opciones: modificación de pequeños mecanismos del ASP.NET session state y el reemplazo del anterior modulo de session state HTTP por uno nuevo. Usted puede personalizar y adaptar cuatro aspectos en el modulo del session state: data store, session state ítem, data dictionary, y session ID. Por este propósito, ASP.NET 2.0, introduce nuevos atributos y elementos en la sesión <sessionstate> del archivo web.config.
ASP.NET 1.x introduce un nuevo contenedor llamado cache, el cual esta unido a otros dos contenedores clásicos de ASP: application y session. Cache es una tabla hash usada para almacenar los datos accedidos frecuentemente. La clase CacheDependency puede representar un único archivo o carpeta, o un conjunto de archivos o capetas, o un conjunto de items almacenados a un ítem en particular en la cache. Para establecer una dependencia entre un ítem almacenado y un componente externo, usted agrega el ítem usando el método Insert. El ítem agregado es removido desde la cache cuando el archivo especificado cambia. El tiempo de vida de los objetos en la cache puede ser administrada a través de un timestamp. Cuando un archivo o directorio es modificado, o movido o eliminado un cambio en el sistema de archivos es detectado y el ítem almacenado es marcado como obsoleto y removido de la memoria. Una dependencia de archivos esta basada en un monitor de archivos – una instancia de la clase FileSystemWatcher. La mayor diferencia entre la dependencia de la cache entre la versión ASP.NET 1.x y ASP.NET 2.0 es el soporte para dependencia de cache personalizable que posee ASP.NET 2.0. Para el manejo de dependencias personalizables, la clase CAcheDependency en ASP.NET 2.0 no es mas marcada como cerrada.
Controles de usuarios : los controles de servidor ASP.NET proveen una gran cantidad de funcionalidades, pero estos no cubren todas las situaciones. Web User Controls lo habilita a definir controles de una manera muy sencilla para sus aplicaciones, utilizando la misma forma de programación que utiliza para escribir paginas Web. Usted puede convertir una pagina Web Form en un Web user control con pocas modificaciones. Para asegurarse que el user control no puede ser corrido como un simple Web Forms, los user controls son identificados por la extensión de archivo .ascx. Custom controls : los controles personalizados son componentes compilados que corren en el servidor y que encapsulan la información de los usuarios y/o objetos para que sean reutilizables. Los custom controls incluyen todas las características de los controles de servidores ASP.NET, incluyendo un completo soporte para las nuevas características de Visual Studio como las propiedades de ventanas, barra de herramientas, etc.
Cuando cree páginas de formularios Web Forms, puede utilizar estos tipos de controles: Controles de servidor HTML. Elementos HTML expuestos al servidor para que se puedan programar. Los controles de servidor HTML exponen un modelo de objeto que se relacionan muy estrechamente con los elementos HTML que procesan. Controles de servidor Web. Controles con más funciones incorporadas que los controles de servidor HTML. Los controles de servidor Web incluyen no sólo controles de tipo formulario como botones y cuadros de texto, sino también controles con fines especiales como un calendario. Los controles de servidor Web son más abstractos que los controles de servidor HTML pues su modelo de objetos no refleja necesariamente la sintaxis HTML. Controles de servidor HTML Los controles de servidor HTML son elementos HTML que contienen atributos que los hacen visibles (y programables) en un servidor. De forma predeterminada, el servidor no tiene acceso a los elementos HTML de una página de formularios Web Forms: se tratan como texto opaco que se pasa al explorador. Sin embargo, cuando se convierten en controles de servidor HTML, los elementos HTML quedan expuestos como elementos programables en el servidor. El modelo de objetos de los controles de servidor HTML se relaciona estrechamente con el de los elementos correspondientes. Por ejemplo, los atributos HTML se exponen en controles de servidor HTML como propiedades. Cualquier elemento HTML de una página se puede convertir en control de servidor HTML. La conversión es un proceso simple que afecta a unos pocos atributos. Como mínimo, un elemento HTML se convierte en control agregando el atributo RUNAT="SERVER". Esto le indica al marco de trabajo de la página de ASP.NET durante el análisis que debe crear una instancia del control para su uso durante el procesamiento de la página en el servidor. Si desea hacer referencia al control como un miembro dentro del código, también deberá asignarle un atributo ID al control. El marco de trabajo de páginas proporciona controles de servidor HTML predefinidos para los elementos HTML que se utilizan más habitualmente de forma dinámica en una página: formularios, elementos HTML <INPUT> (cuadro de texto, casilla de verificación, botón Enviar, etc.), cuadros de lista (<SELECT>), tablas, imágenes, etc. Estos controles de servidor HTML predefinidos comparten las propiedades básicas del control genérico y, además, cada control normalmente proporciona su propio conjunto de propiedades y su propio evento. Los controles de servidor HTML ofrecen las funciones siguientes: Un modelo de objetos que pueda volver a programar en el servidor con las técnicas habituales orientadas a objetos. Los controles de servidor exponen propiedades que permiten manipular los atributos HTML del control mediante programación en el código del servidor. Un conjunto de eventos para los que pueda escribir controles de eventos de la misma forma que lo haría en un formulario basado en cliente, con la excepción de que un evento se controla en código del servidor. La capacidad de controlar eventos en una secuencia de comandos de cliente. Mantenimiento automático del estado del control. Si el formulario realiza una acción de ida y vuelta al servidor, los valores que el usuario escriba en los controles de servidor HTML se mantendrán automáticamente cuando la página se envíe de vuelta al explorador. Interacción con controles de validación que permiten comprobar con gran facilidad si el usuario ha escrito la información adecuada en un control. Enlace de datos a una o varias de las propiedades del control. Compatibilidad con estilos HTML 4.0 si la página de formularios Web Forms se muestra en un explorador que admite hojas de estilos en cascada. Paso a través de atributos personalizados. Pueden agregarse los atributos que se necesiten a un control de servidor HTML: el marco de trabajo de páginas los leerá y los procesará sin ningún cambio en la funcionalidad. Esto permite agregar atributos específicos del explorador a los controles. Controles de servidor Web Los controles de servidor Web son un segundo conjunto de controles diseñado con otro enfoque. No se asignan uno a uno a controles de servidor HTML. En lugar de ello, se definen como controles abstractos, en los que el HTML real procesado por el control puede ser muy diferente al modelo con respecto al que se han programado. Por ejemplo, un control RadioButtonList de servidor Web podría procesarse en una tabla o como un texto en línea con otro HTML. Los controles de servidor Web incluyen controles de formulario tradicionales como botones y cuadros de texto, además de controles complejos, como, por ejemplo, las tablas. También incluyen controles que proporcionan funcionalidad de formulario de uso frecuente, como la presentación datos en cuadrícula, la elección de fechas, etc. Los controles de servidor Web ofrecen todas las funciones descritas anteriormente para los controles de servidor HTML (excepto la asignación uno a uno a elementos HTML) y estas funciones adicionales: Un modelo de objetos enriquecido que proporciona capacidades de programación de tipo seguro. Detección automática del explorador. Los controles pueden detectar capacidades del explorador y crear el resultado apropiado para exploradores básicos y enriquecidos (HTML 4.0). Para algunos controles, la capacidad de definir su propia apariencia para el control mediante plantillas. Para algunos controles, la capacidad de especificar si un evento del control provoca un envío inmediato al servidor o, en su lugar, se almacena en caché y se activa cuando se envía el formulario. Capacidad para pasar eventos de un control anidado (como un botón en una tabla) al control contenedor. Cuando la vista HTML está en tiempo de diseño, los controles aparecen en la página con un formato como el siguiente: <asp:button attributes runat="server"/> En este caso los atributos no son los de los elementos HTML. En lugar de ello, son propiedades del control Web. Cuando se ejecuta la página de formularios Web Forms, el control de servidor Web se procesa en la página utilizando el HTML apropiado, que con frecuencia no sólo depende del tipo de explorador sino también de la configuración que haya realizado para el control. Por ejemplo, un control TextBox podría procesarse como una etiqueta <INPUT> o una etiqueta <TEXTAREA>, dependiendo de sus propiedades.
Debido a que los user control pueden simplificar la reutilización del código y de componentes comunes UI, entender que son y como trabajan es muy importante. Los user controls son paginas ASP.NET con extensión ascx. Similar a las paginas Web Forms, usted puede editar estos controles con cualquier editor de texto o desarrollarlo usando code-behind clases. También, de manera similar a las paginas Web Forms, user controls son compilados cuando son pedidos por primera vez, y almacenados en memoria del servidor para reducir el tiempo de respuesta para peticiones sucesivas. A diferencia de la paginas Web Forms, los user control no pueden ser peticionados independientemente, deben ser incluidos en Web Forms para poder funcionar
Debido a que los user control pueden simplificar la reutilización del código y de componentes comunes UI, entender que son y como trabajan es muy importante. Los user controls son paginas ASP.NET con extensión ascx. Similar a las paginas Web Forms, usted puede editar estos controles con cualquier editor de texto o desarrollarlo usando code-behind clases. También, de manera similar a las paginas Web Forms, user controls son compilados cuando son pedidos por primera vez, y almacenados en memoria del servidor para reducir el tiempo de respuesta para peticiones sucesivas. A diferencia de la paginas Web Forms, los user control no pueden ser peticionados independientemente, deben ser incluidos en Web Forms para poder funcionar
Debido a que los user control pueden simplificar la reutilización del código y de componentes comunes UI, entender que son y como trabajan es muy importante. Los user controls son paginas ASP.NET con extensión ascx. Similar a las paginas Web Forms, usted puede editar estos controles con cualquier editor de texto o desarrollarlo usando code-behind clases. También, de manera similar a las paginas Web Forms, user controls son compilados cuando son pedidos por primera vez, y almacenados en memoria del servidor para reducir el tiempo de respuesta para peticiones sucesivas. A diferencia de la paginas Web Forms, los user control no pueden ser peticionados independientemente, deben ser incluidos en Web Forms para poder funcionar
Para agregar un control de usuarios, primero debemos ingresar a un proyecto nuevo o uno existente. Sobre el Menu Project, clic en Add Web User Control. Agregue el texto y los controles que sean necesarios. Cualquier control que usted quiera que este disponible para acceder desde programación debería ser un control Web Forms o HTML Server Use el Web Form Designer para configurar propiedades y crear el código necesario para su control.
Agregar controles de usuario a una página de formularios Web Forms Para agregar controles de usuario Web a páginas de formularios Web Forms en la vista Diseño sencillamente arrastre el control desde el Explorador de soluciones y colóquelo en el lugar de la página donde desee que aparezca. El Diseñador de Web Forms agrega automáticamente a la página una directiva @ Register y una etiqueta para el control. A partir de este punto, los controles se convierten en parte de las páginas y aparecen representados cuando éstas se procesan. Asimismo, los eventos, propiedades y métodos públicos del control se exponen a la página pueden manipularse mediante programación. También pueden agregarse controles de usuario a una página mediante programación Nota El control de usuario debe estar en el mismo proyecto que la página de formularios Web Forms. Para agregar un control de usuario a una página de formularios Web Forms En el Diseñador de Web Forms, abra la página a la que desee agregar el control y asegúrese de que la página está en la vista Diseño. En el Explorador de soluciones, seleccione el archivo del control de usuario y arrástrelo a la página. Para agregar un control de usuario a una página de formularios Web Forms en la vista HTML En el diseñador de formularios Web Forms, abra la página a la que desee agregar el control y, a continuación, cambie a la vista HTML. En la parte superior de la página, antes de la etiqueta <HTML>, agregue una directiva que registre el control de forma que sea reconocido cuando ésta se procese. Esta directiva se usa para asociar un nombre y un espacio de nombres con el control de usuario Web especificando los valores de ubicación TagPrefix , TagName y Src . Por ejemplo: <%@ Register TagPrefix="uc1" TagName="menu" Src="menu.ascx" %> Sitúe la directiva en su propia línea. Si no hay más directivas, haga que ésta sea la primera línea del archivo. En la parte <BODY> del archivo, cree una etiqueta para el control en la ubicación en la que desee que éste aparezca. Utilice los valores TagPrefix y TagName que registró en el paso 2. Asigne una identificación (id.) al control y establezca el atributo runat=server, como en el ejemplo siguiente: <uc1:menu id="Menu1" runat="server"/> Si el control tiene propiedades que se puedan establecer en tiempo de diseño, y así lo desea, establézcalas declarando sus valores en la etiqueta: <uc1:menu id="Menu1" runat="server" enabled=true /> Siga diseñando el resto de la página de formularios Web Forms. Si le resulta más cómodo, cambie a la vista Diseño para trabajar con la página. En ella, se mostrará el control de usuario mediante un glifo que indica su localización, pero no se mostrará una representación WYSIWYG en el diseñador. Para editar el control, vuelva a la vista HTML.
Los controles Web personalizados son componentes compilados que se ejecutan en el servidor, y que encapsulan la interfaz de usuario y el resto de la funcionalidad relacionada en paquetes reutilizables. Pueden incluir todas las funciones de tiempo de diseño de los controles de servidor ASP.NET estándar, incluida la total compatibilidad con las funciones de diseño de Visual Studio, como la ventana Propiedades, el diseñador visual y el Cuadro de herramientas. Hay varias formas de crear controles Web personalizados: Se puede compilar un control que combine la funcionalidad de dos o más controles existentes. Por ejemplo, si se necesita un control que encapsule un botón y un cuadro de texto, se puede crear compilando los controles existentes en uno. Para obtener más información, vea Desarrollar un control compuesto. Si un control de servidor existente casi reúne los requisitos pero le faltan algunas funciones, se puede personalizar creando un derivado suyo y sobrescribiendo sus propiedades, métodos y eventos. Si ninguno de los controles de servidor Web existente (ni sus combinaciones) cumplen los requisitos necesarios, se puede crear un control personalizado derivado de una de las clases de controles básicas. Estas clases proporcionan toda la funcionalidad básica de los controles de servidor Web para que el usuario se pueda concentrar en programar las funciones necesarias. Nota de seguridad: En Visual Studio, en tiempo de diseño, el código siempre se ejecuta con plena confianza, aunque pueda incluirse finalmente en un proyecto donde quizá no reciba una confianza tan plena durante la ejecución. Es decir, un control personalizado podría funcionar perfectamente durante las pruebas en el equipo del programador, pero podría dar errores a causa de la falta de los permisos adecuados en una aplicación implementada. Compruebe siempre los controles en el contexto de seguridad donde se ejecutarán en las aplicaciones reales.
Los controles Web personalizados son componentes compilados que se ejecutan en el servidor, y que encapsulan la interfaz de usuario y el resto de la funcionalidad relacionada en paquetes reutilizables. Pueden incluir todas las funciones de tiempo de diseño de los controles de servidor ASP.NET estándar, incluida la total compatibilidad con las funciones de diseño de Visual Studio, como la ventana Propiedades, el diseñador visual y el Cuadro de herramientas. Hay varias formas de crear controles Web personalizados: Se puede compilar un control que combine la funcionalidad de dos o más controles existentes. Por ejemplo, si se necesita un control que encapsule un botón y un cuadro de texto, se puede crear compilando los controles existentes en uno. Para obtener más información, vea Desarrollar un control compuesto. Si un control de servidor existente casi reúne los requisitos pero le faltan algunas funciones, se puede personalizar creando un derivado suyo y sobrescribiendo sus propiedades, métodos y eventos. Si ninguno de los controles de servidor Web existente (ni sus combinaciones) cumplen los requisitos necesarios, se puede crear un control personalizado derivado de una de las clases de controles básicas. Estas clases proporcionan toda la funcionalidad básica de los controles de servidor Web para que el usuario se pueda concentrar en programar las funciones necesarias. Nota de seguridad: En Visual Studio, en tiempo de diseño, el código siempre se ejecuta con plena confianza, aunque pueda incluirse finalmente en un proyecto donde quizá no reciba una confianza tan plena durante la ejecución. Es decir, un control personalizado podría funcionar perfectamente durante las pruebas en el equipo del programador, pero podría dar errores a causa de la falta de los permisos adecuados en una aplicación implementada. Compruebe siempre los controles en el contexto de seguridad donde se ejecutarán en las aplicaciones reales.
Los controles Web personalizados son componentes compilados que se ejecutan en el servidor, y que encapsulan la interfaz de usuario y el resto de la funcionalidad relacionada en paquetes reutilizables. Pueden incluir todas las funciones de tiempo de diseño de los controles de servidor ASP.NET estándar, incluida la total compatibilidad con las funciones de diseño de Visual Studio, como la ventana Propiedades, el diseñador visual y el Cuadro de herramientas. Hay varias formas de crear controles Web personalizados: Se puede compilar un control que combine la funcionalidad de dos o más controles existentes. Por ejemplo, si se necesita un control que encapsule un botón y un cuadro de texto, se puede crear compilando los controles existentes en uno. Para obtener más información, vea Desarrollar un control compuesto. Si un control de servidor existente casi reúne los requisitos pero le faltan algunas funciones, se puede personalizar creando un derivado suyo y sobrescribiendo sus propiedades, métodos y eventos. Si ninguno de los controles de servidor Web existente (ni sus combinaciones) cumplen los requisitos necesarios, se puede crear un control personalizado derivado de una de las clases de controles básicas. Estas clases proporcionan toda la funcionalidad básica de los controles de servidor Web para que el usuario se pueda concentrar en programar las funciones necesarias. Nota de seguridad: En Visual Studio, en tiempo de diseño, el código siempre se ejecuta con plena confianza, aunque pueda incluirse finalmente en un proyecto donde quizá no reciba una confianza tan plena durante la ejecución. Es decir, un control personalizado podría funcionar perfectamente durante las pruebas en el equipo del programador, pero podría dar errores a causa de la falta de los permisos adecuados en una aplicación implementada. Compruebe siempre los controles en el contexto de seguridad donde se ejecutarán en las aplicaciones reales.
XML-HTTP callbacks, o client callbacks, son mas eficientes que postback por dos razones. Una, la pagina no es renderizada (la pagina procesa un stop antes del evento PreRender). Segundo, los formularios no son aprobados, lo cual significa que ni la información ingresada en el formulario ni el estado de la vista actual son transmitidas al servidor como un full-blown postback. Mientras que el Internet Explorer soporta callbacks sincrónicos y asincrónicos, ASP.NET 2.0’s client callbacks manager siempre trabaja con callbacks asincrónicos
El primer paso en la mejora del rendimiento de un client callback es la llamada al método GetCallBackEventReference para obtener el nombre de la función del lado del cliente que puede ser llamada para inicializar un callback. Entonces usted llama a la función del lado del cliente (utilizando un script de lado cliente), el cual se conecta con ASP.NET’s callback manager, el cual esta implementado en el lado del cliente, para conectarse con XML-HTTP callback al servidor. ASP.NET notifica a la pagina que un callback a llegado por medio del método ICallbackEventHandler.RaiseCallbackEvent. RaiseCallbackEvent procesa el callback y lo retorna.
Comprender el funcionamiento y la versatilidad de los XML-HTTP CallBacks. Ver en una aplicación sencilla como solo una parte de la página refresca información a partir de un pedido de un usuario. La aplicación muestra un drop-down list de empleados. Al hacer click en el botón “Traer Datos” se obtiene un label que informa el Id del usuario seleccionado, utilizando el sistema de CallBack. Pasos Abrir el website que se encuentra en ClientCallback. Asegurarse que el connection string del método PopulateList apunta a un SQL Server donde se cuenta con la base NorthWind. Ejecutar la demo, mostrando los resultados. Utilizar IE 5 o superior. Mostrar en primer lugar la página ASP.NET, luego el code behind y finalmente el callback.js. Hacer hincapié en el método WebForm_DoCallback Revisar la forma en la que se llama al callback desde la pagina, con el código javascript y el uso de XML-HTTP.
ASP.NET 2.0 permite construir visualizaciones de datos de una manera mas sencilla que su antecesor introduciendo la utilización de nuevos controles de datos (los cuales reducen notoriamente la cantidad de código que se debe ingresar), como por ejemplo los GridView y DatailsView.
Gracias a la habilidad del control SQLDataSource para peticionar datos y relacionarlo con un control, no es necesario escribir código. Además de hacer peticiones a la base de datos, SqlDataSource puede tamben actualizar los datos. Esto no es restrictivo para bases de datos de SQL Server, el control puede generar vínculos con cualquier base de datos para la cual exista un provider. SqlDataSource es parte de una nueva familia de controles de acceso a datos. Otro miembro notable de la familia es ObjectDataSource, el cual habilita el nivel de control y acceso a los componentes de datos. Otras de las posibilidades es que SqlDataSource puede llamar a un stored procedure y utilizar consultas con parámetros, y la conexión no tiene que ser almacenada en el archivo aspx o en texto plano. Una nueva sintaxis declarativa permite a una propiedad del control ConnectionString hacer referencia una conexión en la nueva sección <connectionStrings> de Web.config y dicha sección puede ser opcionalmente encriptada. En este ejemplo, la conexión es hard-code dentro del archivo ASPX. En la practica, usted debería poner el connection string en la nueva sección <connectionString> dentro del archivo Web.config y cargarlo con el signo $.
SqlDataSource implementa un conjunto de propiedades publicas listas para su utilización, algunas de estas propiedades podrían ser: SelectCommand el cual define peticiones que el SqlDataSource usa para traer datos desde la base de datos, mientras que InsertCommand, UpdateCommand y DeleteCommand definen comandos para usar durante una actualización de la base de datos.
Los controles Data Source deberían tener valores limitados si SelectCommand, InsertCommand y DeleteCommand no pudiesen ser parametrizados. Un buen ejemplo es el caso donde la información mostrada a través de un GridView depende del valor selecciona desde un DropDownList. En este caso, el SqlDataSource completa al GridView desde un SelectCommand que contenga la cláusula WHERE con que el se reemplacen parámetros los cuales serán obtenidos desde el DropDownList. Afortunadamente, este escenario es soportado, lo cual significa que el control SqlDataSource pueda realizar consultas complejas con los parámetros SELECTs, INSERTs, UPDATEs, y DELETEs. Las propiedades SelectParameters, InsertParameters, UpdateParameters, y DeleteParameters proveen una manera amigable de agregar parámetros a los SelectCommand, InsertCommand, UpdateCommand, y DeleteCommand. FilterParameters define parámetros para SqlDataSource.FilterExpression. FilterExpression filtra los datos devueltos por SelectCommand. Nótese que FilterExpression no es diferente que incluir la cláusula WHERE en el SelectCommand. Sin embargo, FilterExpression trabaja solo si SqlDataSource esta haciendo caching de los resultado peticionados.
Este ejemplo usa los valores de los ítems actualmente seleccionados en una lista drop-down para completar un parámetro en un Select. Note que el elemento <SelectParameters> agrega elementos a SelectCommand y el elemento <asp:ControlParameter> correspondiente al parámetro @Country en el SelectCommand. Si SelectCommand contiene parámetros adicionales, <SelectParameter> debería contener elementos adicionales <asp:xxxParameter>. Una pregunta común es si el control SqlDataSource puede utilizar Stored Procedure, y las respuesta es que si. Ambos SelectCommand deberían ser reemplazados por SP. Uno de los SP no tiene parámetros y el otro tiene el parámetro Select.
xmlDataSource es una funcionalidad similar a SqlDataSource pero esta diseñada para leer datos desde orígenes de datos xml en lugar de base de datos. Uno utiliza un xmlDataSource para leer datos en una estructura jerárquica xml y reenviar los datos leídos al control TreeView para poder mostrarlos.
GridView es una mejora de DataGrid, a diferencias del DataGrid que requiere código para realizar ordenación, paginado, seleccionados y ediciones, el control GridView puede realizar todas estas acciones en forma nativa, sin la necesidad de escritura d código alguno. GridView también soporta una mayor flexibilidad en la administración comparándolo con DataGrid. La columna ImageFied, por ejemplo, habilita a GridView a mostrar imágenes, algo que en el DataGrid se podía hacer, pero con ayuda.
Este ejemplo utiliza un DataGrid y un SqlDataSource para mostrar los empleados de la tabla Northwind de una base de datos de SQL. Para embellecer el resultado puede usar una directiva, <%@Page Theme=“BasicBlue” $> para agregarle color al GridView.
Los tipos de campos de GridView son similares a los de DataGrid. Los campos CheckBoxField y ImageField son especialmente significante porque no son equivalentes a los del DataGrid.
Así como DataGrid puede ser personalizable configurando AutoGenerateColumns=“false” y declarando columnas en el elemento <columns>, GridView puede ser personalizable configurando AutoGenerateColumns=“false” y declarando campos en el elemento <Columns>. Este ejemplo usa una columna ImageField para mostrar las fotos de los empleados obtenidas desde la tabla Employees, otra columna TemplateField para combinar el nombre y el apellido y un BoundField para mostrar el contenido de cada registro del campo “Title”. Note que las fotos de los empleados no requieren código para ser mostradas. Lo mismo no podría ser realizado en un control DataGrid.
Mientras que GridView es diseñado para renderizar un conjunto de registros dentro de una tabla HTML, DetailsView es diseñado para tomar un registro y mostrarlo de a uno a la vez. Built-in paging support habilita registros dentro de un DetailsView para ser explorados sin la escritura de código. Built-in Edit support permite a los registros que sean insertados, actualizados y eliminados (aunque la realidad nos dice que se termina ingresando código para responder posibles inconvenientes de fallas, etc.) sin la escritura de código. Los campos ImageFied, CheckBoxField pueden ser declarados tanto en un GridView como en un DetailsView. En demostraciones, el control DetailsView es frecuentemente mostrado en conjunto con el control GridView para hacer visualizaciones de datos y detalles de los mismos. Sin embargo, DetailsView es perfectamente capaz de trabajar sin GridView.
Este ejemplo declara un control DetailsView y usa el elemento <Fields> para declarar campos que DetailsView mostrara. Una vez mas, la visualización de fotos de empleados se realiza sin la escritura de código al igual que los cambios en la estética del control.
El comando Configure Data Source de Visual Studio, realiza casi todo el trabajo por usted, definiendo las propiedades InsertCommand, UpdateCommand, y DeleteCommand del control data source. Adicionalmente le permite definir si los comandos UpdateCommand y DeleteCommand son generados implementando estrategias first-in wins o last-in wins, que determinan que pasará cuando múltiples usuarios editen los mismos datos al mismo tiempo.
Objetivos: Mostrar el uso del GridView a partir de diferentes DataSources, focalizando la atención en lo sencillo que resulta mostrar datos de manera dinámica que provienen de cualquier fuente. En la primera parte, se utilizara un XMLDataSource, y en la segunda un SQLDataSource. La práctica se encuentra desarrollada en la carpeta que contiene todas las prácticas, bajo el nombre de GridView. Se recomienda de todas formas comenzar la práctica partiendo de un WebSite en blanco. Guiar a los alumnos en la realización de la práctica guiada. Tiempo estimado: 60 minutos como Práctica Guiada Preparación de la demo: Realizar el restore la base de datos Northwind (northwind.backup) en el Servidor Microsoft SQL Server 2005 local. Utilizar el archivo libros.xml del lab XMLDataSource Pasos: Crear un nuevo website. Renombrar default.aspx como GridViewDemo1.aspx Agregar en App_Data de la solución el archivo libros.xml. Este xml será utilizado como DataSource. En modo de diseño, arrastrar un GridView Control a la pagina. Seleccionar un formato desde la opción Auto Format… Elegir un DataSource para el control, desde la opción Choose Data Source, Add New… Elegir un DataSource del tipo XML File, configurarlo seleccionando como Data File libros.xml, que se encuentra en App_Data. Como XPath Expresión escribir: Libros/genero[@nombre='Literatura']/libro Observar que el DataView ya aparece poblado con los valores ingresados desde el XML. Ejecutar la aplicación en modo Debugging. Mostrar el código obtenido a partir del uso del designer. El mismo creo nuestro DataSource XML. Además, se crea un DataGridView que mapea los valores del nodo xml a columnas en la tabla, automáticamente. Crear un nuevo aspx file, con el nombre GridViewDemo2.aspx Agregar otro GridView Control. Determinar un estilo, y luego crear un nuevo DataSource Seleccionar un datasource del tipo DataBase. Elegir SQLDataSource y armar un connection string que vaya contra el Server local y contra la base NorthWind. Luego seleccionar algunas columnas de la tabla customers para que sean visualizadas. Dentro de los tasks del GridView, seleccionar Enable Padding y Enable Sorting. Ejecutar la aplicación. Mostrar el paginado y la posibilidad de ordenar por columna. Mostrar el código generado. Observar que el datasource ahora es un SQLDataSource. Agregar un DetailsView. En el GridView agregar Enable Select. Agregar un DataSource a DetailsView, que sea también a la misma base de datos. Al “Select Statement” agregarle algunas columnas de una tabla de NorthWind que tenga Customers, por ejemplo Orders. Agregar un WHERE. En Column, seleccionar “CustomerId”, Operador “=“ y Source como Control. En ControlId, seleccionar el GirdView que ya se creo. Luego, hacer un Add del Expresión. Ejecutar la acción. Ahora, al seleccionar algún Customer, mostrará los detalles de Orders para el mismo. Observar el código generado.
![Clase XI
•[nombre instructor]
•[fecha]](https://image.slidesharecdn.com/clasexi-130115120544-phpapp01/85/Clase-xi-1-320.jpg)
