Muy relacionado con mi último post, les dejo el link al código de una clase que se encarga de suspender y reanudar el redibujado de un control (o form en su totalidad si lo deseamos). La técnica se basa en el envío de mensajes al control o ventana en cuestión.

¡Nos vemos en el próximo post!

Publicado originalmente en http://gerardocontijoch.wordpress.com.

Si tenemos un Form y el SO determina que es necesario que sea redibujado (porque cambio su contenido por ejemplo), entonces se envía un mensaje conocido como WM_PAINT (en .NET veremos que esto dispara el evento Paint), en cambio si presionamos la tecla ‘Q’ en el teclado, entonces el mensaje recibido por nuestra aplicación es WM_KEYDOWN (también tenemos el evento KeyDown en .NET, el cual es lanzado cuando se recibe un mensaje de este tipo). Cabe aclarar que el nombre de los mensajes es solo una ayuda para nosotros los humanos, ya que los mensajes en realidad no son más que un valor entero, y estos nombres son los nombres de las constantes asociadas a los mismos.

Para interceptar estos mensajes lo que se suele hacer comúnmente es sobrescribir el método WndProc definido en la clase Control de la siguiente manera:

   1: ...

   2: private const int WM_PAINT = 15;

   3:

   4: protected override void WndProc(ref Message m) {

   5:

   6:     if (m.Msg == WM_PAINT) {

   7:         // Atrapamos el mensaje...

   8:     } else{

   9:         // Ignoramos el mensaje y dejamos que siga su curso

  10:         base.WndProc(ref m);

  11:     }

  12:

  13: }

  14: ...

El método WndProc es el que se encarga de procesar todos los mensajes que recibe un Form y es por eso que ese es el punto indicado para atraparlos.

Ahora el problema esta en conocer el valor de los mensajes, ya que muchas veces uno sabe que mensaje procesar, pero no sabe cual es su valor. Estos valores están definidos en la clase System.Windows.Forms.NativeMethods y System.Design.NativeMethods, pero lamentablemente estas clases son internas y no tenemos acceso a ellas, por lo que vamos a tener que usar .NET Reflector para ver su contenido.

La info de este post fue sacada de aquí.

¡Nos vemos en el próximo post!

Publicado originalmente en http://gerardocontijoch.wordpress.com.

Hoy regresé, aunque no se si por mucho tiempo ya que en realidad sigo bastante ocupado.

¡Nos vemos en el próximo post!

Publicado originalmente en http://gerardocontijoch.wordpress.com.

   1: <% for (int i = 0; i < 4; i++) {%>

   2:   <%= Html.CheckBox("checks", (object)new { value = "val" + i.ToString() })%><%= "Check " + i.ToString() %><br/>

   3: <%}%>

Sin embargo, rápidamente nos vamos a encontrar con dos problemas. El primero de ellos se hace presente dentro del código de la acción que se ejecuta al postear el form.

Dada la siguiente vista:

   1: <% using (Html.BeginForm("Index1", "Home", FormMethod.Post)) { %>

   2:     <% for (int i = 0; i < 4; i++) {%>

   3:         <%= Html.CheckBox("checks1", (object)new { value = "val" + i.ToString() })%><%= "Check " + i.ToString() %><br/>

   4:     <%}%>

   5:     <input type="submit" value="Post!" />

   6: <%}%>

veamos como recibimos los valores de los CheckBoxes si tildamos sólo los dos primeros CheckBoxes (los asociados a los valores ‘val0’ y ‘val1’):

Como se puede apreciar, lo que recibimos es un array de valores un tanto desconcertante. Esto se debe a la manera en que postea el valor de los CheckBoxes.

Posteo de Checkboxes

Un CheckBox no es más que un input de tipo checkbox en una página, el cual puede tener o no un valor asociado. A diferencia de como funciona un input de tipo text (un TextBox), el valor del checkbox sólo se postea si el mismo esta tildado. Esto significa que si en un form HTML no tildamos un CheckBox, su valor no será enviado al servidor, lo cual puede traer muchos problemas en ASP.NET MVC si nuestra acción (la asociada al form que posteamos) tiene que recibir como parámetro el valor del CheckBox, ya que la llamada fallará cuando este no este tildado y el DefaultModelBinder no pueda asignarle un valor al parámetro asociado al mismo (debido a que no se posteó).

Es por este problema que el método de extensión CheckBox renderiza dos inputs en vez de uno solo. El primer input es el propio CheckBox (un imput de tipo ‘checkbox’), y el segundo es un input de tipo hidden llamado igual, pero cuyo valor esta hardcodeado a ‘false’. Es decir, dado el siguiente código:

   1: <%= Html.CheckBox("checkbox") %>"Check"

se renderiza lo siguiente en la página:

   1: <input id="checkbox" type="checkbox" value="true" name="checkbox"/>

   2: <input type="hidden" value="false" name="checkbox"/>

   3: Check

   4: <br/>

Así, si posteamos el form sin tildar el CheckBox, se postea el valor del input oculto, es decir, para la variable del post ‘checkbox’ se asigna el valor ‘false’ (que en el servidor es transformado en el booleano False). En cambio, si tildamos el CheckBox, se postea el valor ‘true, false’ (uno por cada input). Este valor es procesado por el DefaultModelBinder y lo interpreta como el booleano True.

Posteo de más de un CheckBox

