[CelulaUNT.Net]: Cansado de overview y novedades?, Evento post-lanzamiento

Si ya has asistido a un evento de Lanzamiento, y deseas explorar a detalle alguna de las novedades de los nuevos releases de Microsoft, la Célula UNT .Net esta organizando un evento, en la ciudad de Trujillo-Perú: Aprendiendo con las nuevas tecnologías {Microsoft 2008}:

Clic para agrandar

El evento será el Viernes 30 de Mayo por la tarde en la Universidad Nacional de Trujillo (UNT), si deseas ver la agenda en detalle puedes hacerlo aquí, y si deseas la ubicación exacta, hicieron un mapa. Pueden registrarse en la siguiente página: Registro Evento.

Yo estaré participando con el tema de Escenario de Acceso a datos con el nuevo control ListView de ASP.NET, hay algunos artículos interesantes en MSDN Magazine sobre este control, estaré mostrando algunas de las cualidades de las cuales podemos sacar provecho, soporte de inserción a comparación del GridView, el manejo total del render del html, con los anteriores controles debemos usar CSS Control Adapter para manejar el render del html, y además de esto con soporte de los controles DataSource, que soporte paginación customizable, son muchos los escenarios que podemos explotar con este control, y esperamos abordarlas en el evento, además de acompañarlas de algunas otras features, como  el uso de Linq to Objects, uso del paquete Data Access del Service Factory, entre otras.

P.D.: Después de la charla, subiré la presentación (si hay, si da el tiempo), y las demos que siempre se terminan de alguna manera durante la sesión evento, si no terminaron antes

Saludos,

[CodeSnippet] Borrar masivamente procedimientos almacenados

Iniciamos una nueva sección en el blog, llamada Code Snippets, serán pequeñas porciones de código simples o algunas marcianas, pero que siempre son útiles, ya se para el trabajo, para preparar un demo, o un código rebuscado.

Problema: He restaurado una base de datos usando la herramienta SQL Database Publishing, para una demostración, y estoy actualizando/recreando los store procedures, y el problema era que deseaba eliminar masivamente los store procedures, que tengan un determinado patrón. Puedes eliminar los store procedures, desde SQL Server Managment Studio, haciendo clic derecho sobre el procedure, y seleccionando delete pero uno por uno, si hubiera un shift select/delete, y la otra forma, hasta donde se :$ , es haciéndolo por código, y esta es la que vamos a explotar.

Plataforma: SQL Server 2005, query a nivel de base de datos.

   1: use dbGeekProducts
   2: go
   3: DECLARE @SPs varchar(max)
   4: SET @SPs = ''
   5: SELECT @SPs = @SPs + [name] + ',' FROM sys.objects
   6: WHERE type = 'P' AND name LIKE 'usp_%'
   7:  
   8: SELECT @SPs
   9: go

En mi caso yo quiero eliminar todos los store procedures de una base de datos que empiecen con el nombre “usp_%“. El detalle de DROP PROC, es que no acepta strings o variables, si no nombres de objetos. De ahí el tip de hacer SELECT @SPs. Copio el resultado del SELECT, remuevo la última coma, y lo pego dentro del siguiente código:

   1: DROP PROC usp_Product_Insert,usp_Product....
   2: go

Si alguien tiene alguna otra o mejor forma, favor de  comentarlo :D.

P.D.: Imagino que con VS for Database Professionals, puede hacer esto con shift/control select.

Saludos,

[Off-Topic] Blogs de la Celula UNT .Net

Una noticia que me causo mucha alegría es la liberación de los blogs de la Célula UNT .Net. Antes había blog personales de estudiantes, pero no como equipo, no como Célula UNT .Net, puede ser enriquecedor sobre salir personalmente, pero sobresalir como grupo humano es mucho mas enriquecedor, ya Luis Fraile compartió algunas reflexiones sobre el compañerismo las cuales comparto.

En algunos casos alcanzar este tipo de objetivos es un poco difícil ya que no se cuenta con el apoyo de las autoridades o de la misma Universidad, algunas veces por que la facultad es nueva y no tienes el apoyo docente, otras por cuestiones políticas dentro de la universidad, y algunas veces por racismo de software (anti-microsoft o anti-inux). Mis felicitaciones para todo el grupo que hizo posible esto sobretodo porque ellos mismos están financiando la Web ideal debería ser que la Universidad de algún sub-hosting dentro de su mismo sitio Web, tener la Web de la Célula UNT .NET fue siempre un deseo del grupo de la Célula en los años en que participe, pero no se pudo hacer,  y si en algo ayudo mi participación cuando fui parte de la Celula UNT .Net, pues me siento muy a gusto y satisfecho.

