Tag Archive for web dev

.NET y Configuraciones – Parte 8

La última vez que conversamos acerca de configuraciones sacamos a relucir lo sencillo que es agregar soporte para funciones de validación callback, y antes de eso comentábamos lo sencillo que era agregar soporte para validación de forma declarativa usando los atributos de validación incluídos en la Configuration Framework de la .Net Framework.

Hoy seguiremos caminando en el soporte de validación customizada de secciones y elementos de validación, pero esta vez creando nuestros propios atributos de validación customizados.

Atributos de Validación

Un atributo de validación nos permite validar los elementos o secciones de nuestra configuración de .Net, simplemente tenemos que adornar ese elemento con el atributo en cuestión. La .Net framework nos incluye algunos atributos ya dentro de la caja, pero podemos agregar los nuestros propios de forma sencilla.

Realmente un atributo de validación costa de dos clases: La clase que marca el atributo (un atributo marcador) y la clase que ejecuta la acción de validar (el validador). Como podremos notar en este lado de la framework se utilizan los atributos de una manera muy particular (y que en lo personal me gusta) de mezclar el atributo como marcador pero no como ejecutor.

Usemos un simple ejemplo, imaginemos que necesitamos validar la entrada de correos electrónicos, como todos sabemos, podemos seguir un par de reglas expuestas en una serie de RFC’s acerca de direcciones de email. Bueno, comencemos por la clase que hace realmente la validación, esta debe heredar de la clase ConfigurationValidatorBase y luego el override de los métodos CanValidate (que nos dice si podemos o no validar el tipo en cuestión) y Validate (quien realmente realiza la validación).

using System;
using System.Configuration;
using System.Text.RegularExpressions;

namespace Cprieto.Samples {
    public class EmailValidator : ConfigurationValidatorBase {
        private const string Word = "[^x00-x1F^(^)^<^>^@^,^;^:^\^"^.^[^]^s]";
        private const string IpEntry = "[[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}]";
        private static readonly string Domain = string.Format("({0}+(.{0}+)*", Word);

        private static readonly Regex EmailRegex =
            new Regex(string.Format("^{0}+(.+)*@{1}|{2})$", Word, Domain, IpEntry), RegexOptions.Compiled);

        public override bool CanValidate(Type type) {
            return type == typeof (string);
        }

        public override void Validate(object value) {
            var item = (string) value;
            if (!string.IsNullOrEmpty(item) && !EmailRegex.IsMatch(item))
                throw new ArgumentException("value is not a valid email");
        }
    }
}

Bien, ahora simplemente creamos el atributo marcador, este debe heredar de ConfigurationValidatorAttribute y la parte importante de este es el override de la propiedad ValidatorInstance que retorna una nueva instancia de nuestra clase validadora.

using System.Configuration;

namespace Cprieto.Samples {
    public class EmailValidatorAttribute : ConfigurationValidatorAttribute {
        public override ConfigurationValidatorBase ValidatorInstance {
            get { return new EmailValidator(); }
        }
    }
}

Ahora simplemente lo aplicamos a nuestra sección de configuración:

using System.Configuration;

namespace Cprieto.Samples {
    public class SampleConfigurationSection : ConfigurationSection {
        [CallbackValidator(Type = typeof(PortValidator),
            CallbackMethodName = "Validate")]
        [ConfigurationProperty("port", DefaultValue = 80)]
        public int Port {
            get { return (int) this["port"]; }
        }

        [ConfigurationProperty("host", IsRequired = true)]
        public string Host {
            get { return (string) this["host"]; }
        }

        [EmailValidator]
        [ConfigurationProperty("email")]
        public string Email {
            get { return (string) this["email"]; }
        }
    }
}

Y claro, nunca cae de más un pequeño archivo de validación que debe marcar como inválido

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="sample"
             type="Cprieto.Samples.SampleConfigurationSection, Cprieto.Samples.ValidationCallback"/>
  </configSections>
  <sample port="80" host="localhost" email="invalid@@email" />