Hay que reconocer que es un método bastante ingenioso de resolver el problema, pero lamentablemente está pensado para funcionar sólo con un único CheckBox. Volviendo al ejemplo que presenté al comienzo de este post, se puede ver ahora que el array que recibimos en nuestra acción esta conformado por los valores asociados a cada uno de los CheckBoxes renderizados, esto es, se posteo ‘val0, false’ para el primer CheckBox, ‘val1, false’ para el segundo, ‘false’ para el tercero, y ‘false’ para el cuarto (recordemos que los dos últimos CheckBoxes no fueron tildados). Esta forma de recibir los parámetro puede ser bastante problemática. Por un lado, no podemos procesar los valores con un foreach ya que no todos los valores nos interesan, sólo aquellos que son distintos a ‘false’ nos resultan útiles. Uno podría discriminar estos valores para recuperar sólo el set que nos interesa, pero esto es posible únicamente si no posteamos valores booleanos ya que si efectivamente queremos un valor ‘false’ cuando no tildamos un CheckBox, no vamos a poder ubicarlo fácilmente dentro del array. Es verdad que uno puede imaginarse una lógica un tanto compleja en donde si se encuentra un valor ‘true’, entonces ignora el siguiente valor (que debería ser ‘false’), pero esto tiene una utilidad limitada, ya que muy posiblemente nos topemos con el segundo de los problemas que mencioné anteriormente.

Este segundo problema es similar al del posteo de los valores, pero se presenta a la hora de mostrarlos a los valores. Cuando posteamos un form en ASP.NET MVC los parámetros de las acciones se cargan en el ModelState, lo cual nos permite, al momento de renderizar la vista inicializar los valores de los controles con los valores posteados para que los mismos no aparezcan vacíos (recordemos que la web es stateless y luego de un post las páginas se vuelven a cargar desde cero). El modo de hacerlo es matcheando los nombres de los controles (atributo name) con las entradas del ModelState. Así, si tenemos un TextBox llamado ‘txtNombre’, ASP.NET MVC va a crear una entrada dentro del ModelState con el nombre ‘txtNombre’ asociado al valor posteado en el TextBox. Al momento de renderizar la página se consulta el ModelState y se cargan los valores posteados con anterioridad. Particularmente en nuestro caso, lo que se carga en el ModelState es un arrays de valores, el cual esta asociado a todos los CheckBoxes en el form. Y eso es un problema ya el método CheckBox() no esta preparado para procesar un array de valores, sino un único valor que determina si un CheckBox esta o no tildado (ese código puede verse claramente cerca de la línea 153 de la clase InputExtensions en el código fuente de ASP.NET MVC). Como consecuencia de esto, si tenemos más de un CheckBox con el mismo nombre en el form, los mismos no van a recuperar su estado anterior.

Un CheckBoxList que funciona

Dado ese problema, decidí crear un nuevo CheckBoxList personalizado (hay un par de implementaciones dando vueltas, pero no encontré ninguna que resolviera el segundo problema).

El código es bastante sencillo y esta ‘inspirado’ en el código del CheckBox original de ASP.NET MVC.

   1: public static partial class HtmlHelperExtensions {

   2:

   3:     public static string CheckBoxList(this HtmlHelper htmlHelper, string name, IEnumerable<string> values, object htmlAttributes) {

   4:         return CheckBoxList(htmlHelper, name, values, values, htmlAttributes);

   5:     }

   6:

   7:     public static string CheckBoxList(this HtmlHelper htmlHelper, string name, IEnumerable<string> values, IEnumerable<string> labels, object htmlAttributes) {

   8:         // No creamos ningun CheckBox si no hay valores

   9:         if (values == null) {

  10:             return "";

  11:         }

  12:

  13:         if (labels == null) {

  14:             labels = new List<string>();

  15:         }

  16:

  17:         RouteValueDictionary attributes = htmlAttributes == null ? new RouteValueDictionary() : new RouteValueDictionary(htmlAttributes);

  18:         attributes.Remove("checked");

  19:

  20:         StringBuilder sb = new StringBuilder();

  21:

  22:         string[] modelValues = new string[] { };

  23:

  24:         ModelState modelState;

  25:         if (htmlHelper.ViewData.ModelState.TryGetValue(name, out modelState)) {

  26:             modelValues = ((string[])modelState.Value.RawValue);

  27:         }

  28:

  29:         // Por cada valor pasado generamos un CheckBox

  30:

  31:         IEnumerator<string> labelEnumerator = labels.GetEnumerator();

  32:         foreach (string s in values) {

  33:             // Si el array contiene el valor correspondiente a este checkbox, entonces fue chequeado

  34:             bool isChecked = modelValues.Contains(s);

  35:             sb.Append(CrearCheckBox(name, s, isChecked, attributes));

  36:

  37:             labelEnumerator.MoveNext();

  38:             if (labelEnumerator.Current != null) {

  39:                 sb.AppendLine(labelEnumerator.Current);

  40:             }

  41:         }

  42:

  43:         // Creamos el div contenedor

  44:         TagBuilder divTag = new TagBuilder("div");

  45:         divTag.InnerHtml = sb.ToString();

  46:

  47:         // No nos olvidemos de indicar si hay un error en alguno de los checks

  48:         if (modelState != null && modelState.Errors.Count > 0) {

  49:             divTag.AddCssClass(HtmlHelper.ValidationInputCssClassName);

  50:         }

  51:

  52:         return divTag.ToString(TagRenderMode.Normal);

  53:     }

  54:

  55:     private static string CrearCheckBox(string name, string value, bool isChecked, IDictionary<string, object> htmlAttributes) {

  56:         TagBuilder tagBuilder = new TagBuilder("input");

  57:         tagBuilder.MergeAttributes(htmlAttributes);

  58:         tagBuilder.MergeAttribute("type", "checkbox");

  59:         tagBuilder.MergeAttribute("name", name, true);

  60:

  61:         tagBuilder.GenerateId(name);

  62:

  63:         if (isChecked) {

  64:             tagBuilder.MergeAttribute("checked", "checked");

  65:         }

  66:

  67:         if (value != null) {

  68:             tagBuilder.MergeAttribute("value", value, true);

  69:         }

  70:

  71:         return tagBuilder.ToString(TagRenderMode.SelfClosing);

  72:     }

  73: }