Lo que más gusto me da, es que la mayoría de los Bloggers UNT, están en media carrera recién ahondando en la carrera, ya que los primeros años son de cursos generales, y no se si habrán percatado o enterado, pero actualmente tener un blog te ayuda mucho en tu vida profesional. Algunos imagino que recién están ingresando al mundo .NET, quizás unos con mas experiencia que otros, pero en un año o menos, espero leer entradas sobre los proyectos en los que estén trabajando, y como están aplicando .NET, mejores prácticas, patrones, bloques de código, herramientas, y todo los chiches que hay, etc, etc…

Si están buscando jóvenes talentos, estos son los Blogs: http://celulaunt.net/community/blogs/Bloggers.aspx.

P.D.: Creo que el siguiente objetivo debe ser participar en el Imagine Cup.

Saludos,

Serie de WebCast: Introduction to SharePoint for .NET Developers

El día de hoy empezó una serie de WebCast de SharePoint orientada a los .NET Developers.

En el de WebParts del día de hoy, primero de la serie, contó con alrededor de 400 asistentes online, no había visto tanta gente en un WebCast desde la clásica batalla C# vs VB.Net. Además de estar muy claro y simple de entender, e imagino que los demás serán del mismo tipo.

Los WebCast son nivel 100, todos en inglés. El primero, a la fecha de hoy, ya lo podemos ver bajo demanda, y los demás podemos a llegar a verlos online, igual si no llegamos lo podemos ver después bajo demanda. Lo interesante de poder asistir a un online, es la capacidad de poder hacer preguntas a los speakers de los Webcast, si han tenido alguna pregunta o duda con alguno de los temas, puede aprovechar el WebCast para hacerla.

  1. 20080520 – MSDN Webcast: Introduction to SharePoint for .NET Developers: Web Parts (Level 100). Por Robert Bogue.
  2. 20080521 – MSDN Webcast: Introduction to SharePoint for .NET Developers: Data Lists (Level 100). Por Robert Bogue.
  3. 20080527 – MSDN Webcast: Introduction to SharePoint for .NET Developers: Silverlight and SharePoint Server (Level 100). Por Andrew Connell.
  4. 20080528 – MSDN Webcast: Introduction to SharePoint Server for .NET Developers: Using Event Handlers (Level 100). Por Andrew Connell.
  5. 20080603 – MSDN Webcast: Introduction to SharePoint for .NET Developers: Page Branding (Level 100). Por Andrew Connell.
  6. 20080604 – MSDN Webcast: Introduction to SharePoint for .NET Developers: Workflows (Level 100). Por Robert Bogue.
  7. 20080610 – MSDN Webcast: Introduction to SharePoint Server for .NET Developers: Web Services (Level 100). Por Andrew Connell.
  8. 20080611 – MSDN Webcast: Introduction to SharePoint Server for .NET Developers: Page Navigation (Level 100). Por Andrew Connell.
  9. 20080617 – MSDN Webcast: Introduction to SharePoint for .NET Developers: User Management (Level 100). Por Robert Bogue.
  10. 20080618 – MSDN Webcast: Introduction to SharePoint Server for .NET Developers: Custom Content Types (Level 100). Por Robert Bogue.

Saludos,

IIS 7.0: Administracion Remota a nivel de Servidor, de Sitio, de Aplicacion, de Archivo?

Normalmente los servicios de hosting, proveen una herramienta Web para la administración de un Sitio Web, esta herramienta cuenta con las funciones básicas, stop/restart application, default documents, entre otras features. Pero no es como abrir la consola de administración de IIS. Es ahí donde contar con una herramienta de estas, de poder administrar remotamente un sitio Web a nivel de Web Site (no el servidor), se convierte una herramienta poderosa para los clientes que alquilan un servicio de hosting, y comercial/atractiva para los que ofrecen un servicio de hosting.

Otro escenario, es dentro de nuestra organización, tenemos un WebSite, con dos Web Applications una de ventas y otra de recursos humanos, cada una con su propia administrador, no es lo más recomendado dar permisos mas de los necesarios a cada usuario, es decir, sólo debería poder administrar lo que necesite, y no de otros Web Applications. Además ya no tiene la excusa de ante un problema de tirar el muertito a los demás admins, responsabilizar a los usuarios que tienen los permisos de administración. Habilitando la administración a nivel de Aplicación cada admin es responsable de su Web Application.

Voy a tomar como base copy/paste el siguiente artículo:  Configuring Remote Administration and Feature Delegation in IIS 7.0. Además de acotar algunos detalles que puede no quedar no muy claros.

Empecemos… con la administración de un servidor

1. ServerIIS – Instalar el Servicio. Lo primero que debemos hacer ir al Server Manager, dentro del Role Web Server (IIS), verificar que tengamos instalado el rol Management Service. Este servicio, es el que provee la infraestructura necesaria para habilitar la administración remota en IIS 7.0:

http://sergiot2.com/blogimages/2008/05May/18_ServerManager.jpg

