Enadan's Blog

Cambio de blog

2006-02-06T09:52:00.000+01:00

Simplemente comunicar que he creado un nuevo blog, en ingles, y no creo que tenga tiempo de postear en ambos, asi que sintiendolo mucho de momento no volvere a escribir aqui.

Podeis seguir leyendo mis posts en http://blogs.clearscreen.com/enadan

Un saludo.

Lectura recomendada

2006-01-17T17:57:00.000+01:00

Aqui dejo un link a un articulo sobre SOA que esta bastante bien.

Principios de diseño de servicios: patrones y antipatrones de servicios

Enhorabuena Miguel

2006-01-10T14:49:00.000+01:00

Hace tiempo escribi un Post (Grupo de usuarios de .NET en Madrid) avisando de la creacion del grupo de usuarios de .NET en Madrid MAD.NUG.

Pues ahora quiero volver a felicitar a Miguel, amigo y compañero de trabajo, ya que ha sido recientemente nombrado MVP de C# en España.

Podeis ver su perfil MVP aqui

Creo que si le conocierais pensariais lo mismo que yo.... ENHORABUENA, TE LO MERECIAS!!

IsNumeric en C#

2006-01-04T11:23:00.000+01:00

Hay muchas formas de hacer esto, pero creo que la mejor es usar Expresiones Regulares, ya que poner el tipico try{} catch{} con un Convert.To...() dentro funciona bien pero si falla la conversion penaliza mucho en performance, ya que lanzar una excepcion es algo muy pesado en .NET.

Os dejo el codigo que creo que se explica bien por si solo, aunque la verdad es que se ve fatal.
Faltaria incluir si quieren usarse o no separadores de miles.... pero creo que esto os dara la base para terminarlo, no?!

class NumericHelper
{
private const string regExNumericParse = @"^-{0,1}\d+$";
private const string regExNumericParseWithDot = @"^-{0,1}\d*\.{0,1}\d+$";
private const string regExNumericParseWithComma = @"^-{0,1}\d*\,{0,1}\d+$";

public static bool IsNumeric(string number)
{
return IsNumeric(number, ' ');
}

public static bool IsNumeric(string number, char decimalSeparator)
{
if (decimalSeparator != '.' && decimalSeparator != ',' && decimalSeparator != ' ')
{
throw new ArgumentException("decimalSeparator must be '.' or ','", "decimalSeparator");
}
switch (decimalSeparator)
{
case '.':
return Regex.IsMatch(number.Trim(), regExNumericParseWithDot);
case ',':
return Regex.IsMatch(number.Trim(), regExNumericParseWithComma);
case ' ':
return Regex.IsMatch(number.Trim(), regExNumericParse);
}
return false;
}
}

Defensive programing in custom controls

2005-12-18T18:41:00.000+01:00

Una de las Best Practices de todos los proyectos es tener tu propia coleccion de Custom Controls aunque a priori no vayamos a necesitarla. Basta con que heredemos de los controles del framework y cuando necesitemos implementar algo en todo nuestro proyecto veremos recompensada esta accion.

En mi proyecto tenemos todos los controles de la UI customizados y hemos ido añadiendo funcionalidad poco a poco, pero el otro dia me encontre un problema que os detallo a continuacion, asi como la solucion que elegimos para arreglarlo.

Muchas veces cuando creamos un control que va a usarse en todo nuestro proyecto no pensamos en todas posibles situaciones en las que este va a ser usado. Es imposible. Por motivos funcionales nos vimos obligados a añadir una serie de atributos a todos los controles, para diseñar un mecanismo que detectara en cliente si se habia modificado algun valor y poder preguntar asi al usuario si queria guardar los cambios antes de proceder a la navegacion hacia otra pagina de la aplicacion.

Pues nos pusimos manos a la obra. En nuestro CustomTextBox añadimos en el PreRender un atributo "onchange" que cambiaba el valos de un HiddenField marcando la pagina como "modificada".

Un mes mas tarde alguien necesitaba añadir cierta logica cliente para que, en un textbox determinado, al cambiar de valor, realizara una comprobacion de si este nuevo valor cumplia con una serie de restricciones. La persona encargada de esto hizo lo que tenia que hacer, añadio un atributo "onchange" a su textbox y la llamada a la funcion javascript que se habia creado, pero no le funcionaba. Despues de varias horas pensando que el problema era suyo, vino a hablar conmigo y vimos que su codigo era perfecto, el problema venia de mas arriba.

Al añadir en el PreRender del CustomTextBox el atributo "onchange" para el mecanismo de deteccion de cambios estabamos machacando cualquier otro atributo "onchange" que alguien, desde cualquier pagina de la aplicacion, quisiera añadir.

La solucion.

Despues de pensar en cual seria la mejor solucion para evitar esto hicimos lo siguiente. Antes de añadir cualquier atributo en cualquiera de nuestros Custom Controls decidimos chequear si ese atributo ya existia, y en ese caso, si el valor del atributo no era el mismo que queriamos añadir, lo concatenabamos para que se llamara a ambos.