Su uso es muy sencillo:

   1: <%

   2:    List<string> values = new List<string>() { "val0", "val1", "val2", "val3", "val4" };

   3:    List<string> labels = new List<string>() { "Check 0", "Check 1", "Check 2", "Check 3", "Check 4" };

   4: %>

   5: <%= Html.CheckBoxList("checks3", values, labels, null) %>

Los valores en la acción son recibidos así:

El código podría mejorarse un poco más agregando la posibilidad de aplicarles estilos al div contenedor de los CheckBoxes, usar labels reales en vez de solo texto, agregar sobrecargas a los métodos, etc., pero preferí dejarlo así porque era más sencillo. Es preciso aclarar que este CheckBoxList, al igual que la primer alternativa que presenté, no va a funcionar bien con valores booleanos ya que la idea es que los valores asociados a cada uno de los CheckBoxes sean únicos.

Si encuentran algún bug o tienen algo que aportar, no duden en comentarlo.

¡Nos vemos en el próximo post!

Publicado originalmente en http://gerardocontijoch.wordpress.com.

Es una pregunta interesante ya que normalmente uno enlaza a mano los eventos que desea capturar, pero en el caso de los eventos de la clase HttpApplication, la situación es diferente porque no podemos enlazarlos nosotros mismos (en realidad si podemos, pero no tiene ningún efecto). Veamos como es el asunto.

Cuando agregamos un archivo Global.asax a nuestro proyecto vemos que la clase Global ya posee algunos handlers creados:

   1: public class Global : System.Web.HttpApplication {

   2:

   3:     protected void Application_Start(object sender, EventArgs e) { }

   4:

   5:     protected void Session_Start(object sender, EventArgs e) { }

   6:

   7:     protected void Application_BeginRequest(object sender, EventArgs e) { }

   8:

   9:     protected void Application_AuthenticateRequest(object sender, EventArgs e) { }

  10:

  11:     protected void Application_Error(object sender, EventArgs e) { }

  12:

  13:     protected void Session_End(object sender, EventArgs e) { }

  14:

  15:     protected void Application_End(object sender, EventArgs e) { }

  16: }

Lógicamente, al handler Application_Start nunca vamos a poder enlazarlo nosotros mismos ya que el mismo es ejecutado cuando la aplicación se inicia, pero el resto parecería que si podría ser enlazado debido a que ocurre luego de la inicialización de la aplicación. Bueno, no es tan así.

Para empezar, Application_Start, Application_End y Session_End parecen handlers pero en realidad no existe ningún evento asociado a los mismos, por lo que no es posible enlazarlos de otra manera. La clase HttpApplicationFactory es la encargada de simular estos eventos con los métodos FireApplicationOnStart(), FireApplicationOnEnd() y FireSessionOnEnd().

Segundo, el resto de los handlers no son mas que accesos directos a los eventos de distintos módulos (clases que implementan IHttpModule) que pueden ser cargados. Estos módulos son configurados en el archivo web.config en la seccion <httpModules>. Por ejemplo, uno de los que se carga por defecto es el llamado Session (de tipo System.Web.SessionState.SessionStateModule). El mismo es el encargado de mantener una sesión entre distintos requests y su carga esta definida en el archivo web.config que se encuentra en %WIN_DIR%\Microsoft.NET\Framework\[VERSION_FRAMEWORK]\CONFIG\ (este web.config se carga para todas las aplicaciones que se corran en nuestro equipo). Si en el web.config de nuestra aplicación agregamos la siguiente línea a la sección <httpModules>:

   1: <remove name="Session"/>

veremos que el handler Session_Start no se ejecuta más, ya que no hay ningún módulo llamado Session que provoque un evento Start (y como consecuencia, nuestra aplicación ya no tiene soporte para sesiones). Como no tenemos acceso a esos módulos sino hasta que la aplicación ya haya sido inicializada, no hay manera de enlazar esos eventos con los handlers y por eso necesitamos estos accesos directos que nos provee la clase HttpApplication.

Como se puede ver en el artículo original de Rick Strahl, el enlace ocurre en un método llamado HookupEventHandlersForApplicationAndModules() (con ese nombre, ¿a alguien le queda alguna duda de ello?). Resumiendo la funcionalidad del método, básicamente lo que sucede es que, dado un array de objetos MethodInfo (son cada uno de los handlers que creamos), se itera sobre ellos y se determina si el evento es de la aplicación o pertenece a algún módulo. Esto se logra buscando el ‘_’ en el nombre del mismo y tomando la primer parte. Luego se guarda una referencia a la instancia de HttpApplication o al módulo y se busca via reflection el evento en base al nombre del método (el evento ‘Start’ se asocia al método terminado en ‘Start’, por ejemplo). Un detalle curioso es que esta lógica reconoce a ‘Application_BeginRequest’ y a ‘Application_OnBeginRequest’ como lo mismo, teniendo precedencia el primero si es que se encuentran ambos presentes. Luego se valida que el handler tenga los parámetros correctos y si no es así, se genera un proxy para el mismo (lo que significa que nuestros handlers pueden no aceptar ningún parámetro y van a a ser igual de válidos). Finalmente después de obtener una referencia al evento correcto, se invoca al método Add del mismo para asociar nuestra instancia de MethodInfo (o el proxy que mencioné hace un momento) al evento y de este modo, cuando ocurra, se ejecuta nuestro handler.