2. ServerIIS – Configurar la Administración Remota. Ahora nos vamos al IIS Manager, seleccionamos el Servidor y dentro del grupo Security, abrimos la feature Management Service. Notar que seleccionamos el servidor, y no un Sitio Web, ya que esta feature esta disponible a nivel de Servidor:

http://sergiot2.com/blogimages/2008/05May/18_ManagementService.jpg

En esta feature, marcamos el check en “Enable remote connections“, y en “Identity Credentials“, podemos escoger “Windows credentials only” o “Windows credentials or IIS Manager credentials“, y el seleccionar una otra va depender de los requerimientos que se tenga, las credenciales de Windows, son los usuarios de la PC, y las credenciales de IIS, es para habilitar a los usuarios de IIS (estos usuario son administrados dentro del IIS). Por ejemplo si yo no quiero crear un usuario Windows por cada Web Application, puedo crear un usuario en IIS Manager, y este usuario será usado para la conexión, si no, será usado el usuario Windows. Ahora otro tema a tener en cuenta, es los permisos que tengamos que dar en los ACLs de los directorios de la aplicación, pero esto lo veremos más adelante.

También podemos escoger el puerto del servicio, y otras features adicionales. Después de escoger nuestra configuración, hacemos clic en el “Apply”, para guardar los cambios, y después Start, para iniciar el servicio.

http://sergiot2.com/blogimages/2008/05May/18_enabledRemote.jpg

Un detalle a tener en cuenta es que si reiniciamos el servidor por alguna razón, este servicio no estará iniciado. Si vamos a los Servicios del servidor, podemos cambiar esta feature. Además notar que también podemos cambiar el usuario del servicio de acuerdo las políticas de seguridad que se tenga, por defecto lo instala con la cuenta “Local Service“. Recordar este usuario, que será usado más adelante:

http://sergiot2.com/blogimages/2008/05May/18_Web_Management_Services.jpg

Otro detalle a tener en cuenta es verificar que la excepción al servicio “Web Management Service (HTTP)“, este habilitada dentro Windows Firewall, que por defecto apunta al puerto 8172, si cambiamos el puerto, tendríamos que agregar la excepción para ese puerto. [OF: Alguien sabe donde se guarda o configura, ¿cuál es el puerto por defecto de un servicio para estas excepciones?]:

http://sergiot2.com/blogimages/2008/05May/18_WFirewall.jpg

3. UserPC – Conexión a un Servidor. Si tenemos un user y password de Windows, con los permisos respectivos, ya podemos usarlos para conectarnos a través del IIS 7.0 Manager Client (para WXP, Vista, y W2k3), que es una descarga adicional para el cliente. Una vez que descargamos el programa, abrimos el IIS 7.0 Manager, y seleccionamos “Connect to a server…“:

http://sergiot2.com/blogimages/2008/05May/18_IISManager_Client.jpg

En Server name, ingresamos la IP o dirección del servidor:

http://sergiot2.com/blogimages/2008/05May/18_ServerName.jpg

Nuestro User name, y Password:

http://sergiot2.com/blogimages/2008/05May/18_UserIIS.jpg

Y finalmente asignamos un nombre a nuestra conexión, y hacemos clic en “Finish”:

http://sergiot2.com/blogimages/2008/05May/18_ConnectionName.jpg

Y ahora puedo administrar mi servidor IIS 7.0, desde donde quiera que esté con las capacidad que brinda la Consola de administración IIS 7.0 Manager:

http://sergiot2.com/blogimages/2008/05May/18_adminIIS.jpg

 

Pero si yo no quiero habilitar la administración de todo mi servidor, si no solamente un Web Site?

Nota: Si yo tengo una cuenta para administrar todo el servidor IIS 7.0, puedo habilitar la administración remota a nivel de Web Site, y Web Applicación desde mi PC, en caso de no, tengo que hacerlo desde el Servidor de IIS 7.0.

1. ServerIIS – Habilitar la administración remota a nivel de Web Site

Dentro de nuestro Servidor de IIS 7, abrimos la feature IIS Manager Users. Voy a usar usuarios de IIS, y no de Windows, para habilitar la administración remota de un Web Site:

http://sergiot2.com/blogimages/2008/05May/18_IISUsers.jpg

En Actions, seleccionamos Add User, e ingresamos los datos de nuestro usuario:

http://sergiot2.com/blogimages/2008/05May/18_AddUser.jpg

Ahora seleccionamos el Web Site, en el que queremos habilitar la administración remota, y abrimos la feature IIS Manager Permissions:

http://sergiot2.com/blogimages/2008/05May/18_BlogEngine.jpg

En Actions seleccionamos Allow User, seleccionamos el usuario creado previamente, adminBlogEngine, y hacemos clic en OK:

http://sergiot2.com/blogimages/2008/05May/18_AllowUser.jpg

2. UserPC – Conexión a un Web Site

Iniciamos el IIS 7.0 Manager Client, y en Connection tasks, hacemos clic en Connect to a site.

