Variable not found en Geeks.ms

La solución propuesta consistía en introducir en la vista código de script para desplazar el foco hasta el control indicado mediante una llamada al helper Html.SetFocusTo(), que implementábamos en el mismo post, aunque hay otras formas para conseguirlo.

Unos días después, un amigo de Variable not found preguntaba en un comentario si no había una forma de conseguir lo mismo utilizando una sintaxis más declarativa, al estilo de la especificación de metadatos o validadores basados en atributos o data annotations.

En primer lugar he de decir que no creo que sea muy conveniente hacerlo, puesto en casi todos los escenarios posicionar el foco en un elemento es pura presentación, no suele haber decisiones de negocio tras ello, y por tanto no es algo que debamos sacar de la Vista. Pero bueno, independientemente de eso, vamos a ver cómo podríamos conseguirlo.

Una forma relativamente sencilla de hacerlo sería utilizando atributos de metadatos personalizados de forma muy similar al ejemplo que vimos también en un post anterior.

Lo primero que necesitamos es definir un atributo que implemente IMetadataAware, lo que indica que incluye información sobre metadatos, y aprovechar el método OnMetadataCreated() para introducir en la colección de metadatos adicionales una señal que permita más adelante detectar la propiedad a “enfocar”:

public class FocusedAttribute : Attribute, IMetadataAware
{
    public const string MetadataKey = "Focused";
    public void OnMetadataCreated(ModelMetadata metadata)
    {
        metadata.AdditionalValues[MetadataKey] = true;
    }
}

De esta forma, para activar el foco inicialmente sobre el editor de una propiedad concreta, simplemente deberíamos marcarla con el atributo [Focused], como se muestra en el código siguiente:

public class Friend
{
    [Focused]
    public string Name { get; set; }
 
    public string Email { get; set; }
    public string Phone { get; set; }
    public string Fax { get; set; }
 
}

Una vez finalizados los preparativos, tenemos que ver cómo implementarlo en la vista. Lo más sencillo en este caso sería crear el helper Html.Autofocus(), que será encargado de localizar la propiedad con el atributo [Focused] y generar sobre la vista el script que mueva el foco a la misma:

public static class HtmlExtensions
{
    public static MvcHtmlString Autofocus(this HtmlHelper html)
    {
        var template = html.ViewData.TemplateInfo;
        var focusedProperty = 
             (from property in html.ViewData.ModelMetadata.Properties
              where property.AdditionalValues.Any(
                     a => a.Key == FocusedAttribute.MetadataKey && (bool) a.Value)
              select template.GetFullHtmlFieldId(property.PropertyName)
             ).FirstOrDefault();
        if (focusedProperty != null)
        {
            return createAutofocusScript(focusedProperty);
        }
 
        return null;
    }
 
    private static MvcHtmlString createAutofocusScript(string focusedProperty)
    {
        string script = "<script type='text/javascript'>" +
                        "$(function() { $('#" + focusedProperty + "').focus(); });" +
                        "</script>";
        return MvcHtmlString.Create(script);
    }
}

Por último, basta con introducir en la vista la siguiente llamada. O mejor aún, si queremos que esta funcionalidad esté activa en todas las vistas, podemos añadirla al final del Layout que estemos empleando para ellas:

@Html.Autofocus()

Hay que tener en cuenta que nada impide que el atributo Focused sea empleado en más de una propiedad, en cuyo caso el foco se establecerá en la primera ocurrencia localizada. Esto se podría evitar llevando el atributo a nivel de clase e indicando como parámetro el valor de la propiedad (algo así como [DefaultProperty("Name")] sobre la propia entidad). En el proyecto de demostración podréis encontrar también esta implementación.

Descargar proyecto de demostración (VS2010+MVC 3) desde Skydrive.

Publicado en Variable not found.