¿Muy complicado? Si, seguro, la clase HttpApplication es una de las más complejas de .NET Framework, pero eso es lo que la hace interesante, ¿no?

¡Nos vemos en el próximo post!

Publicado originalmente en http://gerardocontijoch.wordpress.com.

El problema se presentó cuando uno de los campos del form con el que estaba trabajando no se actualizaba luego de un postback. El form no tenia nada de especial, sólo un par de campos, y su posteo provocaba la ejecución de una acción que tampoco hacia nada muy loco. Lo único destacable era que el parámetro con problemas era cargado con un ModelBinder personalizado, pero el mismo funcionaba bien y lo inicializaba correctamente al valor. Lo primero que hice fue verificar que las variables del post lleguen correctamente al server. También verifiqué que no haya ningún código javascript interfiriendo con el llenado de campos. Lo que más me desconcertó fue que dentro de la acción, el parámetro cuyo valor tenia problemas estaba correctamente inicializado, cosa que no esperaba (lo que me llevó a pensar que no había un error en el ModelBinder). Sin embargo había un detalle que pasé de largo: entre los valores del ModelState del request no se encontraba el parámetro con problemas. Fue cuando descubrí eso que supe donde estaba el problema. Un poco más de investigación me confirmó las sospechas. Pero antes de explicarles el problema, veamos el código del ModelBinder:

   1: public class TipoDeOperacionModelBinder : IModelBinder {

   2:     #region IModelBinder Members

   3:

   4:     public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) {

   5:

   6:         if (bindingContext == null) {

   7:             throw new ArgumentNullException("bindingContext");

   8:         }

   9:

  10:         ValueProviderResult val;

  11:         if (!bindingContext.ValueProvider.TryGetValue(bindingContext.ModelName, out val)) {

  12:             // Si no encontramos el valor, devolvemos null y ASP.NET MVC se encarga de provocar la excepción necesaria

  13:             return null;

  14:         }

  15:

  16:         int realVal = (int)val.ConvertTo(typeof(int));

  17:         return (TipoDeOperacion)realVal;

  18:     }

  19:

  20:     #endregion

  21: }

Este ModelBinder simplemente toma un valor (indicado por bindingContext.ModelName) y lo transforma en un Enum de tipo TipoDeOperacion. Cabe aclarar que este ModelBinder esta registrado para el tipo TipoDeOperacion, por lo que el propio framework es el encargado de hacer uso del mismo cuando necesite hacer el binding de un parámetro de tipo TipoDeOperacion.

Como dije antes, el parámetro en cuestión se inicializaba correctamente, lo que confirmaba que las variables del post llegaban sin problemas. El problema estaba en que no se encontraba dentro del ModelState y eso se debe sencillamente a que en ningún lugar del código del ModelBinder lo estoy agregando. Resulta que el ModelBinder no solo es responsable de cargar los parámetros de las acciones y actualizar el modelo con el que estamos trabajando, sino que ¡también debe inicializar el ModelState! El resto de los parámetros de la acción no tenían problemas ya que eran procesados por la clase DefaultModelBinder, la cual se encarga de todo. Todo se resolvió cuando agregué el siguiente código en la línea 15:

bindingContext.ModelState.SetModelValue(bindingContext.ModelName, val);

Parece una pavada de detalle, pero esa sola línea de código me hizo perder varias horas de trabajo por no saber que el ModelState era cargado por los ModelBinders. Esto demuestra la importancia de entender bien las herramientas y frameworks con los que uno trabaja. ASP.NET MVC nos provee de montones de puntos de extensión, pero de nada sirve si no los sabemos aprovechar correctamente.

¡Nos vemos en el próximo post!

Publicado originalmente en http://gerardocontijoch.wordpress.com.

Cabe aclarar que el comportamiento que voy a describir a continuación esta basado en ASP.NET 4.0 CTP y no en la versión definitiva (la cual no salió aún), pero imagino que este es uno de los puntos en donde no va a cambiar el funcionamiento. Otro punto a aclarar es que el id se ve modificado sólo del lado del cliente, es decir, el código del lado del servidor no se ve modificado en nada.

El atributo ClientIDMode

La personalización del Id ahora se puede realizar mediante un nuevo atributo de los controles web llamado ClientIDMode. Dependiendo de su valor, el id generado para el control que lo aplique puede ser fijo (siempre el mismo), dinámico (basado en datos asociados al control) o automático (es decir, igual que en las versiones anteriores de ASP.NET).

Sus valores posibles son:

• Legacy
• Static
• Predictable
• Inherit

Veamos uno por uno.

Legacy

Este valor indica que el comportamiento de ASP.NET al generar el id va a ser igual al de las versiones anteriores, es decir, el id va a tener el siguiente formato: [IdControlContenedor]_[IdControlHijo].

Static