Como puede notar ahora además del nombre del servidor debemos agregar, el nombre del Web Site, que vamos administrar remotamente:

http://sergiot2.com/blogimages/2008/05May/18_ConnectSite.jpg

Los siguientes pasos, son iguales al Connect to a server, debemos ingresar el usuario, que en este caso será el usuario de IIS adminBlogEngine, y finalmente debemos asignar un nombre la conexión.

Seleccionamos nuestro Web Site, y abrimos la feature Directory Browsing:

http://sergiot2.com/blogimages/2008/05May/18_DirectoryBrowsing.jpg

Si en Actions, seleccionamos Enable, para habilitar Directory Browsing, es decir permitir que el usuario puede ver la lista de archivos disponibles en la carpeta solicitada, en nuestro Web Site, obtenemos el siguiente error:

http://sergiot2.com/blogimages/2008/05May/18_EnabledDicBrow.jpg

Filename: MACHINE/WEBROOT/APPHOST/WebSite
Error: Cannot write configuration file due to insufficient permissions

Y el problema es que del lado del servidor, el usuario con el que se esta ejecutando el servicio Web Management Service, que en nuestro caso es la cuenta LOCAL SERVICE, no tiene permisos para escribir en la carpeta del Web Site.

Para darle los permisos necesarios, en nuestro ServerIIS, ubicamos la carpeta del Web Site, hacemos clic derecho en propiedades, y en la pestaña Securtity, hacemos clic en el botón Edit, para editar los permisos, agregamos a la cuenta LOCAL SERVICE, y habilitamos el permisos para modificar:

http://sergiot2.com/blogimages/2008/05May/18_Local_Service.jpg

Atención, este permiso es para cliente de IIS Manager, si es que tenemos habilitado la administración remota, no tiene nada que ver con el permiso del Web Site si vamos a dejar que el usuario suba archivos, recuerden que para eso debemos dar permisos a la cuenta de usuario que tiene asignado el Application Pool.

Y si regresamos a nuestro PC cliente, volvemos a reintentar habilitar el Directory Browsing, y ahora ya no vamos a tener ningún problema:

http://sergiot2.com/blogimages/2008/05May/18_EnableDir.jpg

Pero si quiero ser más granular, y habilitar sólo la administración de un Web Application?

1. ServerIIS – Habilitar la administración remota a nivel de Web Application

Al igual que en el anterior modo, voy agregar un usuario IIS, en mi servidor de IIS con el nombre adminWebClassic.

Selecciono mi Web Application, WebClassic abro la feature IIS Manager Permissions, y agrego al usuario creado previamente adminWebClassic:

http://sergiot2.com/blogimages/2008/05May/18_WebApp.jpg

Recordar que debemos dar los permisos necesarios a la cuenta LOCAL SERVICE, para que pueda modificar el Web Application desde el IIS 7.0 Manager Client.

2. UserPC – Conexión a un Web Application

Iniciamos el IIS 7.0 Manager Client, y en Connection tasks, hacemos clic en Connect to an application.

Ahora además de ingresar Server name, y Site name, debemos ingresar Application name:

http://sergiot2.com/blogimages/2008/05May/18_Connect_Application.jpg

Los siguientes pasos, son iguales al Connect to a server o Connect to a Site, debemos ingresar el usuario, que en este caso será el usuario de IIS adminWebClassic, y finalmente debemos asignar un nombre la conexión.

Y ya puedo administrar mi Web Application:

http://sergiot2.com/blogimages/2008/05May/18_AdminWebApp.jpg

Y si quiero la administración remota a nivel de archivo?

Pues no hay, pero lo que si podemos hacer es decidir que funciones vamos a delegar y cuales no.

Tenemos tres opciones: permitir que pueda ver/modificar una feature, permitir que sólo pueda ver una feature y su configuración, o simplemente no delegar la feature y el usuario no se entera que existe. Vamos a ver un ejemplo:

1. ServerIIS – Delegando features

Dentro de mi Servidor de IIS 7.0, abrimos la feature, dentro de la categoría Security, Feature Delegation:

http://sergiot2.com/blogimages/2008/05May/18_FeatureDelegation.jpg

Primero, en Actions, seleccionamos Custom Site Delegation, seleccionamos el site Default Web Site, seleccionamos la feature que se desea delegar, en nuestro caso Directory Browsing, y en Actions, hacemos clic en Not Delegated:

http://sergiot2.com/blogimages/2008/05May/18_CustomDelegation.jpg

Y si en la PC cliente, nos vamos las features de la categoría HTTP Features, vamos a poder ver que ya no tenemos Directory Browsing. En este caso si ya tenía abierta la sesión de WebClassic, van a tener que reconectarse para actualizar la delegación de features, para ver los cambios aplicados:

http://sergiot2.com/blogimages/2008/05May/18_without_dirbrow.jpg