</configuration>

Bueno, y ahora me queda pensar que escribo para el siguiente post de la serie :) Hasta la próxima!

.NET y Configuraciones – Parte 6

Bueno, miren que lejos hemos llegado con el asunto de las configuraciones :) pero no se preocupen, aún falta mucho más que aprender sobre nuestros amigos los archivos app/web.config y sobre nuestras configuraciones personalizadas, imagínense un mundo con menos y con configuraciones más claras y con mayor significado para el desarrollador. Hasta el momento hemos explorado secciones, grupos de secciones, elementos, colecciones todas personalizadas, hoy aprenderemos un poco acerca de validadores.

Element Validators

Imagínense que en su sistema de configuración necesitan validar que el número ingresado por el usuario en la configuración se encuentre dentro de un rango, o que el texto ingresado cumpla con una expresión regular o cumpla una longitud mínima o máxima (si, ya se, ambos se pueden lograr con un regex, pero para efectos de ejemplo digamos que son dos diferentes). Muchos quizás nos veremos tentados a obtener el valor de la configuración y posteriormente validarlo, bien, en el caso de elementos de configuración es buena idea abstenerse de hacerlo. La buena noticia es que tenemos a nuestra disposición toda una infraestructura de validación de valores de configuración y esta se lleva a cabo en el momento en que el ConfigurationManager lee los valores.

Los Validators son atributos especiales que acompañan a nuestros elementos de configuración, podemos definir nuestros propios validadores (ese será el tema de un post futuro) pero por defecto la framework nos empaca un par de validadores simples y sencillos:

IntegerValidator Valida un entero dentro de un rango
LongValidator Valida un número dentro de un rango
PositiveTimeSpanValidator Valida un timespan dentro de un rango positivo
RegexStringValidator Valida que una cadena cumple con una expresión regular
StringValidator Valida que una cadena debe cumplir una longitud máxima/mínima
TimeSpanValidator Valida un timespan dentro de un rango

Usar los validadores no puede ser más sencillo, simplemente adornamos nuestras propiedades o elementos con el atributo del validador que nos interesa y la framework de configuración se encarga del resto

using System;
using System.Configuration;

namespace Samples {
    public class SampleConfigurationSection : ConfigurationSection {
        [ConfigurationProperty("port", DefaultValue = 80)]
        [IntegerValidator(MaxValue = 100, MinValue = 20)]
        public int Port {
            get { return (int) this["port"]; }
        }

        [ConfigurationProperty("host", IsRequired = true)]
        public string Host {
            get { return (string) this["host"]; }
        }

        [ConfigurationProperty("timeout")]
        [TimeSpanValidator(MinValueString = "00:00:00",
            MaxValueString = "00:01:00")]
        public TimeSpan Timeout {
            get { return (TimeSpan) this["timeout"]; }
        }
    }
}

Para probar la configuración podemos usar este simple app.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="sample" type="Samples.SampleConfigurationSection, ValidatorSample"/>
  </configSections>
  <sample host="localhost" port="80" timeout="00:00:30" />
</configuration>

Y este pequeño programa de consola puede servirnos como simple prueba

using System;
using System.Configuration;

namespace Samples {
    internal class Program {
        private static void Main(string[] args) {
            var cfg = ConfigurationManager.GetSection("sample")
                as SampleConfigurationSection;
            if (cfg == null)
                return;

            Console.WriteLine("Host: {0}, Port: {1}, Timeout: {2}",
                cfg.Host, cfg.Port, cfg.Timeout);

            Console.ReadLine();
        }
    }
}

Si algún elemento no cumple con lo esperado por el validador el ConfigurationManager tirará una excepción de tipo ConfigurationErrorsException que a su vez en la propiedad Errors contendrá los ConfigurationException en forma de arreglo.

.NET y Configuraciones – Parte 5