Éste sea posiblemente el valor más utilizado ya que indica que el id generado sea el que definimos nosotros (es decir, que quede estático o fijo) y no se vea modificado por nada. Hay que tener en mente que esto puede traer conflictos de ids si hay un contenedor con un control con el mismo id dentro de este. Por ejemplo:

   1: <body>

   2:     <form id="form1" runat="server">

   3:     <div>

   4:         <asp:TextBox ID="txtNombre" runat="server" ClientIDMode="Static"></asp:TextBox>

   5:         <uc1:MiControlWeb ID="MiControlWeb1" runat="server" />

   6:     </div>

   7:     </form>

   8: </body>

Donde MiControlWeb esta definido así:

   1: <%@ Control Language="C#" AutoEventWireup="true" CodeFile="MiControlWeb.ascx.cs" Inherits="WebUserControl" %>

   2: <asp:TextBox ID="txtNombre" runat="server" ClientIDMode="Static"></asp:TextBox>

Esto quedaría renderizado así:

   1: <div>

   2:   <input name="txtNombre" type="text" id="txtNombre" />

   3:   <input name="MiControlWeb$txtNombre" type="text" id="txtNombre" />

   4: </div>

Este atributo no debería usarse nunca dentro de un control como Repeater, ya que los ids de los controles contenidos en el serían todos iguales.

Inherit

Este es el modo por defecto, y simplemente indica que el valor de ClientIDMode se hereda del contenedor donde se encuentre el control (como pueden ser un WebControl, un ContentPlaceHolder – en MasterPages- o una página).

Predictable

Este modo de generación produce resultados similares al modo Legacy pero, como lo indica su nombre, los valores son predecibles. Es principalmente útil en los controles enlazados a datos. El id en este caso se genera mediante el uso del dato asociado o enlazado al control. Veamos como funciona.

Dado este control:

   1: <asp:GridView ID="gvPersonas" runat="server" AutoGenerateColumns="false" ClientIDMode="Predictable">

   2: <Columns>

   3:     <asp:TemplateField HeaderText="Id">

   4:          <ItemTemplate>

   5:               <asp:Label ID="lblPersonaId" runat="server" Text='<%# Eval("Id") %>' />

   6:          </ItemTemplate>

   7:     </asp:TemplateField>

   8:     <asp:TemplateField HeaderText="Nombre">

   9:          <ItemTemplate>

  10:               <asp:Label ID="lblNombre" runat="server" Text='<%# Eval("Nombre") %>' />

  11:          </ItemTemplate>

  12:     </asp:TemplateField>

  13:     <asp:TemplateField HeaderText="Apellido">

  14:          <ItemTemplate>

  15:               <asp:Label ID="lblApellido" runat="server" Text='<%# Eval("Apellido") %>' />

  16:          </ItemTemplate>

  17:     </asp:TemplateField>

  18: </Columns>

  19: </asp:GridView>

El Html renderizado se vería así:

   1: <table id="gvPersonas" style="border-collapse: collapse" cellspacing="0" rules="all" border="1">

   2:   <tbody>

   3:     <tr>

   4:        <th scope="col">Id</th>

   5:        <th scope="col">Nombre</th>

   6:        <th scope="col">Apellido</th>

   7:     </tr>

   8:     <tr>

   9:        <td><span id="gvPersonas_lblPersonaId_0">1</span></td>

  10:        <td><span id="gvPersonas_lblNombre_0">Juan (primer persona)</span></td>

  11:        <td><span id="gvPersonas_lblApellido_0">Lopez</span></td>

  12:     </tr>

  13:     ...

  14:     <tr>

  15:        <td><span id="gvPersonas_lblPersonaId_35">36</span></td>

  16:        <td><span id="gvPersonas_lblNombre_35">Gerardo (36ta persona)</span></td>

  17:        <td><span id="gvPersonas_lblApellido_35">Contijoch</span></td>

  18:     </tr>

  19:   </tbody>

  20: </table>

Noten el sufijo numérico al final de los Ids. Este sufijo puede ser personalizado en los controles enlazados a datos para que sea otro valor y no un simple índice. Esto se logra mediante la aplicación del atributo RowClientIDSuffix. El valor de este atributo debe ser nombre de la propiedad o columna (dependiendo del origen de datos) cuyo valor deseamos incluir en el Id. Veamos un ejemplo para aclarar esto. Dado este código:

   1: <asp:GridView ID="gvPersonas" runat="server" AutoGenerateColumns="false" ClientIDMode="Predictable" RowClientIDSuffix="Apellido">

   2: <Columns>

   3:     <asp:TemplateField HeaderText="Id">

   4:          <ItemTemplate>

   5:               <asp:Label ID="lblPersonaId" runat="server" Text='<%# Eval("Id") %>' />

   6:          </ItemTemplate>

   7:     </asp:TemplateField>

   8:     <asp:TemplateField HeaderText="Nombre">

   9:          <ItemTemplate>

  10:               <asp:Label ID="lblNombre" runat="server" Text='<%# Eval("Nombre") %>' />

  11:          </ItemTemplate>

  12:     </asp:TemplateField>

  13:     <asp:TemplateField HeaderText="Apellido">

  14:          <ItemTemplate>

  15:               <asp:Label ID="lblApellido" runat="server" Text='<%# Eval("Apellido") %>' />

  16:          </ItemTemplate>

  17:     </asp:TemplateField>

  18: </Columns>

  19: </asp:GridView>