Conclusiones:

Espero, no decir alguna barbaridad por la hora, que todo en la entrada/post haya quedado claro, y acá sólo vemos un poco del poder de IIS 7.0. Ahora podemos hacer más granular la administración de IIS 7.0, pudiendo llegar a nivel de Servidor, de un Sitio Web, o de una Aplicación Web. Además de poder decidir que features va tener disponible el cliente remoto. Hay algunas opciones en la que no entre en detalles, para no dar más lata con el artículo, pero de acuerdo a sus necesidades ustedes pueden detallar en la mucha información que hay Internet.

P.D.: Ya no doy más lata, y voy a dormir, que en unas horas hay mucho curro/laburo/trabajo, para iniciar la semana.

Saludos,

Mini-Poster de IIS 7.0 (Componentes) y Referencia de Modulos

Un mini-poster con los componentes de IIS 7.0:

IIS 7.0 Components

Link: Mini-poster IIS 7.0 Setup Components.

También, aprovecho el post para compartir la referencia de módulos disponibles en IIS 7.0: IIS 7.0 Modules Overview. Al final del artículo van a encontrar una lista-referencia de los módulos, con su descripción, sección de configuración, dependencias y notas del módulo. Como dijo Iván González, en algunos WebCast, ahora vas a poder legolizar tu aplicación con IIS 7.0, es decir vas ir armando y usando los módulos de acuerdo a tus necesidades. Y si has revisado los módulos disponibles con IIS 7.0, y ninguno de ellos satisface tu necesidad pues extiéndelo.

Nuevamente, no se olviden de revisar los módulos disponibles, para no hacer un esfuerzo innecesario en algo que ya esta construido. También no esta demás navegar en la red, quizás alguien ya implemento el módulo que necesitamos, como este que comenta ScottGu: IIS 7.0 Bit Rate Throttling Module Released.

Saludos,

[WebCast] C# vs Vb.Net, yo le voy a C# y tu?

C# vs VB.Net

Como recordatorio del WebCast de este martes 6 de mayo. Registro aquí.

Ya Jorge Serrano, hizo una entrada a este clásico debate. Y como dice, siempre y cuando este tipo de charlas no caiga en radicalismos y envidia, y que sea usado para romper el hielo, y conocer un poco más del lenguaje que usamos, creo que el debate es enriquecedor.

Voy a dar mi opinión hablando con el corazón y basado en gustos subjetivamente. Yo empecé, y aprendí a programar con C++, y cuando ingrese al mundo de .Net lo hice con VB.Net. Pero desde que conocí C#, que les puedo decir, me quede con ese lenguaje, y me gusta ver “;” al final de una instrucción, o mis bloques de código encerrado entre llaves. Particularmente siento mi código mas ordenado cuando lo veo en C#.

Pero veamos otro tema:

¿Qué tanto puede influir el lenguaje en el desarrollo de un proyecto?. Pues como ya se dijo en el post de Jorge, técnicamente el lenguaje no es más que un skin para el .Net Framework, no veamos capacidad del lenguaje, si no la productividad que te puede dar uno o otro. Imaginemos que si para un proyecto se contratan 5 developers, y tres de ellos ya tienen varios proyectos hechos con C#, hacer que ellos trabajen en VB.Net disminuirá ligeramente su productividad?, otro tema son las librerías disponibles sobre las cuales vas a trabajar, sobre todo si quieres personalizar algunas de ellas, digamos que vas usar algún software factory, como el Web Service Software Factory que en un inicio esta disponible sólo en C#, incrementaría la productividad que el proyecto este desarrollado con C#, y los developers estén familiarizados con ese lenguaje, y cuando tengan que hacer algún cambio al código generado lo hagan más rápido?

Podríamos resumir, para escoger un lenguaje las siguientes pautas, ya que en el fondo con los dos podrías hacer lo mismo:

  • Escoger aquel con el cual los desarrolladores hacen más rápido el proyecto. Y esto va por la experiencia, y con cual se sienten a gusto.
  • Que sea igual al lenguaje de las librerías, frameworks o bloques de código, que se van a usar. Siempre y cuando se quiera personalizar las mismas.

Imagino que debe haber alguna más, pero no se me ocurren en este momento.

Y si yo tengo la oportunidad de escoger el lenguaje, yo escogería C#, por que desarrollo más rápido en el, y la mayoría de librerías que usado ha predominado C#, como los Flan Controls, Ajax Control Toolkit, y la versión anterior de Web Service Software Factory que en un inicio se liberó en C#.

Ya si la decisión no depende de mí, y el jefe de proyecto escoge VB.Net, es bajo su responsabilidad xD, y si el proyecto esta interesante por que no hacerlo?

¡No se pierdan el WebCast!, no vemos ahí.

Saludos,

decodificando el ViewState… para verle hasta las venas