Despues de ver que esto funcionaba perfectamente hicimos un pequeño refactoring para que quedara mas bonito y no tener codigo duplicado, creando un metodo del tipo AddAttributeSafety(string attibuteType, string attributeValue) que hacia todo lo que explicaba antes.

Solo una ultima cosa. Siempre que añadais un atributo para hacer cosas en cliente a un control, aseguraros de que terminais el codigo del valor del atributo con ";", porque si no no podreis concatenar mas de una accion sobre el mismo evento.

Este es el codigo del metodo para añadir atributos de forma segura en Custom Controls:

private void AddAttributeSafety(string attributeType, string attributeValue)
{
if (attributeType.Length == 0 attributeValue.Length == 0)
{
return;
}

if (Attributes[attributeType] == null Attributes[attributeType].Length == 0)
{
Attributes.Add(attributeType, attributeValue);
}
else
{
string existingAttribute = Attributes[attributeType];
if (existingAttribute.IndexOf(attributeValue) == -1)
{
Attributes.Add(attributeType, existingAttribute + attributeValue);
}
}
}

Como siempre espero que le sea util a alguien, y si se os curre algo mejor, compartirlo :D

Cuidado con ListItemCollection.Insert()

2005-12-15T12:29:00.000+01:00

Despues de un par de meses sin escribir nada vuelvo con otra de mis anecdotas.

En todos los controles que heredan de ListControl (DropDownList, ListBox...) , tenemos dos formas de añadir items de forma manual, que son:
- Items.Add(ListItem item);
- Items.Insert(int index, ListItem item);

Pues lo gracioso es que si intentamos añadir un ListItem que es null con el metodo Add(), nos lanza una excepcion, pero si usamos el metodo Insert() la excepcion no se lanza al añadir el ListItem nulo, si no que se lanza al renderizar la pagina.

Ademas, si nos fijamos en la Propiedad SelectedIndex (que si no hay ningun item seleccionado deberia valer -1), vemos que es null, asi que si intentamos acceder a ella tambien lanza una excepcion.

¿Por que se comportan de distinta manera estos dos metodos? ¿Deberia lanzar una excepcion el Insert() igual que lo hace el Add()?

La verdad es que no deberiamos de insertar nunca un ListItem que sea null, pero visto lo visto no viene mal algo de defensive programing:
- Si el ListItem nos lo devuelve un Metodo, antes de insertarlo chequear si es null.
- Si lo cogemos de Session con safetly cast (Session["myItem"] as ListItem) chequear si es null.
- Si lo hacemos a proposito aseguraros de hacer check in con el usuario del compañero que peor te caiga :D

La verdad es que no es un fallo muy dificil de detectar y si es muy raro que se produzca, pero como no a mi me ha pasado, y por eso escribo este post.

Espero que le sirva a alguien.

Restringir caracteres de un TextBox en cliente

2005-10-20T11:10:00.000+02:00

Muchas veces queremos limitar la entrada de caracteres de un TextBox para permitir solo numeros.

Para evitar hacer PostBack, podemos realizar esta validacion en cliente de forma muy sencilla.

Al TextBox le añadimos el atributo "onKeyPress", que llamara a la funcion AllowJustNumbers();

Podemos hacerlo en el .aspx directamente o añadirlo desde el .cs de la siguiente forma.
txtRestringido.Attributes.Add("onKeyPress", "AllowJustNumbers();");

Metemos el siguiente script en el .aspx o en un .js aparte y listo.

function AllowJustNumbers()
{
if (window.event.keyCode <> 57)
{
window.event.keyCode = null;
}
}

Lo unico que hace este script es comprobar si la tecla pulsada esta entre el 0-9, y si no pone la tecla pulsada a null y asi no la metera en el textbox, es como si nunca se hubiera pulsado esa tecla.

P.D. 48 y 57 son los codigos ASCII asociados al 0 y al 9.

Esta tecnica se puede escalar para limitar la entrada de cualquier caractes, solo teneis que coger el ASCII y añadir una nueva condicion al if.

Un saludo,
Dani

Es util la propiedad UserControl.IsPostBack?

2005-10-07T11:11:00.000+02:00

Todos conocemos la propiedad Page.IsPostBack. Gracias a ella hacemos que nuesro codigo sea mas eficiente, pero tambien existe otra propiedad, UserControl.IsPostBack. Esta propiedad nos indica si la carga de un UserControl ha sido provocada por un PostBack de cliente. Esto solo es util si tenemos el UserControl agregado a la pagina directamente, pero ¿que ocurre si queremos agregarlo de forma dinámica?. Pues que esta propiedad no nos sirve.

En el proyecto en el que estoy trabajando tenemos UserControls para mostrar pequeños dialogos, que se cargan cuando el usuario pincha en un boton, o cambia el SelectedItem de un DropDownList...

Dentro de esto UserControls necesitabamos saber si era la primera vez que se cargaban o era un PostBack, pero ni Page.IsPostBack ni UserControl.IsPostBack nos servian, ya que estas dos siempre eran true aunque fuera la primera vez que se cargaba el control, porque esta carga era provocada por un PostBack del cliente.