Se genera lo siguiente:

   1: <table id="gvPersonas" style="border-collapse: collapse" cellspacing="0" rules="all" border="1">

   2:   <tbody>

   3:     <tr>

   4:        <th scope="col">Id</th>

   5:        <th scope="col">Nombre</th>

   6:        <th scope="col">Apellido</th>

   7:     </tr>

   8:     <tr>

   9:        <td><span id="gvPersonas_lblPersonaId_Lopez">1</span></td>

  10:        <td><span id="gvPersonas_lblNombre_Lopez">Juan (primer persona)</span></td>

  11:        <td><span id="gvPersonas_lblApellido_Lopez">Lopez</span></td>

  12:     </tr>

  13:     ...

  14:     <tr>

  15:        <td><span id="gvPersonas_lblPersonaId_Contijoch">36</span></td>

  16:        <td><span id="gvPersonas_lblNombre_Contijoch">Gerardo (36ta persona)</span></td>

  17:        <td><span id="gvPersonas_lblApellido_Contijoch">Contijoch</span></td>

  18:     </tr>

  19:   </tbody>

  20: </table>

Si prestan atención, verán que el sufijo ahora es el valor del campo Apellido en nuestro origen de datos. Una característica interesante del atributo RowClientIDSuffix es que acepta más de un único valor, por lo que es posible definir nuestro control así:

   1: <asp:GridView ID="gvPersonas" ... ClientIDMode="Predictable" RowClientIDSuffix="Id, Apellido">

Generando un HTML como este:

   1: ...

   2: <tr>

   3:    <td><span id="gvPersonas_lblPersonaId_1_Lopez">1</span></td>

   4:    <td><span id="gvPersonas_lblNombre_1_Lopez">Juan (primer persona)</span></td>

   5:    <td><span id="gvPersonas_lblApellido_1_Lopez">Lopez</span></td>

   6: </tr>

   7: ...

Se puede ver que el sufijo ahora consiste en el campo Id y el campo Apellido.

Referencias:

• ASP.NET 4.0 Client ID Feature
• Overview of .NET 4.0 features: ASP.NET 4.0 ClientIDMode
• ASP.NET 4.0: Way too much information on Control IDs and ASP.NET 4.0 Client Id Enhancements

¡Nos vemos en el próximo post!

Publicado originalmente en http://gerardocontijoch.wordpress.com.

El caso más común con el que me encuentro yo es conocer el id de ciertos controles desde el lado del cliente. Sabemos bien que ASP.NET tiene la costumbre de renombrar nuestros controles con unos nombres bastante crípticos y esto es un gran problema si queremos acceder a ellos desde javascript. El verdadero nombre de estos controles (lo que se conoce como el ClientId) se encuentra accesible desde el código del lado del servidor, pero no desde el cliente. Y es por esto que Rick Strahl creo la clase wwScriptVariables que nos permite pasarle a nuestros scripts los valores que querramos desde el servidor.

Veamos un ejemplo con el cual vamos a trabajar. Imaginemos que tenemos una página en donde se ingresa un valor y como respuesta, se informa si ese valor es numérico o no. Esta es la parte interesante del código HTML:

   1: <div id="valor">Ingrese un valor: <asp:TextBox ID="txtValor" runat="server"></asp:TextBox>

   2:     <asp:Button ID="btnEnviar" runat="server" Text="Enviar" onclick="btnEnviar_Click" />

   3: </div>

   4: <div id="resultado">

   5:     <asp:Label ID="lblResultado" runat="server" Text=""></asp:Label>

   6: </div>

Y este es el código del lado del servidor:

   1: using System;

   2:

   3: public partial class _Default : System.Web.UI.Page

   4: {

   5:     protected void Page_Load(object sender, EventArgs e){}

   6:

   7:     protected void btnEnviar_Click(object sender, EventArgs e) {

   8:         if (EsNumero(this.txtValor.Text)) {

   9:             this.lblResultado.Text = "Es un número!";

  10:         } else {

  11:             this.lblResultado.Text = "No es un número!";

  12:         }

  13:     }

  14:

  15:     private bool EsNumero(string valor) {

  16:         int val = 0;

  17:         if (int.TryParse(valor, out val)) {

  18:             return true;

  19:         }

  20:         return false;

  21:     }

  22: }

Si ingresamos un valor numérico el resultado se vería así:

Como se ve puede ver, todo es muy sencillo, pero imaginemos que queremos aplicarle algún efecto a la página dependiendo del resultado. En mi caso voy a usar jQuery para esto y el efecto va a consistir simplemente en aplicarle un estilo a la respuesta (ya se que lo mismo se puede hacer desde el lado del servidor, pero la idea es modificarlo desde el lado del cliente como un ejemplo).

Normalmente uno agregaría algo similar a esto en la sección head de la página:

   1: <link href="style.css" rel="stylesheet" type="text/css" />

   2:

   3: <script src="jquery-1.2.6.min.js" type="text/javascript"></script>

   4:

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

   6:   $(document).ready(function() {

   7:

   8:     var lbl = $("#lblResultado");

   9:

  10:     lbl.addClass("claseResultado");

  11:

  12:     });

  13: </script >

Pero eso sólo funciona cuando nuestro control (en este caso el label ‘lblResultado’) no se encuentra dentro de un contenedor, como puede ser una grilla o una master page. Esto se debe a que ASP.NET modifica los Id de los elementos renderizados para evitar la colisión de nombres y por eso, nuestro ‘lblResultado’ se puede transformar en algo como ‘ctl00_ContentPlaceHolder1_lblResultado’ provocando un error en nuestro script. Lo que necesitamos es pasarle a nuestros scripts el verdadero nombre de los controles lo que se puede lograr con algunos code nuggets incrustados en medio de nuestro script:

   1: $(document).ready(function() {

   2:     var lbl = $("#<%= lblResultado.ClientId %>");

   3:     lbl.addClass("claseResultado");

   4: });