El tema de ViewState es tema muy triado, pero no he tenido la oportunidad de comentarlo y entenderlo bien así que voy a explicar algunos puntos relacionados al tema.

Para tratar de entender a detalle al ViewState pueden leer el siguiente artículo: TRULY Understanding ViewState, tal fue el ranking del post que un usuario hizo un pdf con todos los comentarios, clasificados y ordenados al estilo FAQ: TRULY Understanding ViewState, the comment index. Aunque supongo que ya lo leyeron, los que revisaron el LDLS-2008mar10.

Para entender el ViewState, veamos primero que pasaba antes de la existencia del mismo, y cual era el problema que en el ASP Clásico, y en general en el mundo Web con las demás tecnologías de servidor, debido a que las páginas web son stateless.

Cuando agregamos un nuevo WebForm a nuestro proyecto Web, agrega el siguiente código html:

   1: <body>
   2:     <form id="form1" runat="server">
   3:     <div>
   4:     
   5:     </div>
   6:     </form>
   7: </body>

Ahora vamos a cambiar el código de form, por el siguiente, para revisar el modelo de trabajo de un página con el clásico ASP:

   1: <form id="form1" method="post" action="WebForm01.aspx" >
   2:    <div>
   3:        <input id="txtNombre" name="txtNombre" type="text" />
   4:        <br />
   5:        <input id="btnEnviar" type="submit" value="enviar" />
   6:        <br />
   7:        <br />
   8:        <span><strong>Nombre: </strong>
   9:           < %= Request.Form["txtNombre"]%></span>
  10:    </div>
  11: </form>

En el caso del action, depende del nombre sobre el formulario que estén trabajando.

SI hacemos “View in Browser” a la página, ingresamos un nombre y hacemos un submit:

http://sergiot2.com/blogimages/2008/05May/02_name.jpg

Noten que el contenido del control txtNombre, se ha perdido. Este era el problema, la perdida de valores entre postbacks al servidor, y se usaban distintas técnicas para guardar el valor de los controles, como por ejemplo el uso de controles  Hidden. Veamos el código fuente de lo que se muestra en el navegador:

   1: <form id="form1" method="post" action="WebForm01.aspx" >
   2:    <div>
   3:        <input id="txtNombre" name="txtNombre" type="text" />
   4:        <br />
   5:        <input id="btnEnviar" type="submit" value="enviar" />
   6:  
   7:        <br />
   8:        <br />
   9:        <span><strong>Nombre: </strong>Ricardo</span>
  10:    </div>
  11: </form>

Recuerden que siempre al cliente llega todo como html, y nada de la tecnología de servidor usada. Para refrescar un poco:

http://sergiot2.com/blogimages/2008/05May/03_web.jpg

Sólo como recordatorio: El cliente ingresa a su navegador y pide una url, esta se envía por el método get al servidor, el servidor recibe el request, y lo procesa de acuerdo al tipo de recurso solicitado, en el caso de asp.net las compila, y genera el html para ser enviado al cliente que hizo el request, cuando llega el html al browser, este lo interpreta (si la diseño bien y respeto los estándares), y lo muestra finalmente al usuario. Esto es en el primer pedido, cuando el usuario no ha interactuado con el formulario.

En nuestro ejemplo si el usuario ingresa un nombre y hace un submit, el paso 1 se modifica y en el request también viaja el formulario con el contenido del formulario enviado, para que el servidor lo procese y vuelva devolver el html requerido.

Como pueden ver el problema, es que cada página muere después de su llegada al servidor, y este envía una nueva página, y ahí es donde había que hacer trabajo adicional para “mantener” variables o valores. En nuestro caso para “conservar” el valor podíamos hacer lo siguiente:

   1: <form id="form1" method="post" action="WebForm01.aspx" >
   2:    <div>
   3:        <input id="txtNombre" name="txtNombre" type="text" 
   4:               value="<%= Request.Form["txtNombre"]%>" />
   5:        <br />
   6:        <input id="btnEnviar" type="submit" value="enviar" />
   7:        <br />
   8:        <br />
   9:        <span><strong>Nombre: </strong>< %= Request.Form["txtNombre"]%></span>
  10:    </div>
  11: </form>

Con esto “mantenemos” el valor ingresado. Este es un caso simple, de como se pierde los valores de los controles entre postbacks, imaginen el trabajo necesario para mantener combos, listas, o grillas, u otra información, si que te hacía aprender html a la fuerza.

Ahora veamos a ASP.NET, y el famoso ViewState:

Primero hagamos una página igual a la anterior pero al estilo ASP.NET:

   1: <form id="form1" runat="server">
   2:     <div>
   3:         <asp:TextBox ID="TextBox1" runat="server" />
   4:         <br />
   5:         <br />
   6:         <asp:Button ID="Button1" runat="server" 
   7:              OnClick="Button1_Click" Text="Button" />
   8:         <br />
   9:         <br />
  10:         <asp:Label ID="Label1" runat="server" Text="Label" />
  11:     </div>
  12: </form>