Y uno de estos casos es un detallito muy simple pero útil: establecer el foco de edición en un control concreto al cargar una página. En Webforms era suficiente con asignar al atributo defaultFocus del tag <form> el nombre del control que nos interesara, y ya lo teníamos solucionado; ASP.NET MVC no trae ninguna solución “de serie” para conseguirlo, aunque, como veremos en este post, no es mucho más complicado que la alternativa Webforms una vez hemos preparado la infraestructura necesaria.

En líneas generales, la solución consiste en utilizar un pequeño script que, una vez cargada la página, mueva el foco hacia el control que nos interese. Por ejemplo, si quisiéramos que el campo con identificador “Nombre” obtenga el foco automáticamente, podríamos utilizar jQuery de la siguiente forma:

<script type="text/javascript">
    $(function () {
        $("#Nombre").focus();
    });
</script>

Aunque eficaz, es una solución demasiado trabajosa e introduce una dependencia en el código, difícilmente manejable, hacia el nombre del control. Si quisiéramos introducir este código en múltiples puntos de nuestra aplicación tendríamos que copiar y pegar en cada vista, y sustituir el id del control apropiado en cada caso, lo cual es bastante incómodo.

¿No podríamos mejorar esto un poco?

El helper SetFocusTo()

Una posible solución, realmente rápida de implementar, sería crear un helper personalizado, al que llamaremos SetFocusTo(), que genere el código por nosotros partiendo únicamente de la información de la propiedad a editar.

Y para evitar la dependencia hacia el nombre de la propiedad y hacerlo más flexible, incluso podríamos crear la versión fuertemente tipada del mismo, de forma que podamos utilizarlo de cualquiera de las siguientes formas:

// Usando el nombre de la propiedad:
@Html.SetFocusTo("Nombre")

// Usando la versión fuertemente tipada:
@Html.SetFocusTo(model=>model.Nombre)

El código del helper es el siguiente:

public static class HtmlHelpers
{
    public static MvcHtmlString SetFocusTo<TModel, TProperty>(
                    this HtmlHelper<TModel> html,
                    Expression<Func<TModel, TProperty>> expression)
    {
        var prop = ExpressionHelper.GetExpressionText(expression);
        return html.setFocusTo(prop);
    }

    public static MvcHtmlString SetFocusTo(this HtmlHelper html, 
                                           string propertyName)
    {
        var prop = ExpressionHelper.GetExpressionText(propertyName);
        return html.setFocusTo(prop);
    }

    private static MvcHtmlString setFocusTo(this HtmlHelper html, 
                                            string property)
    {
        string id = html.ViewData.TemplateInfo.GetFullHtmlFieldId(property);
        var script = "<script type='text/javascript'>" +
                        "$(function() {" +
                            "$('#" + id + "').focus();" +
                        "});" +
                        "</script>";
        return MvcHtmlString.Create(script);
    }

}

Recordad que para que estos helpers estén visible en las vistas y podáis usarlos normalmente, debéis incluir el espacio de nombres en el que están definidos bien sea añadiendo una directiva @using en la vista, o bien en la sección <namespaces> del archivo web.config que encontraréis en la carpeta /Views (o en la del área correspondiente).

¡Y eso es todo! De esta forma ya volvemos a disponer de la posibilidad de establecer el foco por defecto sobre un control de forma muy rápida, compacta, y cómoda de utilizar.

Publicación original (14-dic-2011): http://www.variablenotfound.com/2011/12/aspnet-mvc-establecer-el-foco-en-un.html

Sin embargo, los atributos en el propio código de la clase no son la única vía para especificar metadatos en el framework. En este post veremos cómo extender el framework para crear nuevas vías para especificar esta información.

Sea cual sea su origen, los metadatos siempre se representan como objetos del tipo ModelMetadata, cuya estructura podéis ver a la derecha. Los providers deben incluir la lógica para obtener los metadatos desde donde corresponda, pero siempre retornarán objetos ModelMetadata, en los que, entre otra información, podemos encontrar los siguientes datos:

¿Y cómo determina el framework MVC qué proveedor de metadatos utilizar?

En primer lugar, intenta utilizar el dependency resolver para obtener una instancia de un tipo que implemente ModelMetadataProvider , que es la clase base para todos los proveedores. Este punto de extensión permite definir un proveedor personalizado muy fácilmente, y sobre todo si utilizamos contenedores IoC.

Si no ha sido posible obtener un proveedor desde el dependency resolver, el framework utilizará el establecido en la propiedad ModelMetadataProviders.Current. Por defecto, esa propiedad contiene una un objeto de la clase DataAnnotationsModelMetadataProvider, pero podemos sustituirlo por cualquier otro descendiente de ModelMetadataProvider .

Por tanto, para crear un proveedor personalizado de metadatos, basta con:

Como sabéis, al mostrar en una vista las etiquetas (labels) asociadas a una propiedad del Modelo, el texto que aparece es obtenido desde los metadatos de la entidad, desde el atributo Display o DisplayName (en ese orden); en caso de no existir, se asume como descripción el nombre de la propiedad.

Pues bien, nuestro objetivo es conseguir generar de forma automática estas las descripciones (DisplayName) de cada campo partiendo del nombre de la propiedad, y teniendo en cuenta el “camel casing”, de forma que podremos ahorrarnos el teclear esta descripción en muchos casos. Por ejemplo, a una propiedad que se llame FullName se le asociará automáticamente la descripción “Full Name”, o EmailAddress se describirá como “Email Address”. De esta forma la entidad anterior podremos simplificarla un poco:

Para ello, dado que queremos conservar el comportamiento del proveedor por defecto DataAnnotationsModelMetadataProvider, lo extenderemos y añadiremos la lógica deseada a su método CreateMetadata(), que es el invocado para obtener los metadatos de la entidad y cada una de las propiedades:

Cuando el framework intenta obtener el proveedor de metadatos actual, antes de nada intenta localizarlo utilizando el dependency resolver. Si estamos utilizando un contenedor IoC como Unity o StructureMap, podemos utilizarlos para gestionar esta dependencia, asociando la clase abstracta ModelMetadataProvider al tipo concreto DisplayNameModelMetadataProvider.

Por ejemplo, en el caso de Unity, lo más sencillo es instalar el paquete Unity.MVC3 desde Nuget, y ya simplemente tendríamos que incluir la siguiente línea en el registro de tipos (en el archivo bootstrapper.cs):

En definitiva, en este post hemos visto que en ASP.NET MVC los metadatos no proceden de una ubicación fija, sino que son obtenidos a través de un proveedor configurable. Esto nos permite modificar el comportamiento por defecto del framework y adaptarlo a nuestras necesidades, generarlos de forma dinámica, como en el ejemplo que hemos visto, u obtenerlo desde algún almacén de persistencia (como podría ser un archivo de configuración o una bases de datos), y siempre de forma muy sencilla aprovechando la magnífica extensibilidad del marco de trabajo 🙂

<script type="text/javascript">
    $(function () {
        var settings = $.data($('form')[0], 'validator').settings;
        settings.showErrors = function (errorMap, errorList) {
            // Aquí el código personalizado:
            [...]

            // Y si nos interesa, finalmente podemos
            // ejecutar el comportamiento por defecto

            this.defaultShowErrors();
        };
    });
</script>

(Por simplificar, estamos asumiendo que en el formulario hay un único tag <form>, que es el que capturamos con el selector).

La función showErrors() recibe dos parámetros. El primero es un “mapa” donde asociamos a cada clave (nombre del campo) el mensaje de error que tenga asociado. Así, por ejemplo, el valor de errorMap.Nombre será nulo si el campo “Nombre” del formulario no tiene ningún error (ha validado correctamente), o el texto del error en caso contrario.