Aunque hemos creado colecciones de elementos en las secciones de configuración personalizadas no nos dejemos engañar, hay mucho más acerca de las colecciones de elementos de configuración que simplemente conocer como agregar elementos nuevos.

Tipos de colecciones de configuración

Existe un enumerador especial, ConfigurationElementCollectionType, que nos sirve como indicador de “cómo” debe ser el comportamiento de la colección. Al principio uno piensa “¿cómo así el comportamiento? una colección simplemente es un número finito secuencial de elementos”. Bueno, veamos en que difiere cada tipo:

AddRemoveClearMap El tipo por defecto, los elementos de la colección pueden unirse o fusionarse dentro de una jerarquía de archivos de configuración (por ejemplo, la jerarquía en Web.config). Existen operaciones de Clear, Remove, Add que permiten modificar las propiedades heredadas dentro de la jerarquía
AddRemoveClearMapAlternate Igual que AddRemoveClearMap, con la diferencia en que sus elementos ordenan sus elementos en la definición actual antes que la de la jerarquía. Estando los elementos locales antes que los elementos heredados (en la colección)
BasicMap Los elementos definidos en un nivel son compartidos con los de los niveles hijos, pero los niveles hijos no pueden modificar la colección definida por su padre
BasicMapAlternate Funciona igual al BasicMap, pero los elementos heredados son mostrados después que los elementos locales

Las colecciones de tipo BasicMap no poseen operaciones de add, remove, clear. Los tipos Alternate incluyen los elementos padres después de la definición de elementos locales. Lo más común es mantenerse en colecciones de tipo AddRemoveClearMap y utilizar BasicMap cuando realmente queremos asegurarnos que no se debe modificar la colección.

Definir nodos como elementos

Otra opción poco común pero sencilla de hacer es evitar utilizar la palabra add para agregar el nodo a la colección y en vez de eso utilizar el elemento como nodo de la colección. Esto es realmente sencillo y muchas veces nos puede mejorar la claridad del código de configuración. El secreto es simplemente hacer override de las propiedades de la colección que se encarga de retornar los nombres de los elementos en la colección, ElementName y CollectionType, y opcional a ello indicar el tipo de colección que utilizaremos marcando la colección con una propiedad de un atributo, ConfigurationCollectionAttribute.

using System.Configuration;

namespace Samples {
    [ConfigurationCollection(typeof (ServerConfigurationElement),
        CollectionType = ConfigurationElementCollectionType.BasicMap)]
    public class ServerConfigurationCollection : ConfigurationElementCollection {
        public ServerConfigurationElement this[int index] {
            get { return BaseGet(index) as ServerConfigurationElement; }
            set {
                if (BaseGet(index) != null)
                    BaseRemoveAt(index);
                BaseAdd(index, value);
            }
        }

        public new ServerConfigurationElement this[string name] {
            get { return BaseGet(name) as ServerConfigurationElement; }
        }

        public override ConfigurationElementCollectionType CollectionType {
            get { return ConfigurationElementCollectionType.BasicMap; }
        }

        protected override string ElementName {
            get { return "server"; }
        }

        protected override ConfigurationElement CreateNewElement() {
            return new ServerConfigurationElement();
        }

        protected override object GetElementKey(ConfigurationElement element) {
            var value = element as ServerConfigurationElement;
            return value != null ? value.Name : null;
        }
    }
}

Y nuestro archivo de configuración ahora tendría la siguiente forma

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="sample"
             type="Samples.SampleConfigurationSection, Samples.Cfg.AdvancedCollections"/>
  </configSections>
  <sample default="default">
    <servers>
      <server name="default" host="localhost" />
      <server name="another" port="8080" host="192.168.1.1" />
    </servers>
  </sample>
</configuration>

Algunos quizás encontraran esto ligeramente más fácil de leer que la versión original publicada en la parte 4 de esta serie.