¿Qué pueden notar a simple vista?, el casi camuflado runat=”server”. Esto hará que el compilador de asp.net les de un tratamiento especial, y si hacemos “View in Browser”, vamos a ver cual es ese tratamiento especial:

   1: <form name="form1" method="post" action="WebForm02.aspx" id="form1">
   2: <div>
   3:     <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" 
   4:           value="/wEPDwUKMTU5MTA2ODYwOWRkoCvvBWgUOH7PD446qvEOF6GTCq0=" />
   5: </div>
   6: <div>
   7:     <input name="TextBox1" type="text" id="Text1" />
   8:     <br />
   9:     <br />
  10:     <input type="submit" name="Button1" 
  11:              value="Button" id="Submit1" />
  12:     <br />
  13:     <br />
  14:     <span id="Span1">Label</span>
  15: </div>
  16: <div>
  17:     <input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" 
  18:          value="/wEWAwK96cyQBQLs0bLrBgKM54rGBnfFy5qsGxoLdjEJRH5u2jb20INJ" />
  19: </div>
  20: </form>

Como pueden ver el html generado por ASP.NET tiene en general las mismas estructuras que el html que genera el clásico ASP. El formulario usará el método post para enviar su contenido al servidor, tiene un input tipo text para el contenido, y un input tipo submit para enviar el formulario. ¿Y dónde esta la diferencia?, ¿Qué ha hecho el runat=”server”?

Pues a parte de agregar los atributos que le faltaban al elemento “form”, ha agregado dos elementos input adicionales tipo hidden, y que el usuario no ve en el navegador. El primero de ellos es usado para el ViewState, y el segundo es usado para la validación de los eventos de los controles.

Pero centrémonos en el ViewState, esa “basurilla” que aparece en el value del input, es debido a que su valor esta codificado en Base64, y si queremos ver el contenido de este podemos usar la excelente herramienta de Fritz Onion: ViewState Encoding in ASP.NET 2.0.

Si descargamos esta herramienta, y copiamos el value del input, el resultado sería similar al siguiente:

http://sergiot2.com/blogimages/2008/05May/02_view01.jpg

El número que aparece, es un código identificador de la página que es agregado en la compilación, y no he revisado, con reflector, que patrón sigue para generar este código.

¿Qué pasa si ingreso un nombre al input y hago un submit?. El código html devuelto por el servidor es el siguiente:

   1: <form name="form1" method="post" action="WebForm02.aspx" id="form1">
   2: <div>
   3:     <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" 
   4:       value="/wEPDwUKMTU5MTA2ODYwOQ9kFgICAw9kFgICBQ8PFgIeBFRleHQFFWhvbGEgKGFnYWluKTogUmljYXJkb2RkZBYEcyX+SIJ6nk9MwXtX7kSpUKKN" />
   5: </div>
   6: <div>
   7:     <input name="TextBox1" type="text" value="Ricardo" id="Text1" />
   8:     <br />
   9:     <br />
  10:     <input type="submit" name="Button1" value="Button" id="Submit1" />
  11:     <br />
  12:     <br />
  13:     <span id="Span1">hola (again): Ricardo</span>
  14: </div>
  15: <div>
  16:     <input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" 
  17:            value="/wEWAwLi/5/ADgLs0bLrBgKM54rGBlPmS3Xh+glhVkA6doo4UW+6VIvp" />
  18: </div>
  19: </form>

Como pueden ver el ViewState ha crecido, y nosotros, el que hizo el trabajito fue ASP.NET, no hicimos ningún trabajo adicional para “mantener” el estado del valor ingresado. Si nuevamente usamos la herramienta ViewState Decoder, vamos a ver como ASP.NET usa el View State para guardar el valor del contenido del elemento html span, que es lo que genera un control Label de ASP.NET:

http://sergiot2.com/blogimages/2008/05May/02_view02.jpg

¿Dónde vemos un caso más práctico?. Cuando llenamos un DropDownList, recuerdan que siempre nos dicen que debemos llenarlo en Load, con un condicional para llenarlo sólo en el primer request de la página. ¿Por qué ya no debemos llenarlo en los siguientes postbacks?, por que el ViewState se esta encargando de guardar los valores entre postbacks al servidor.

Ahora si agregamos un control DropDownList a la página, y en el evento Load de la página agregamos el siguiente código:

   1: protected void Page_Load(object sender, EventArgs e)
   2: {
   3:    if (!Page.IsPostBack)
   4:    {
   5:       DropDownList1.Items.Add("Trujillo");
   6:       DropDownList1.Items.Add("Lima");
   7:       DropDownList1.Items.Add("Cusco");
   8:    }
   9: }

Y sin hacer submit, vemos el ViewState actual de la página generada:

http://sergiot2.com/blogimages/2008/05May/02_view03.jpg