En el segundo parámetro de la función encontraremos un array con los errores a mostrar. En cada elemento tendremos disponible la propiedad element, desde la que podemos acceder al control que ha generado el error, y message, donde podemos consultar o establecer la descripción del mismo.

Es importante tener en cuenta que la función showErrors() es invocada con mucha frecuencia durante el proceso de edición (pérdida de foco, obtención de foco, pulsación de teclas…), por lo que desde el punto de vista de la usabilidad no tiene demasiado sentido introducir en ella procesos bloqueantes (como puede ser un alert()) o demasiado largos en el tiempo, para evitar que se solapen.

Por ejemplo, en el siguiente código utilizamos el efecto “highlight” de jQuery UI para resaltar con un rápido destello el elemento en el que se ha detectado un error:

    settings.showErrors = function (errorMap, errorList) {
        for (var i = 0; i < errorList.length; i++) {
            var error = errorList[i];
            // error.element es el elemento que ha provocado el error
            $(error.element).effect("highlight", { times: 1 }, 100);
        }
        this.defaultShowErrors();
    };

En fin, algo no demasiado útil ;-P, pero interesante en cualquier caso para profundizar un poco en los misterios e interioridades de jQuery validate.

Publicación original (22/11/2011): http://www.variablenotfound.com/2011/11/aspnet-mvc-introducir-logica.html
Tip: ¿todavía no conoces la selección de enlaces interesantes de Variable not found?

Este libro, escrito en el año 1987 por Geoffrey James, recoge, en un humorístico tono de misticismo oriental, distintas historias y parábolas con geniales mensajes de fondo sobre calidad en la programación, gestión de proyectos y otros temas que siguen siendo válidos veinticinco años después.

Como probablemente habrá más lectores que no lo conozcan, me ha parecido interesante reproducirlo aquí traducido en su totalidad, por supuesto contando previamente con el permiso expreso del Sr. James.

¡Que aproveche!

En este post vamos a ver un nuevo ejemplo de cómo utilizar el mismo mecanismo de proveedores, pero esta vez para conseguir de forma muy sencilla simplificar el código de clases del modelo en las que todas sus propiedades sean por defecto obligatorias, salvo aquellas en las que indiquemos expresamente lo contrario.

1. Empezando por el final…

Lo que pretendemos hacer es crear dos nuevos atributos, AllRequired y NotRequired. El primero, aplicado a una clase indicará la obligatoriedad de todas sus propiedades, mientras que el segundo, aplicado a una propiedad, indicará que ésta es opcional.

Observad en la siguiente tabla el efecto que podríamos conseguir sobre el código:

public class Friend
{
    [Required] 
    public string Name { get; set; }
    [Required]
    public string Surname { get; set; }
    [Required]
    public string Nickname { get; set; }
    [Required]
    public string Address { get; set; }
    [Required]
    public string City { get; set; }
    [Required]
    public string Country { get; set; }
    public string Phone { get; set; }
    [Required]
    public string MobilePhone { get; set; }
    [Required]
    public string Email { get; set; }
}

[AllRequired]
public class Friend
{
    public string Name { get; set; }
    public string Surname { get; set; }
    public string Nickname { get; set; }
    public string Address { get; set; }
    public string City { get; set; }
    public string Country { get; set; }
    [NotRequired]
    public string Phone { get; set; }
    public string MobilePhone { get; set; }
    public string Email { get; set; }
}

2. Model validator providers

Cuando el framework necesita obtener los validadores asociados a una clase y sus propiedades, no lo hace de forma directa sino a través de unos componentes llamados model validator providers. Éstos son los encargados de acceder a las distintas fuentes en las que puede existir información sobre las reglas de validación para cada clase.

Así, existe “de serie” un model validator provider específico para obtener los validadores partiendo de las anotaciones realizadas sobre la clase (DataAnnotationsModelValidatorProvider ), que es el método utilizado normalmente; existe otro para obtener las implementaciones del interfaz IDataErrorInfo (DataErrorInfoModelValidatorProvider), y otro que se encarga de validaciones implícitas del tipo (ClientDataTypeModelValidatorProvider).

