Clase xi
Descargar como PPT, PDF0 recomendaciones925 vistas
El documento presenta la agenda de una clase sobre ASP.NET 2.0, incluyendo introducciones a ASP.NET, el modelo de código de página, manejo de estado, controles, controles de usuario y personalizados, callbacks en clientes y acceso a datos. Explica conceptos como view state, session state, cache y diferentes tipos de controles y su creación.
![Clase XI
•[nombre instructor]
•[fecha]](https://image.slidesharecdn.com/clasexi-130115120544-phpapp01/85/Clase-xi-1-320.jpg)
Clase xi
- 1. Clase XI •[nombre instructor] •[fecha]
- 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
- 7. El proceso Postback ASP.NET 2.0
- 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
- 28. Demo •Creación de un Web Form user control
- 29. Demo •Agregar user control a Web Forms
- 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
- 35. Demo •Client CallBacks
- 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
- 42. Laboratorio •XMLDataSource
- 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
- 46. Control GridView <asp:SqlDataSource ID="Employees" RunAt="server" <asp:SqlDataSource ID="Employees" RunAt="server" ConnectionString="server=localhost;database=northwind;..." ConnectionString="server=localhost;database=northwind;..." SelectCommand="select photo, lastname, firstname, title from SelectCommand="select photo, lastname, firstname, title from employees" /> employees" /> <asp:GridView DataSourceID="Employees" Width="100%" RunAt="server" <asp:GridView DataSourceID="Employees" Width="100%" RunAt="server" AutoGenerateColumns="false" >> AutoGenerateColumns="false" <Columns> <Columns> <asp:ImageField HeaderText="" DataField="photo" /> <asp:ImageField HeaderText="" DataField="photo" /> <asp:TemplateField HeaderText="Name"> <asp:TemplateField HeaderText="Name"> <ItemTemplate> <ItemTemplate> <%# Eval ("firstname") ++ "" "" ++ Eval ("lastname") %> <%# Eval ("firstname") Eval ("lastname") %> </ItemTemplate> </ItemTemplate> </asp:TemplateField> </asp:TemplateField> <asp:BoundField HeaderText="Title" DataField="title" /> <asp:BoundField HeaderText="Title" DataField="title" /> </Columns> </Columns> </asp:GridView> </asp:GridView> 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
- 48. Control DetailsView <asp:SqlDataSource ID="Employees" RunAt="server" <asp:SqlDataSource ID="Employees" RunAt="server" ConnectionString="server=localhost;database=northwind;..." ConnectionString="server=localhost;database=northwind;..." SelectCommand="select employeeid, photo, ... from employees" /> SelectCommand="select employeeid, photo, ... from employees" /> <asp:DetailsView DataSourceID="Employees" RunAt="server" <asp:DetailsView DataSourceID="Employees" RunAt="server" AllowPaging="true" AutoGenerateRows="false" AllowPaging="true" AutoGenerateRows="false" PagerSettings-Mode="NextPreviousFirstLast"> PagerSettings-Mode="NextPreviousFirstLast"> <Fields> <Fields> <asp:ImageField HeaderText="" DataField="photo" /> <asp:ImageField HeaderText="" DataField="photo" /> <asp:BoundField HeaderText="Employee ID" DataField="employeeid" /> <asp:BoundField HeaderText="Employee ID" DataField="employeeid" /> <asp:BoundField HeaderText="Date Hired" DataField="hiredate" /> <asp:BoundField HeaderText="Date Hired" DataField="hiredate" /> <asp:TemplateField HeaderText="Name"> <asp:TemplateField HeaderText="Name"> <ItemTemplate> <ItemTemplate> <%# Eval ("firstname") ++ "" "" ++ Eval ("lastname") %> <%# Eval ("firstname") Eval ("lastname") %> </ItemTemplate> </ItemTemplate> </asp:TemplateField> </asp:TemplateField> <asp:BoundField HeaderText="Title" DataField="title" /> <asp:BoundField HeaderText="Title" DataField="title" /> </Fields> </Fields> </asp:DetailsView> </asp:DetailsView> 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
- 50. Demo •GridView y DetailsView
Notas del editor
- #5: 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”>
- #6: 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.
- #7: 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
- #8: 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.
- #9: 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.
- #10: 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.
- #13: 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.
- #14: 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 .
- #15: 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.
- #16: 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.
- #17: 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.
- #18: 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
- #19: 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 .
- #20: 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.
- #21: 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.
- #22: 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.
- #23: 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.
- #24: 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.
- #25: 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.
- #26: 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
- #27: 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
- #28: 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
- #29: 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.
- #30: 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.
- #31: 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.
- #32: 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.
- #33: 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.
- #34: 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
- #35: 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.
- #36: 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.
- #37: 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.
- #38: 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 $.
- #39: 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.
- #40: 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.
- #41: 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.
- #42: 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.
- #44: 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.
- #45: 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.
- #46: 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.
- #47: 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.
- #48: 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.
- #49: 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.
- #50: 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.
- #51: 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.