Pero esto tiene algunos problemas. Primero y principal, si nuestro script esta en un archivo externo y no embebido en la página, no se pueden usar code nuggets. Otro problema es que el valor que pasemos tiene que estar correctamente escapado para que javascript no lo malinterprete o falle. Sumado a esto, no es muy elegante la solución de incrustar código de servidor dentro de un script y no facilita para nada la reutilización de los scripts.

Ahora veamos como solucionamos este inconveniente con la ayuda de wwScriptVariables. Su uso es sencillísimo, solo hay que instanciarla y mediante el método Add() agregamos los valores que queremos pasarle a nuestros scripts. Luego, desde el lado del cliente, podemos acceder a estos valores desde una nueva variable que tendremos a nuestra disposición, la cual es generada (durante el renderizado) por la clase wwScriptVariables. Veamos como queda nuestro ejemplo con el uso de esta clase.

Del lado del servidor:

   1: using System;

   2:

   3: public partial class NuevaVersion : System.Web.UI.Page

   4: {

   5:     protected void Page_Load(object sender, EventArgs e){}

   6:

   7:     protected void btnEnviar_Click(object sender, EventArgs e) {

   8:

   9:         Westwind.Web.Controls.Controls.wwScriptVariables scriptVar = new Westwind.Web.Controls.Controls.wwScriptVariables(this, "variables");

  10:         scriptVar.Add("lblResultado", this.lblResultado.ClientID);

  11:

  12:         if (EsNumero(this.txtValor.Text)) {

  13:             scriptVar.Add("esNumero", "true");

  14:             this.lblResultado.Text = "Es un número!";

  15:         } else {

  16:             scriptVar.Add("esNumero", "false");

  17:             this.lblResultado.Text = "No es un número!";

  18:         }

  19:     }

  20:

  21:     private bool EsNumero(string valor) {

  22:         int val = 0;

  23:         if (int.TryParse(valor, out val)) {

  24:             return true;

  25:         }

  26:         return false;

  27:     }

  28: }

y del lado del cliente:

   1: $(document).ready(function() {

   2:     var lbl = $("#" + variables["lblResultado"]);

   3:

   4:     // Aplicamos distintas clases dependiendo del resultado

   5:     if (variables["esNumero"] == "true")

   6:     {

   7:         lbl.addClass("resultadoNumero");

   8:     } else {

   9:         lbl.addClass("resultadoTexto");

  10:     }

  11: });

El funcionamiento de la clase es muy sencillo, básicamente lo que hace es registrar los valores que queremos pasar al cliente y dentro del evento PreRender genera el siguiente script:

   1: <script type="text/javascript">

   2: //<![CDATA[

   3: var variables = {

   4:     "lblResultado": 'ctl00_ContentPlaceHolder1_lblResultado',

   5:     "esNumero": 'false'

   6: }

   7: //]]>

   8: </script >

Lo mejor de todo es que Rick pone a nuestra disposición el código completo de la clase para que la modifiquemos a gusto si así lo que deseamos.

La página donde pueden bajar esta clase es ésta, pero aclaro que esa es una versión vieja, hay una versión más nueva acá, la cual agrega nuevas funcionalidades como la posibilidad de actualizar el valor de las variables desde el cliente y pasárselas al servidor. Si no nos interesa esto último, les recomiendo usar la primer versión, ya que tiene menos dependencias y es mucho mas liviana.

¡Nos vemos en el próximo post!

Publicado originalmente en http://gerardocontijoch.wordpress.com.

TraceTool consiste en una librería (disponible para .NET, Java, Delphi, Javascript, entre otros lenguajes) para hacer tracing o logging (como prefieran llamarlo) y un visor (de uso opcional) que es capaz de interpretar tanto los logs o trazas generadas por la librería como así también otros orígenes.

En este post me voy a limitar a hacer una presentación de la herramienta (actualmente en su versión 11), pero para más información pueden consultar el artículo original, el cual contiene muchos más detalles sobre el funcionamiento y configuración de la misma.

Uso de la librería

En la mayoría de los casos la única clase con la que vamos a necesitar interactuar directamente es TTrace. Esta clase expone 3 propiedades, Debug, Warning y Error, las cuales se utilizan para registrar logs de información, advertencia y errores respectivamente. Veamos un ejemplo:

   1: public void Log() {

   2:     TTrace.Debug.Send("Esto es un mensaje.");

   3:     TTrace.Warning.Send("Esto es una advertencia...");

   4:     TTrace.Error.Send("Esto es un mensaje de error!");

   5: }

Ese código produce la siguiente salida (vista en el visor de TraceTool):

Como se ve, lo único que diferencia a cada tipo de mensaje, es el icono que lo precede. Si lo deseamos, también podemos agregar un comentario o texto asociado al mensaje de la siguiente manera:

TTrace.Debug.Send("Esto es un mensaje.", "Texto con info extra sobre el mensaje...");

Que nos quedaría así en el visor:

Una característica por de más de interesante es el hecho de que el método Send() nos devuelve una instancia de un objeto de tipo TraceNode (que es la clase base de la cual derivan los objetos Debug, Warning y Error), la cual nos permite seguir enviando trazas pero anidadas dentro de la traza original (es decir, sub-trazas):

   1: TraceNode nodo = TTrace.Debug.Send("Nodo nivel 0.");

   2: nodo.Send("¡Me encuentro en el nivel 1!");

   3: nodo.Send("¡Yo tambien!");

   4: nodo.Send("¡Y yo!");

   5: TTrace.Debug.Send("Otro nodo nivel 0.");