La solucion.

Despues de pensar en varias soluciones al final dimos con la que creo que es la mas correcta.

Todos nuestros UserControl heredan de uno que extendimos nosotros del
System.Web.UI.UserControl, pongamos por ejemplo UserControlBase. En este UserControlBase agregamos una propiedad de la siguiente forma.

protected bool IsUserControlPostBack
{
get
{
return this.ViewState["IsUserControlPostBack"] != null;
}
}

Luego haremos lo siguiente.

protected override void OnLoad(System.EventArgs e)
{
base.OnLoad (e);

if (!IsUserControlPostBack)
{
this.ViewState.Add("IsUserControlPostBack", true);
}
}

Con esto conseguiremos que la primera vez que se ejecute nuestro Page_Load del user control, esta propiedad valga "false", y las posteriores veces valdra "true". El motivo de hacer primero el base.OnLoad (e); es porque asi disparamos la carga del UserControl antes de agregar al ViewState la propiedad, y asi conseguimos este efecto.

La ventaja de usarlo asi es que al cerrar el UserControl automaticamente se elimina del ViewState, asi que podemos tener tantos UserControl como queramos y que todos hereden del UserControlBase sin que entren en conflicto. Otras soluciones como usar la Session tienen el peligro de que gestionemos mal las variables de Session y por despiste veamos alterado el comportamiento.

Espero que os sea util.

Grupo de usuarios de .NET en Madrid

2005-10-07T10:41:00.000+02:00

Recientemente se ha creado un grupo de usuarios de .NET en Madrid. Podeis daros de alta en la pagina www.madriddotnet.net. Os aseguro que merece la pena pertenecer a este grupo.

Agradecer a Miguel Jiménez por haber tenido esta idea y no dejarla en el olvido, si no que ha sido capaz de sacarla a luz, y seguro que llegara a buen puerto.

Os pongo una breve explicacion sacada de la pagina para que os hagais una idea.

Madrid .NET User Group es un grupo independiente de usuarios de .NET y tecnologías adyacentes creado por desarrolladores para desarrolladores. Es un proyecto que pretende comunicar a los desarrolladores de Madrid, realizar eventos técnicos y de socialización para promover a los desarrolladores de nuestra comunidad.

Pertenecer a MAD.NUG es completamente gratuito; y una vez formes parte del grupo puedes participar en todos los eventos, en la organización de nuevos eventos, proponer temas e incluso prepararlos y exponerlos tu mismo. La base de un grupo de usuarios es la de compartir el conocimiento entre sus miembros y por esto es necesaria tu colaboración.
Este proyecto ha sido fruto de varios meses de esfuerzo e incubación, con el soporte de Ilitia Technologies, Microsoft Ibérica y Clearscreen.

Si te gusta .NET y vives en Madrid no puedes dejar de apuntarte.

A DropDownList cannot have multiple items selected.

2005-09-13T09:51:00.000+02:00

Bueno, como esto me trajo de cabeza una temporadita, he decidido escribir un poco al respecto.

Existen unas cuantas clases que heredan de System.Web.UI.WebControls.ListControl, como por ejemplo el DropDownList y el ListBox. Las dos contienen ListItems, pero el ListBox puede tener mas de uno seleccionado, mientras que el DropDownList no.

El problema trabajando con los DropDownList viene cuando modificamos la propidad Selected de los ListItem directamente, para cambiar el item seleccionado. Usando esta tecnica podemos llegar a obtener el mensaje del titulo con bastante frecuencia. Se pueden hacer muchas chapuzas para arreglarlo, como recorrerse la coleccion de ListItems e ir poniendo a todos la propiedad Selected a false antes de poner el que de verdad nos interesa a true, pero aun asi puede seguir fallando. El motivo es que el SelectedIndex no se refresca bien y si no coincide el SelectedIndex con el index del ListItem que tiene Selected a true, tambien nos fallara.

La solucion, trabajar siempre con el SelectedIndex. Una vez que tenemos el ListItem que queremos seleccionar (hay muchas formas de conseguirlo, como por ejemplo con los metodos
FindByText() y FindByValue()...), sacamos el index de este con DropDownList.Items.IndexOf(ListItem) y asignamos este valor a la propiedad SelectedIndex. Os aseguro que de esta forma nunca fallara.

Espero que os sirva, yo lei muchos post en internet pero la mayoria eran chapuzillas, parches, pero no me convencio ninguno :D

My first blog... Comenzando

2005-07-28T12:22:00.000+02:00

Hola a todos.

No tenia muy claro si crear el blog en ingles o en español... pero al final me he decidido por hacerlo en español. Creo que hay muchos y muy buenos blogs en ingles, y que todo lo que tiene que ver con la informatica siempre es mejor si esta en ingles (algunas traducciones.... buff), pero bueno, por que no empezar a hacer cosas en español?!

Este es mi primer blog asi que espero que no se me vaya de las manos y poder actualizarlo con contenidos utiles para toda la gente que desarrolle en .NET.

Espero empezar pronto a escribir alguna cosilla o poner algun enlace o noticia interesante.

Un saludo,
Dani