Todos ellos se encuentran registrados en la colección pública ModelValidatorProviders.Providers, de forma que cuando el framework necesita obtener los validadores asociados a una entidad, lo que hace es recorrer dicha colección e ir llamando uno por uno a los proveedores solicitándoles información de validación para cada una sus propiedades.

Este proceso se realiza, cuando se tiene activa la validación en cliente, para obtener las reglas y parámetros que hay que llevar a la vista, o también durante el binding, para obtener los validadores, ejecutarlos y actualizar el ModelState con el resultado.

Pero sin duda lo mejor que tiene este sistema es su facilidad de extensión. Podemos añadir con suma facilidad nuevos proveedores a la colección ModelValidatorProviders a la que hacía referencia anteriormente, de forma que podemos introducir nuestra propia lógica de generación de validadores en el flujo de ejecución de peticiones del framework.

Y es lo que vamos a hacer a continuación: implementaremos nuestro proveedor para generar automáticamente validaciones de tipo Required para todas las propiedades de las clases decoradas con el atributo [AllRequired], exceptuando aquellas propiedades en las que se haya indicado lo contrario con [NotRequired].

3. Los atributos AllRequired y NotRequired

Antes que nada, necesitamos definir estos dos atributos para poder continuar. El código es tan simple como el que veis a continuación:

[AttributeUsage(AttributeTargets.Class)]
public class AllRequiredAttribute : Attribute
{
        
}
 
[AttributeUsage(AttributeTargets.Property)]
public class NotRequiredAttribute: Attribute
{
        
}

Observad que no es necesario que éstos hereden de ValidationAttribute; de hecho, no estamos creando anotaciones personalizadas, sólo atributos que nos permitan “marcar” en clases y propiedades para generar más adelante, desde el proveedor, las anotaciones necesarias.

Los [AttributeUsage] lo único que hacen es restringir su uso de forma que [AllRequired] se pueda utilizar únicamente sobre clases, mientras que [NotRequired] sea utilizable exclusivamente en propiedades, más que nada para que se comprueben en compilación estos aspectos.

4. Implementando nuestro model validator provider

La implementación de un model validator provider es bastante sencilla. Lo único que tenemos que hacer es heredar de ModelValidatorProvider e implementar su método GetValidators(), que es el que invocará el framework para obtener los validadores de cada una de las propiedades de la clase.

En nuestro caso, simplemente comprobaremos que la clase esté marcada como [AllRequired] , retornando un validador de tipo Required para todas aquellas propiedades que no se hayan marcado con [NotRequired]. Casi mejor lo vemos sobre el código:

public class AllRequiredValidatorProvider : ModelValidatorProvider
{
  public override IEnumerable<ModelValidator> GetValidators(
      ModelMetadata metadata, ControllerContext context)
  {
      var allRequiredAttribute =
              TypeDescriptor.GetAttributes(metadata.ContainerType)
              .OfType<AllRequiredAttribute>().FirstOrDefault();
 
      if (allRequiredAttribute != null)
      {
        var property = metadata.ContainerType.GetProperty(metadata.PropertyName);
        var isOptional = property.GetCustomAttributes(typeof(NotRequiredAttribute), false).Any();
        if (!isOptional)
        {
          var requiredValidator = new RequiredAttribute() { ErrorMessage = "Requerido" };
          yield return new RequiredAttributeAdapter(metadata, context, requiredValidator);
        }
      }
  }
}

Observad la firma del método: retorna una colección de objetos que heredan de ModelValidator, que son adaptadores de los distintos mecanismos de validación que podemos emplear en MVC. En la práctica permiten homogeneizar la diversidad de validadores vistas al framework, y a veces incluyen cierta lógica, como la generación de las reglas de validación en cliente.