Rayos, sin darnos cuenta llevamos ya cinco artículos sobre configuración personalizada en .Net (no se preocupen, aún faltan muchos más), el tiempo vuela cuando uno se divierte :P , como siempre agradezco sus comentarios, tags, pings, whatever… siempre son bienvenidos….

Y bueno, como dice Porky…

.NET y Configuraciones – Parte 4

Hasta el momento hemos tocado la creación de configuraciones personalizadas, elementos de configuración personalizados y la creación de grupos de secciones de configuración personalizados. Es interesante pero eso simplemente es la punta del iceberg de todo lo que dentro del concepto de configuración que nos permite manejar o mover la .NET Framework, hoy profundizaremos un poco más acerca de agregar nuevas características a nuestra configuración personalizada.

Colecciones y listas

Se que muchos hemos visto secciones de la configuración de ASP.NET y notado el uso de colecciones en él web.config, por ejemplo, el segmento de appSettings:

<appSettings>
    <clear />
    <remove name="port" />
    <add name="port" value="81" />
</appSettings>

Luego acceder a tal segmento de la configuración es "relativamente" sencillo, basta con algo como esto:

int port = int.Parse(ConfigurationManager.AppSettings["port"]);

Como habrán notado esto nos permite tener secciones que se comportan como colecciones de valores, que luego pueden ser accedidas por un indexer usando el nombre (en este caso "port") o el índice (en este caso, 0). Estas colecciones también soportan operaciones básicas (remove, clear, add). Crear colecciones de valores para la configuración no es para nada difícil simplemente hay que heredar de una clase abstracta especial, ConfigurationElementCollection

Comencemos por la unidad mínima, digamos que son elementos para datos de servidores

using System.Configuration;

namespace Samples {
    public class ServerConfigurationElement : ConfigurationElement {
        [ConfigurationProperty("name", IsRequired = true)]
        public string Name {
            get { return (string) this["name"]; }
        }

        [ConfigurationProperty("port", DefaultValue = 80)]
        public int Port {
            get { return (int) this["port"]; }
        }

        [ConfigurationProperty("host", IsRequired = true)]
        public string Host {
            get { return (string) this["host"]; }
        }
    }
}

Hasta el momento nada diferente de lo que conocemos. Ahora agreguemos el soporte para la colección de elementos de configuración tipo ServerConfigurationElement

using System.Configuration;

namespace Samples {
    [ConfigurationCollection(typeof(ServerConfigurationElement))]
    public class ServerConfigurationCollection : ConfigurationElementCollection {
        protected override ConfigurationElement CreateNewElement() {
            return new ServerConfigurationElement();
        }

        protected override object GetElementKey(ConfigurationElement element) {
            var value = element as ServerConfigurationElement;
            return value != null ? value.Name : null;
        }

        public ServerConfigurationElement this[int index] {
            get {
                return BaseGet(index) as ServerConfigurationElement;
            }
            set {
                if (BaseGet(index) != null)
                    BaseRemoveAt(index);
                BaseAdd(index, value);
            }
        }

        public new ServerConfigurationElement this[string name] {
            get {
                return BaseGet(name) as ServerConfigurationElement;
            }
        }
    }
}

Obligatoriamente tenemos que implementar los métodos CreateNewElement (el cual creo su nombre e implementación son suficientemente descriptivos) y el método GetElementKey, este nos retorna el valor que tendrá la key del diccionario de elementos. Observen como implementamos los indexers que luego necesitaremos para acceder a los elementos de la colección. Nótese también que nuestra colección esta adornada con el atributo ConfigurationCollectionAttribute, el cual no es estrictamente necesario.

Bien, nos queda simplemente implementar la sección de configuración general, no muy diferente

using System.Configuration;

namespace Samples {
    public class SampleConfigurationSection : ConfigurationSection {
        [ConfigurationProperty("default", IsRequired = true)]
        public string DefaultServer {
            get { return (string) this["default"]; }
        }