Podrán notar que sólo esta el contenido del DropDownList, si hacemos submit, se recargará al ViewState el valor del Label.

Podría resumir al ViewState como una técnica de ASP.NET, que hace uso de elementos html, para almacenar el valor de los controles de una página. Y esto también pasa con una grilla, pero atención que muchas veces el ViewState puede crecer demasiado:

http://sergiot2.com/blogimages/2008/05May/02_view04.jpg

Que a lo larga, lo único que hará será aumentar el tráfico del servidor, ya que este contenido estará viajando del cliente al servidor, y del servidor al cliente, innecesariamente, si es que todo el contenido de un control siempre es vuelto a generar. Si tengo un GridView que en cada postback es para cambiar su contenido, para que usar el ViewState para este control ¿?, pues eso, sólo usar el ViewState cuando sea necesario, por que a la larga no afectemos la escalabilidad y performance de la aplicación, hay un artículo interesante relacionado a la escalabilidad de aplicaciones web ASP.NET, en la edición MSDN Magazine 2008 Abril: Performance – Scaling Strategies for ASP.NET Applications, y aunque hay que leerlo varias veces para entenderlo, la esperanza es lo último que se pierde 😀.

Otra de las formas de rastrear que ViewState esta dando lata, es agregar el atributo Trace=”true”, a la directiva de la página asp.net, y al hacer “View in Browser”, recibiremos una lista con el tamaño de bytes que ocupa el ViewState de los controles que lo estén usando:

http://sergiot2.com/blogimages/2008/05May/02_view05.jpg

Por cierto el Trace, también brinda otra información adicional.

Espero que el tema del ViewState, haya quedado un poco más claro, el por que usarlo, el cuando usarlo, y ver que es lo que realmente hace es usar técnicas que pudieron ser usadas con el clásico ASP, pero ASP.NET se encarga de hacer ese trabajo por nosotros.

A medida que van saliendo las nuevas versiones de ASP.NET, se podrán ver que cada vez el trabajo del developer es más tonto, arrastrar y soltar, y la idea es que ocupe su tiempo en pensar bien las soluciones, y que no las este cambiando cada semana, pero siempre es bueno saber que hay detrás de ese trabajo para poder personalizarlo, y como pueden ver, todas son técnicas que ya se usaban antes. Es fácil arrastrar controles y saber ASP.NET, pero cuando lleguen formularios complejos, si sólo sabemos controles asp.net, y no sabemos nada de html/css/javascript, el formulario se puede convertir en un monstruo.

Nuevamente, leer el siguiente artículo: TRULY Understanding ViewState.

Otros artículos relacionados:

Saludos,

[SW]: BlogEngine.Net

[SW] = Samples Web Site.

Esta Aplicación Web, es Open Source, y la podemos descargar de codeplex. Algunos links relevantes:

  • Proyecto BlogEngine.Net. Es un Sitio Web para Blogs personales multi-autor.
  • BlogEngine en CodePlex. En el cual podemos descargar la Aplicación Web para la instalación. El código fuente para revisar y aprender, y un archivo de documentación, a la fecha esta en la versión 1.3.

Este es el blog, en su skin por defecto:

http://sergiot2.com/blogimages/2008/05May/01_BlogEngine.jpg

No voy hablar mucho del blog como blog, si no más como Aplicación Web para aprender :D. Ya que tendríamos que compararlos con los otros blogs free para ASP.NET, que escapan a los objetivos de la entrada.

Las features del Blog son, extraídas de codeplex:

  • Soporte multi-autor. El manejo de usuarios esta basado en el servicio Membership de ASP.NET.
  • Pingbacks y trackbacks. Revisar
  • Soporte de extensiones.
  • Basado en temas. (ASP.NET Themes)
  • Theming directly in master pages and user controls
  • Gravatar y coComments.
  • Moderación de comentarios.
  • BlogML import/export.
  • Coloreador de código.
  • Creación y edición de páginas que no son post.
  • Tag cloud.
  • Self updating blogroll.

En cuanto a la fuente de datos, puedes guardar la información en Xml, o base de datos SQL Server. Y en un futuro espero que esten disponibles también para otros proveedores.

En la Web encontraran manejo de master pages, manejo de localización para ser multi-idioma, manejo de temas, controles de usuarios, para la edición de texto usan TinyMCE, tiene su sección administrativa, clases para formatear código, manejo de BBCode, y otras features más.

En el código fuente encontrarán la librería BlogEngine.Core, que tiene clases para el soporte de MetaWeblog, clases para los pingbacks y trackbacks, clases de los dos proveedores de acceso a datos clases para Xml y para SQL, contiene controles, clases para httpModules y httpHandlres, las entidades del modelo, entre otras y utilitarios.

Disfruten este Sitio Web, hay mucho que aprender, además de que si están pensando montar un blog esta Web puede ser lo que estaban buscando.

Saludos,