Un efecto parecido se puede lograr con los métodos Indent() y UnIndent() que nos permiten indentar todas las trazas sin necesidad de guardar una referencia a un nodo en particular. Esto suele ser muy útil cuando logueamos las entradas, procesamiento y salidas de ciertos métodos aunque para ello TraceTool ya tiene un set de métodos específicamente adaptado para tal fin:

   1: private void UnMetodo() {

   2:     TTrace.Debug.EnterMethod("UnMetodo()");

   3:

   4:     try {

   5:         TTrace.Debug.Send("Procesando...");

   6:         // ...

   7:         throw new Exception();

   8:     } catch {

   9:         // Aca se podría loguear la excepción

  10:         TTrace.Error.Send("Error!");

  11:     } finally {

  12:         TTrace.Debug.ExitMethod("UnMetodo()");

  13:     }

  14: }

Esto produce la siguiente salida:

Loguear más que sólo texto

Con TraceTool también es posible loguear el contenido de objetos enteros con la misma facilidad con la que logueamos sólo texto:

   1: public class Persona {

   2:     public string Nombre { get; set; }

   3:     public string Apellido { get; set; }

   4:     public int Edad { get; set; }

   5: }

   6:

   7: /*...*/

   8:

   9: TTrace.Debug.Send("Logueando solo texto");

  10: var p = new Persona() { Nombre = "Gerardo", Apellido = "Contijoch", Edad = 27 };

  11: TTrace.Debug.SendObject("Logueando un objeto", p);

También es posible incluir en la información a loguear sobre un objeto detalles como sus campos, métodos, eventos, miembros privados, etc.

En el caso que quisiéramos registrar el valor de una variable de un tipo primitivo, como puede ser un número, este método no resulta práctico (¿para qué mostrar información de la clase Int32 cuando solo queremos su valor?) y es por eso que la clase TraceNode posee el método SendValue():

   1: TTrace.Debug.SendValue("Logueando un Int32", 50);

   2: TTrace.Debug.SendValue("Logueando un DateTime", new DateTime(2005, 10, 6));

   3: TTrace.Debug.SendValue("Logueando un Boolean", false);

(Los logs pueden configurarse para que no se registre la información como la hora y el hilo en el que se ejecutó el logueo)

Como si todo esto fuera poco, también existen métodos similares para registrar Xmls (AddXml()), imágenes (SendBitmap()) y hasta tablas (SendTable()). Pueden ver su uso en el artículo donde se presenta TraceTool.

Configuración

Hay dos puntos donde se puede configurar el logueo. El primero es la propiedad Options de la clase TTrace. Esta propiedad nos va a permitir configurar el formato de los logs que se registren.

Para controlar la verbosidad de los logs se pueden usar las propiedades SendEvents, SendFunctions, SendInherited, SendPrivate, SendProcessName y SendThreadId, las cuales permiten configurar que información se registra sobre los objetos que logueamos.

La otra propiedad importante de esta clase es SendMode, la cual nos permite indicarle a la API si vamos a enviar logs al visor (util cuando se depura, pero no siempre en producción) o no.

El otro punto donde podemos configurar el logueo es la propiedad WinTrace de TTrace. TTrace internamente utiliza a la clase WinTrace para registrar todo y es por ello que algunos parámetros referidos al logueo se especifican acá.

Para setear el path a un archivo de logs vamos a usar el método SetLogFile(). Junto con el path de logs también se puede configurar el particionamiento de los logs, es decir, si se crea un log diferente por día, por máximo de líneas o simplemente un único log ilimitado.

Lamentablemente, los logs son únicamente en formato Xml y esto no se puede cambiar.

Cabe aclarar que TraceTool tiene 2 logs diferentes, uno es el local (el que normalmente usaremos nosotros) y otro es el log del Visor, el cual puede registrar todo lo que se le envíe (usar este log es útil cuando hay mas de una aplicación logueando al mismo lugar). Ambos logs pueden ser configurados independientemente el uno del otro. Para más detalles sobre la configuración pueden ver el artículo original en donde se detalla un poco más el asunto.

Soporte Unicode

Desafortunadamente, si bien la API tiene soporte para logs encodeados como Unicode, el visor aún no los soporta y no es posible abrir logs con caracteres especiales. Es por ello que vamos a tener que cuidarnos de lo que guardamos en los logs porque puede que no podamos abrirlos con el visor. Para solucionar esto, yo opté por modificar la API (el código fuente esta disponible para bajar) y filtrar todos los caracteres especiales con una versión ligeramente modificada del método que presenté en este post (ojo con las tablas, que necesitan los caracteres ‘\t’ para ser procesadas correctamente).

Bien, como dije al comienzo, esto fue sólo una breve presentación de la herramienta, no quise entrar en muchos detalles porque iba a terminar siendo una reescritura completa del artículo original de Thierry Parent. Espero que les resulte interesante esta herramienta y por sobretodo, útil.

¡Nos vemos en el próximo post!

Publicado originalmente en http://gerardocontijoch.wordpress.com.

Yo me inclino por la primera (aunque ello no quita que la segunda pueda ser válida también).

Como regla general, si nuestro handler guarda información (en una propiedad o un campo) referente a un request en particular, entonces la propiedad debería devolver false ya que otro request podría estar siendo procesado con la información incorrecta. Acá se puede ver un ejemplo del problema este.

¡Nos vemos en el próximo post!

Publicado originalmente en http://gerardocontijoch.wordpress.com.