        [ConfigurationProperty("servers", IsRequired = true)]
        public ServerConfigurationCollection Servers {
            get {
                return this["servers"]
                   as ServerConfigurationCollection;
            }
        }
    }
}

Nuestra configuración personalizada lucirá algo así:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section
        name="sample"
        type="Samples.SampleConfigurationSection, Samples.Cfg"/>
  </configSections>
  <sample default="default">
    <servers>
      <clear />
      <add name="default" host="localhost" />
      <add name="another" port="8080" host="192.168.1.1" />
    </servers>
  </sample>
</configuration>

Y en nuestro programa podemos acceder a ella de forma sencilla

using System;
using System.Configuration;

namespace Samples {
    internal class Program {
        private static void Main(string[] args) {
            var cfg = ConfigurationManager.GetSection("sample") as SampleConfigurationSection;
            if (cfg == null) return;

            Console.WriteLine("Default item: {0}", cfg.DefaultServer);

            foreach (ServerConfigurationElement server in cfg.Servers) {
                Console.WriteLine("server: {0}, host: {1}, port: {2}",
                    server.Name, server.Host, server.Port);
            }

            ServerConfigurationElement defaultServer = cfg.Servers[cfg.DefaultServer];

            Console.WriteLine("Default host: {0}", defaultServer.Host);
            Console.ReadLine();
        }
    }
}

Como les advertí desde el principio, nada complicado y sumamente útil. Creo que vale la pena mencionar que cualquier comentario, sugerencia, duda u observación soy todo ojos para leer sus comentarios.

Cómo dijo Terminator, volveré…

.NET y Configuraciones – Parte 3

Ok, hasta el momento ya vimos como crear nuestras propias secciones y valores de configuración, además de darnos una vuelta por las opciones de crear y agregar elementos a nuestras secciones personalizadas. Hoy continuaremos indagando un poco más en el mundo de las configuraciones personalizadas en .NET.

Grupos de Secciones

Imagínense que la configuración de nuestra aplicación es mucho más compleja de lo usual y que además de elementos personalizados necesitamos agregar “subsecciones” de configuración. Dentro de la .Net Framework es algo común en ASP.NET. Crear secciones de configuración no puede ser más fácil, basta con crear las secciones como lo hemos estado haciendo hasta el momento. Tomemos por ejemplo las siguientes dos secciones:

public class SampleSection : ConfigurationSection {
    [ConfigurationProperty("name", IsRequired = true)]
    public string Name {
        get { return (string) base["name"]; }
        set { base["name"] = value; }
    }

    [ConfigurationProperty("port", DefaultValue = 80)]
    public int Port {
        get { return (int) base["port"]; }
        set { base["port"] = value; }
    }
}

public class AnotherSection : ConfigurationSection {
    [ConfigurationProperty("times", IsRequired = true)]
    public int TimesPerDay {
        get { return (int) base["times"]; }
        set { base["times"] = value; }
    }
}

Basta ahora con crear un ConfigurationSectionGroup para obtener ambas secciones dentro de un mismo grupo

public class SampleSectionGroup : ConfigurationSectionGroup {
    [ConfigurationProperty("sample")]
    public SampleSection Sample {
        get { return (SampleSection) Sections["sample"]; }
    }

    [ConfigurationProperty("another")]
    public AnotherSection Another {
        get { return (AnotherSection) Sections["another"]; }
    }
}

Agregarla en el web.config es un poco más laborioso pero continúa siendo sencillo

<configuration>
  <configSections>
    <sectionGroup name="sampleGroup" type="WebApplication2.SampleSectionGroup">
      <section name="sample" type="WebApplication2.SampleSection"/>
      <section name="another" type="WebApplication2.AnotherSection"/>
    </sectionGroup>
  </configSections>
  <sampleGroup>
    <sample name="sample" port="31" />
    <another times="5" />
  </sampleGroup>
</configuration>

Creo que para estas alturas el usarla en el código debe ser algo sencillo y "straighforward"