Arquitectura, buenas prácticas y desarrollo sobre la nueva herramienta de Microsoft SharePoint 2016

SharePoint: aprovisionar Display Templates

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. display templates

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.

2133.figure1.jpg-550x0

 

 

 

 

 

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.

Referencias

http://www.compartimoss.com/revistas/numero-17/introduccion-plantillas-elementos-contenido-display-templates

http://blogs.technet.com/b/sharepoint_quick_reads/archive/2013/08/01/sharepoint-2013-customize-display-template-for-content-by-search-web-part-cswp-part-1.aspx

mm

Sobre Adrián Díaz

Adrián Díaz es Ingeniero Informático por la Universidad Politécnica de Valencia. Es MVP de Microsoft en la categoría Office Development desde 2014, MCPD de SharePoint 2010, Microsoft Active Profesional y Microsoft Comunity Contribuitor 2012. Cofundador del grupo de usuarios de SharePoint de Levante LevaPoint. Lleva desarrollando con tecnologías Microsoft más de 10 años y desde hace 3 años está centrado en el desarrollo sobre SharePoint. Actualmente es Software & Cloud Architect Lead en ENCAMINA.
Esta entrada ha sido publicada en sharepoint 2013 y etiquetada como . Enlace permanente .
Suscríbete a Desarrollando sobre SharePoint

Suscríbete a Desarrollando sobre SharePoint

Recibe todas las actualizaciones semanalmente de nuestro blog

You have Successfully Subscribed!

ENCAMINA, piensa en colores