El framework incluye ya adaptadores para cada una de las anotaciones habituales (RequiredAttributeAdapter, StringLengthAdapter, RegularExpressionAttributeAdapter …), que podemos instanciar directamente para ir construyendo la colección que retorna el método GetValidators(). En el código anterior, fijaos que en la última línea retornamos, usando yield, un nuevo adaptador de tipo RequiredAttributeAdapter, a cuyo constructor suministramos una instancia del atributo Required convenientemente inicializada.

Un último detalle: tened en cuenta que por simplificar el ejemplo no he prestado atención a aspectos como el rendimiento, que podría mejorarse introduciendo una caché, o la personalización de los mensajes de error, que sería fácilmente implementable permitiendo parámetros en el atributo [AllRequired] y suministrándolos más adelante en la instanciación de los RequiredAttribute que retornamos desde el proveedor, como hacemos ahora con la cadena de texto constante “Requerido”.

5. Registro del proveedor

Por último, ya sólo queda indicar al framework que debe utilizar nuestro proveedor para obtener los validadores, por lo que lo añadimos en el global.asax a la colección de providers:

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();
 
    ModelValidatorProviders.Providers.Add(new AllRequiredValidatorProvider());
 
    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);
}

¡Y ahí lo tenemos! A partir de este momento, ya podemos hacer uso de estos nuevos atributos en nuestras clases del modelo o view models, como se muestra a continuación:

[AllRequired]
public class Friend
{
    public string Name { get; set; }
    public string Surname { get; set; }
    public string Nickname { get; set; }
    public string Address { get; set; }
    public string City { get; set; }
    public string Country { get; set; }
    [NotRequired]
    public string Phone { get; set; }
    public string MobilePhone { get; set; }
    public string Email { get; set; }
}

En tiempo de ejecución tendremos, por supuesto, validación tanto en cliente como en servidor; de hecho, el resultado será idéntico al conseguido si hubiéramos decorado cada una de las propiedades anteriores con él atributo Required, puesto que en realidad estamos inyectándolo en todas las propiedades de forma automática, exceptuando en aquellas donde se ha indicado expresamente lo contrario.

Podéis descargar el proyecto de prueba desde Skydrive (VS2010+MVC3).

Publicación original (8-nov-2011): http://www.variablenotfound.com/2011/11/validator-providers-en-aspnet-mvc.html
Tip: ¿todavía no conoces la selección de enlaces interesantes de Variable not found?

< disclaimer>

Todo lo que voy a contar a continuación está probado con la versión previa para desarrolladores de MVC. El ensamblado Microsoft.Web.Optimization es la versión 0.1, y de él puede cambiar hasta el nombre 😉

< /disclaimer>

Para empezar, el paquete Microsoft.Web.Optimization se incluye instalado de serie en MVC 4 (a día de hoy, hay que decir). En cambio, en ASP.NET MVC 3 o Webforms debemos descargarlo utilizando Nuget:

PM> Install-Package Microsoft.Web.Optimization
Successfully installed 'Microsoft.Web.Optimization 0.1'.
Successfully added 'Microsoft.Web.Optimization 0.1' to Mvc4Application49.

Una vez instalado, ya casi tenemos el trabajo hecho 😉

La forma rápida

