Una de las principales novedades que trae de serie la versión 2013 de SharePoint es Display Templates. Estos artefactos vienen a substituir al tedioso XSL que se utilizaba en versiones anteriores.

Una de las principales ventajas es que los Displays Templates utilizan un lenguaje más cercano al desarrollo Web y hace posible que mucha más gente lo conozca y pueda utilizarlo de una forma más o menos sencilla. En este post, vamos a realizar una pequeña introducción sobre los Displays Templates y vamos a ver cómo incluirlos dentro de nuestro ciclo de vida.

Los Display Templates…

… son (como bien su nombre indica) plantillas para mostrar la información obtenida del servicio de búsqueda. Este punto hay que dejarlo claro para saber en que escenario poder plantear esta opción o bien plantear otro tipo de desarrollo. El servicio de búsqueda es muy potente, pero sus requisitos también son bastante grandes y quizás en granjas pequeñas o en algunos procesos, se deben de plantear otras posibilidades (tal y como vimos en otros posts).

Ventajas

Poder reutilizar los Templates en otros proyectos
Similar al javascript
Incorporado en muchos WebPart Out of the box

Inconvenientes

Solo aplicables para SharePoint
Un poco más complejo que otros generadores de Plantillas en JavaScript, como pueda ser MustacheJS

Entrando en detalle

Los Displays Templates están formados por dos ficheros:

Un fichero html donde introduciremos los datos relativos a nuestra plantilla: estructura html, asignación de las propiedades administradas para los valores que se van a mostrar…
Un fichero JS. SharePoint utilizará este fichero para realizar el renderizado, una vez nosotros realicemos cualquier modificación en el html y automáticamente se replicará en el fichero JavaScript.

*Ambos ficheros están sincronizados y dependen uno del otro.

Los Display Templates puedes ser de dos tipos: Control Template o Item Template.

Control Template

Ofrece el HTML para estructurar el diseño general de la forma en que desea presentar los resultados de búsqueda. Por ejemplo, la plantilla de control podría proporcionar el código HTML para una partida, principio y final de una lista.

Item Template

Ofrece el HTML que determina cómo se muestra cada elemento en el conjunto de resultados. Por ejemplo, la plantilla de elementos de la pantalla podría proporcionar el código HTML de un elemento de la lista que contiene una imagen, tres líneas de texto que se asignan a diferentes propiedades administradas asociados al mismo. La plantilla de elementos de visualización se hace una vez por cada elemento en el conjunto de resultados. Por lo tanto, si el conjunto de resultados contiene diez artículos, la plantilla de elementos de visualización crea su sección de HTML diez veces.

¿Cómo lo aprovisionamos?

Una vez tenemos implementada la plantilla y tenemos desarrollado el template, tendremos que incluirlo dentro de nuestro proceso de ALM. Microsoft nos proporciona en esta versión el Design Manager para poder llevar todos los artefactos de diseño de un entorno a otro. Ahora bien, desde mi punto de vista, el potencial del Design Manager es bastante menor que poder disponer de aspectos que nos facilitan mucho más la calidad de nuestro software como: la integración continua, el control de código fuente, etc. Pero más allá de todo esto, hay que tratar todos estos artefactos tal y como al resto. De esta forma, todo nuestro desarrollo seguirá el mismo patrón.

Por este motivo, lo que vamos a realizar con los Display Templates es crearnos un módulo que nos despliegue todos nuestros templates en la carpeta indicada. Para ello, crearemos un módulo desde Visual Studio y dentro del elements añadiremos algo similar a lo siguiente:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="DisplayTemplates" Path="DisplayTemplates" Url="_catalogs/masterpage/Display Templates">
    <!-- CONTENIDO -->
    <File Path="PressKit.html" Url="Content Web Parts/PressKit.html" Type="GhostableInLibrary" Level="Draft" ReplaceContent="TRUE" IgnoreIfAlreadyExists="TRUE">
    </File>
      </Module>
</Elements>

Dentro del File, las propiedades que tenemos que definir son:

Type como «GhostableInLibrary«. Sino añadimos esta marca, cuando se despliegue el módulo no se podrá visualizar el fichero.
ReplaceContent, e IgnoreIfExist. Estas propiedades las marcamos a TRUE, para cuando volvamos a desplegar, se vuelvan a actualizar los Templates.
Level=Draft. Aquí hay uno de los kits de porqué fallan el aprovisionamiento. Si marcamos esta propiedad como Publishing, no se genera el fichero JS y, por lo tanto, no funcionan los Templates dentro de nuestros WebParts.

A continuación, una vez desplegamos el módulo, lo que vamos a implementar es una Feature a nivel de Web, cuya función es publicar todos los Display Templates que estén en estado borrador y los publiquen de esta forma. Una vez publiquemos, se generará el fichero JS correspondiente al fichero HTML y todo funcionará a la perfección. Para ello, podemos utilizar un código similar al siguiente:

     public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {

            var site = properties.Feature.Parent as SPSite;
            string[] templateFolderUrls = { "_catalogs/masterpage/Display Templates/Content Web Parts" };
            if (site == null) return;

            var templatesGallery = site.GetCatalog(SPListTemplateType.MasterPageCatalog);
            if (templatesGallery != null)
            {

                foreach (string folderUrl in templateFolderUrls)
                {
                    SPFolder folders = site.RootWeb.GetFolder(folderUrl);
                    PublishItems(folders);

                }
            }
        }

        private static void PublishItems(SPFolder folders)
        {
            SPFileCollection filesCollection = folders.Files;
            foreach (SPFile file in filesCollection)
            {
                if (file.Level == SPFileLevel.Draft)
                {
                    file.Publish(string.Empty);
                    file.Update();
                }
            }
            foreach (SPFolder folder in folders.SubFolders)
            {
                PublishItems(folder);
            }
        }

El código anterior es muy simple. Lo que hace es recorrer todos los ficheros que están sin publicar en la carpeta de los Content Web Parts de forma recursiva, buscando todos los ficheros que están sin publicar y los publica.

Conclusión

SharePoint es un producto en el que tradicionalmente ha costado mucho llevar a cabo un ciclo de vida correcto y que se pueda mantener. Muchos de los problemas son debido a lo sencillo que es realizar cualquier modificación desde la propia interfaz, lo que hace que se realicen modificaciones en producción incluso por el propio usuario. Esto puede ser muy ágil en un primer momento pero es bastante peligroso y con funestas consecuencias como: pérdida de código, imposibilidad de recrear la aplicación en otro entorno, etc. Con el paso de las versiones, SharePoint ha ido mejorando mucho el ciclo de vida y como prueba está la forma de aprovisionar los Display Templates.