Si lo que queremos es probar rápidamente el sistema de empaquetado, basta con añadir el siguiente código en la inicialización de nuestra aplicación:

   protected void Application_Start()
   {
       ... 
       BundleTable.Bundles.EnableDefaultBundles();
       ...

¡Y esto es todo! A partir de este momento, podemos acceder a las URL:

• /scripts/js, que nos retornará un único archivo script conteniendo todos los scripts disponibles en la carpeta /scripts del proyecto (sin incluir subdirectorios), minimizados y compactados.
• /content/css, que de la misma forma, retornará un único archivo .css conteniendo la suma compactada de todos los css que el sistema encuentre en la carpeta /content.

Vale, he simplificado un poco para que pudierais comprender rápidamente el ejemplo, pero en realidad es aún más potente:

• Cualquier petición del estilo “{path}/js” hará que el sistema retorne en un único archivo compactado todos los scripts disponibles en la carpeta {path}.
• De la misma forma, todas las peticiones a “{path}/css” retornará un único archivo .css con la suma compactada de todas las hojas de estilo presentes en la carpeta {path}.
• Se eliminan las versiones de documentación (*-vsdoc.js, *.debug.js…), es decir, serán ignoradas todas ellas a la hora de generar el archivo compactado único.
• Se tiene en cuenta la ordenación, sobre todo a la hora de anexar los scripts en un único archivo. De esta forma, scripts como jQuery se carguen antes que sus plugins, y otros habituales en el mundo CSS como reset.css o normalize.css sean cargados al final del bundle de estilos.

Si queremos hacer utilizar estos archivos minimizados en nuestro sitio web, simplemente tendremos que acudir al layout (o master) y modificar los enlaces hacia estas direcciones. Observad que tendréis que poner un enlace por cada carpeta:

   <link href="/Content/css" rel="stylesheet" type="text/css" />
   <script src="/Scripts/js" type="text/javascript"></script>

Ojo, muy Importante: para que todo funcione bien los scripts deben ser sintácticamente correctos, de lo contrario podemos encontrarnos con que la versión compactada nos dé fallos en tiempo de ejecución. Esto es así porque el proceso de compactación no sólo elimina espacios sobrantes, sino que acorta los nombres de variables y funciones privadas.

De hecho, a día de hoy este sistema no funciona bien con las bibliotecas que se encuentran por defecto en la carpeta /scripts de los proyectos MVC 3, es necesario actualizarlos (usando Nuget son sólo unos segundos). Con los scripts incluidos en MVC 4 no hay problema.

También los .css deben ser correctos, aunque en caso contrario lo único que ocurrirá es que se retornará un único archivo sin compactar.

¡Quiero más control!

El sistema de bundling es realmente potente y flexible. En el ejemplo anterior se trataba de poner en marcha este sistema de forma rápida, pero se puede conseguir un control mucho más exhaustivo sobre lo que se compacta y lo que no, y sobre la forma de acceder a estos recursos.

La siguiente porción de código muestra cómo podríamos inicializar la tabla de bundles de forma más detallada:

   Bundle cssBundle = new Bundle("~/estilo.css", typeof(CssMinify));
   cssBundle.AddDirectory("/content", "*.css", searchSubdirectories: true);
   BundleTable.Bundles.Add(cssBundle);

   Bundle jsBundle = new Bundle("~/scripts.js", typeof (JsMinify));
   jsBundle.AddFile("~/scripts/jquery-1.6.4.js");
   jsBundle.AddFile("~/scripts/modernizr-2.0.6.js");
   jsBundle.AddDirectory("~/scripts/site", "*.js", searchSubdirectories: false);
   BundleTable.Bundles.Add(jsBundle);

Como podemos observar, en primer lugar se crea un bundle de tipo CSS, en el que se añaden todos los archivos con el patrón *.css que se encuentren en la carpeta /content y todos sus subdirectorios. Este paquete compactado sería accesible a través de la URL “/estilo.css”.

En el segundo bloque creamos un bundle en la URL “/script.js” al que añadimos algunos archivos de forma manual, y todos los .js que encontremos en la carpeta /scripts/site, sin incluir subdirectorios.

¿Fácil, verdad?

En conclusión, aunque todavía tendrá que cambiar, en este momento ya podemos ver una herramienta muy potente y sencilla de utilizar, que seguro entrará a formar parte de nuestros desarrollos en breve. Ya el colmo sería que los contenidos se comprimieran en gzip, pero por la pinta que tienen los componentes probablemente sea una funcionalidad a la que podamos aspirar en breve 🙂

Publicación original (18-oct-2011): http://www.variablenotfound.com/2011/10/compactacion-y-minimizacion-de.html