Métodos de extensión en C#. Usándolos en desarrollo para SharePoint

Muy buenas a todos,

Hoy lo que os traigo es más una recopilación de información que una entrada de mi cosecha propiamente, aunque creo que es muy interesante. No pasan días sin que aprendas cosas nuevas. Todo viene de una entrada en el blog de desarrollo de Encamina, el cual os recomiendo que sigáis porque se suelen hacer entradas muy interesantes. En esta semana se ha estado haciendo un recorrido por buenas prácticas a la hora de desarrollar sobre SharePoint y entonces es cuando me topé con los “Métodos de extensión en C#”. Os dejo la entrada en cuestión.

http://blogs.encamina.com/desarrollandosobresharepoint/2015/05/05/como-aprovechar-la-potencia-de-c-en-nuestros-desarrollos/

Me ha llamado la atención el uso de los métodos de extensión de C#. Yo venía desde hace un tiempo usando algunas clases para facilitar determinadas acciones cuando desarrollo sobre SharePoint. Pero me ha resultado muy interesante ver que podemos, por medio de los métodos de extensión, asociarlos al objeto que afectan, de manera que el intellisense de VS lo detecta y además los puedes llamar como si fueran métodos del objeto propiamente dicho, sin tener que crear una clase derivada, ni heredar ni hacer nada con el objeto original. Os pongo un ejemplo de código con algo sencillo:

public static class Helper
{
   public static string MetodoExtensionEjemplo(this string s, string ejemplo)
   {
      //To do something
   }
}

Este método lo podríamos usar ahora de la siguiente forma

string s = "Hello Extension Methods";
s = s.MetodoExtensionEjemplo("hola");

La verdad es que resulta muy cómodo usarlo de esta forma. Como véis la sintaxis para definir este tipo de métodos es muy sencilla y lo vemos en el primer código.

  • La clase a la que pertenezca el método tiene que ser estática, así como el método propiamente dicho
  • El primer parámetro del método es del tipo al que queremos asociarle el método y lleva delante la palabra reservada this.

En mi caso usar esta opción que nos brinda C#, me da como resultado un código más limpio e intuitivo, así que por mi parte, merece la pena tenerlo en cuenta.

Y bueno, como me gusta compartir con la comunidad todo lo que puedo o creo que puede ser interesante, he subido a GitHub las dos clases que estoy usando como Helpers y en las que estoy usando los métodos de extensión. Por si os interesa, veréis que he creado dos clases, una que tiene las acciones “atómicas” (la clase Helpers) y otra que tiene acciones necesarias pero que son un poco “más complejas” (la clase Utility).

https://github.com/jcroav/SPHelpers

Sentíos libres de cogerlas, modificarlas, mejorarlas, proponer cambios, todo lo que suponga mejorar bienvenido sea. Por otro lado, si conocéis otros trabajos similares que se puedan utilizar y estén en fases más avanzadas, estaré encantado de saberlo. Yo de momento he creado los métodos que necesito para mi último proyecto y a medida que vaya necesitando modificar los mismos para añadir funcionalidad o mejoras o añadir nuevos los iré publicando en el repositorio.

Os dejo también el enlace de la MSDN sobre el tema de los métodos de extensión:

https://msdn.microsoft.com/es-es/library/bb383977.aspx

Anuncios

Nuevo modelo de desarrollo de Sharepoint. Adaptando nuestras soluciones de granja

Buenas tardes a todos,

Últimamemente se viene haciendo mucho hincapié desde Microsoft en el nuevo modelo de desarrollo de SharePoint, modelo que deja atrás el Feature Framework con el que veníamos trabajando últimamente y que se basa en un uso más intensivo de las APIs de Cliente y las aplicaciones para SharePoint. Obviamente, esta nueva propuesta va en detrimento de la API de Servidor y las soluciones de granja que habían sido la base de la extensibilidad de SharePoint en las versiones anteriores. Este nuevo modelo de desarrollo no solo se propone para la nueva plataforma de SharePoint OnLine, sino que se puede emplear igualmente en entornos On-Prem.

Aunque ya se ha comentado mucho sobre esto, los motivos principales que promueven este nuevo modelo podrían ser los siguientes:

  • La aparición de la plataforma OnLine, donde es obvio que las soluciones de granja, donde predomina la API de servidor, no tienen sitio.
  • Proponer un modelo de desarrollo que facilite la migración tanto a nuevas versiones On-Prem como a la versión OnLine, evitando los problemas de Upgrade del modelo anterior de desarrollo.
  • Evitar los riesgos que provocaba el anterior modelo de desarrollo, relacionado con el rendimiento como los leaks de memoria.

Un tema importante a tener en cuenta, es el hecho de que en los desarrollos sobre plataformas On-Prem, si bien se recomienda desde Microsoft adoptar de forma progresiva el nuevo modelo de desarrollo, todavía podremos seguir extendiendo la plataforma usando soluciones de granja, que estarán totalmente soportadas (ojo!!! no así las soluciones SandBox que están deprecated), al menos de momento. Lo que si nos recomiendan desde el equipo de producto es ir adaptando esas soluciones de granja para que nos sea más fácil adoptar poco a poco el nuevo modelo de desarrollo.

En este artículo os quiero enseñar algunos pasos que podríamos seguir para, si bien, en algunas ocasiones continuar trabajando en nuestros proyectos con el modelo clásico, intentar hacerlo de manera que vayamos desarrollando, de la forma más parecida posible, con los patrones y las buenas prácticas del nuevo modelo de desarrollo que nos proponen.

Adaptando nuestras soluciones .wsp para aproximarnos al nuevo modelo de desarrollo

En el ejemplo que vamos a ver a continuación nuestro objetivo será desplegar una solución de SharePoint que va a añadir una serie de columnas de sitio y tipos de Contenido. Vamos a ver la diferencia entre el approach que usaríamos habitualmente con el Feature Framework y la propuesta que nos hacen para ir aproximándonos al nuevo modelo de desarrollo.

En el primer caso usaríamos una serie de ficheros XML que añadirían tanto los tipos de contenido como las columnas de sitio. Los pasos habituales que seguiríamos serían básicamente los siguientes:

  1. Crear una característica
  2. Crear un elemento vacío de SharePoint
  3. Añadir la columnas de sitio al elemento recién creado
  4. Crear un elemento del tipo: “Tipo de Contenido”
  5. Establecer las columnas de dicho tipo de Contenido
  6. Si Visual Studio no lo ha hecho ya automáticamente (que es lo más lógico), añadiremos los elementos a la característica que habíamos creado.

El código de los ficheros .xml que vamos a añadir es el siguiente:

Para las columnas de sitio:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Field ID='{6A4E55B4-3AB1-448F-B51D-01224423C71F}' Group="Ejemplo" Type='DateTime' Name='Fecha' DisplayName='Fecha' SourceID='http://schemas.microsoft.com/sharepoint/v3' StaticName='Fecha' />
  <Field ID='{014AB8C6-02AA-41EC-B5A1-CD46668E6087}' Group="Ejemplo" Type='Note' Name='Comentario' DisplayName='Comentario' NumLines='30' StaticName='Comentario' SourceID='http://schemas.microsoft.com/sharepoint/v3' RichText='TRUE' RichTextMode='FullHtml' IsolateStyles='FALSE' />
  <Field ID='{18377DDE-58DA-4668-9FC5-EAB7A7ED70FC}' Group="Ejemplo" Type='User' Name='Valorador' DisplayName='Valorador' SourceID='http://schemas.microsoft.com/sharepoint/v3' StaticName='Valorador' />
  <Field ID='{9F764C8E-D966-416D-8148-3CC0E4E88BDA}' Group="Ejemplo" Type='Text' Name='Ruta' DisplayName='Ruta' SourceID='http://schemas.microsoft.com/sharepoint/v3' StaticName='Ruta' />
</Elements>

Para los tipos de contenido:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <!-- Tipo de contenido primario: Elemento (0x01) -->
  <ContentType ID="0x01002b1edca8d3f94d9dbeb9ca8da78b2460"
               Name="TipoContenido Ejemplo"
               Group="Ejemplo"
               Description="Descripción de ejemplo de tipo de contenido"
               Inherits="TRUE"
               Version="0">
    <FieldRefs>
      <FieldRef ID='{6A4E55B4-3AB1-448F-B51D-01224423C71F}' Name='Fecha' Required='TRUE'/>
      <FieldRef ID='{014AB8C6-02AA-41EC-B5A1-CD46668E6087}' Name='Comentario' Required='TRUE' />
      <FieldRef ID='{18377DDE-58DA-4668-9FC5-EAB7A7ED70FC}' Name='Valorador' Required='TRUE' />
      <FieldRef ID='{9F764C8E-D966-416D-8148-3CC0E4E88BDA}' Name='Ruta' Required='TRUE' />
    </FieldRefs>
  </ContentType>
</Elements>

¿Qué problemas tiene esta forma de desplegar nuestros elementos en SharePoint?. Utilizando estos ficheros xml se crean una serie de dependencias del fichero con las bases de datos de contenido que pueden darnos problemas a la hora de hacer una migración de nuestro entorno.

Captura de pantalla 2015-04-19 a las 13.33.15

Para evitar estos problemas de dependencias que se crean usando el Feature Framework de esta forma, podemos plantear otro approach, que nos aproxima a la forma de trabajar en el nuevo modelo de desarrollo. La solución, en este caso, pasaría por usar el receptor de eventos de la característica y crear los elementos programáticamente en el evento de activación de la misma.

El código que añadiríamos en el receptor de eventos sería el siguiente:

public class Feature1EventReceiver : SPFeatureReceiver
{
    // Quite las marcas de comentario al método siguiente para controlar el evento generado una vez activada una característica.

    public override void FeatureActivated(SPFeatureReceiverProperties properties)
    {
        SPSite site = properties.Feature.Parent as SPSite;

        using (SPWeb web = site.OpenWeb())
        {
            Helper.CreateTextColumn(web, "Ejemplo1", 255);
            Helper.CreateNumberColumn(web, "EjemploNumber1", 0);

            Helper.CreateContentType(web, "EjemploTipoContenido");
            Helper.AddColumnToContentType(web, "EjemploTipoContenido", "Ejemplo1");
            Helper.AddColumnToContentType(web, "EjemploTipoContenido", "EjemploNumber1");
        }
    }
} 

Como podéis ver en el código, y porque no se extienda tanto éste como el post, los elementos se crean por medio de helpers cuyo contenido no he añadido, aunque si los queréis, puedo añadirlos más adelante.

De esta forma, estaremos eliminando esos problemas de dependencias que se crean, y además estaremos dando un paso hacia la forma de trabajar en el nuevo modelo de desarrollo de SharePoint.

Captura de pantalla 2015-04-19 a las 13.33.50

La misma técnica podríamos usar para, por ejemplo, crear listas y bibliotecas, haciéndolo programáticamente en lugar de usando el despliegue por medio de ficheros XML. La línea a seguir, debería ser, en la medida de lo posible, evitar los ficheros XML para desplegar elementos y reemplazarlos por el uso de la API de SharePoint, lo que se acercará más al uso de las APIs de cliente en apps que nos proponen como nuevo modelo de desarrollo.

Os dejo algunos enlaces interesantes sobre el tema y que os pueden ayudar:

http://www.microsoftvirtualacademy.com/training-courses/transform-sharepoint-customizations-to-sharepoint-app-model

https://github.com/OfficeDev/PnP

En próximas entradas os contaré algunas cosillas más sobre el nuevo modelo de desarrollo y hacia dónde deberíamos de irnos enfocando cuando nos enfrentamos a una solución basada en SharePoint que requiere extender la plataforma.

Un saludo a todos.

Webinar sobre “Ciclo de vida de una solución SharePoint”

Muy buenas tardes a todos,

Quería compartir con vosotros un enlace a un webinar que pude presenciar la pasada semana y que me parece de un interés capital para todas las personas que profesionalmente nos dedicamos a desarrollar sobre SharePoint. Dicho webinar estuvo dirigido por los MVPs de Encamina Alberto Díaz, Santiago Porras y Adrián Díaz, y nos estuvieron desvelando algunos de los aspectos más importantes a tener en cuenta durante el ciclo de vida de un proyecto de SharePoint y nos contaron los retos que se presentan y buenas prácticas en las distintas etapas de los mismos. Como os decía, algo capital para todos los que nos dedicamos al desarrollo de proyectos sobre SharePoint.

En el webinar hablaron de distintas etapas: Gestión de requisitos, Arquitectura de la solución, Desarrollo, Diseño, Construir y empaquetar, Calidad, Testing, Despliegue y Operaciones.

Simplemente os dejaré algunos consejos y “buenas prácticas” que he sacado del webinar.

  • El primer aspecto cuando estamos en la fase de requisitos es que hay que tener claro que estamos desarrollando sobre SharePoint, puede parecer algo muy obvio, pero todo el mundo implicado en el proyecto tiene que conocer el producto y lo que nos ofrece.
  • No se puede cambiar el producto y es importante, siempre que sea posible usar lo estándar y solo extenderlo en el caso de que nuestros requerimientos lo necesiten.
  • Usar patrones y buenas prácticas de desarrollo como haríamos para cualquier otro proyecto, porque en ese aspecto SharePoint no es diferente, se puede hacer sin ningún problema.
  • Usar una herramienta de control de código fuente.
  • Estandarizar los entornos de desarrollo por medio de herramientas tipo SPInstaller y conocer los requisitos de desarrollo y tenerlos en cuenta para todo el equipo de desarrollo.
  • Con respecto al diseño, hay que procurar homogeneizar el look & feel de páginas, los elementos y el comportamiento de los mismos dentro de nuestro proyecto. Tener una comunicación fluida y proactiva entre los equipos de desarrollo y diseñadores y algo muy importante, tratar los fallos de UX como defectos y no como mejoras en nuestros proyectos para evitar que caigan en el olvido.
  • Es importante hacer CodeReviews periódicas en las que se analice el código y se intente mejorar el mismo.
  • Sobre los desarrollos en SharePoint, se pueden y deben hacer Test unitarios. Evidentemente, habrá aspectos que no se pueden probar, como los elementos de la API, pero debemos testear la lógica de negocio de nuestra aplicación.
  • Establecer un proceso de despliegue de nuestras soluciones, que sea conocido y que por medio de PowerShell incluya también parametrizaciones, configuración y que todo quede registrado para poder hacer seguimiento. No usar SharePoint Designer para hacer modificaciones, o si se hace, convertirlo lo antes posible en un artefacto o elemento que pueda ser desplegable.

Os dejo el enlace del webinar que desde Encamina han dejado en su canal de Youtube y os recomiendo a todos que lo veáis porque os va a dar información de mucha utilidad.

Enlace al webinar de Ciclo de vida de una solución

Un saludo a todos. Nos vemos en breve con mas temas de interés sobre todo lo relacionado con Azure, SharePoint y Office 365 por el blog.

Ámbitos de Búsqueda en SharePoint 2010

Muy buenas a todos,

Últimamente, no venía siendo muy habitual que escribiera algo sobre SharePoint 2010, en los últimos meses estaba más centrado en los desarrollos para toda la suite de productividad de Microsoft, y así seguirá siendo en las próximas entradas, pero como en mi trabajo aún tengo proyectos basados en esta versión de SharePoint, quería compartir un aspecto en el que he profundizado relacionado con las búsquedas en SharePoint 2010.

Para todos los que conocéis o conocemos las características de SharePoint 2013 relacionadas con las búsquedas, habréis visto la cantidad de cosas que se pueden hacer, el Search Driven Development (SDD) nos permite cubrir muchos requisitos solo usando las opciones que nos proporcionan las búsquedas. De una forma muy sencilla, por medio de configuración de las búsquedas y usando los estándares de programación web (Javascript, Css y HTML) podemos hacer aplicaciones completas.

Si bien, con SharePoint 2010 no podemos alcanzar este nivel tan avanzado, si podemos hacer configuraciones interesantes para las búsquedas. En mi caso, para un proyecto necesitaba de un nivel importante de personalización de los resultados de búsqueda. Para este proyecto, al final, lo que pretendíamos es que las búsquedas solo devolvieran los elementos de unas listas determinadas de todo el proyecto. Para conseguir esto, al final, usamos el concepto de los “Ámbitos de Búsqueda” y “Grupos de Presentación”. Finalmente usando esto hemos conseguido el resultado justo que queríamos.

Vamos a ver cómo definir y usar los ámbitos de búsqueda en SharePoint 2010.

Definiendo el Ámbito de Búsqueda para SharePoint 2010

Lo primero que vamos a hacer es crear el ámbito de búsqueda para nuestro sitio. Los ámbitos de búsqueda, los podemos crear a nivel de Administración Central en la configuración de nuestro servicio de búsqueda, o bien en la configuración de la colección de sitios.

Para crear el ámbito a nivel de la configuración de la colección de sitios, hacemos lo siguiente:

image (5)

image (6)

Una vez en el apartado de ámbitos de búsqueda, pulsamos sobre crear o añadir un nuevo ámbito y nos aparece una pantalla como ésta.

image (7)

Aquí especificaremos el nombre y descripción del ámbito que vamos a crear y a qué página de resultados queremos que nos lleve. Una vez completada esta información, pulsamos sobre el botón Aceptar y ya tendremos el ámbito  creado para nuestra colección de sitios.

Añadiendo las reglas al ámbito de búsqueda

La potencia de los ámbitos de búsqueda se encuentra en las reglas que definamos para éstos. Aquí disponemos de bastante versatilidad y podemos definir mucha variedad de reglas. El siguiente paso tras crear el ámbito será asignarle las reglas que queremos para el mismo. Pulsamos sobre la opción de añadir reglas, y nos encontraremos una pantalla como la que veremos a continuación.

image (9)

Como podemos observar, podremos especificar restricciones para todas las propiedades administradas que hayan sido rastreadas y configuradas por nuestro servicio de búsqueda. Es posible que alguna en concreto no aparezca entre la opciones disponibles, pero sin embargo, si que se encuentre entre las propiedades administradas. Esto se debe a que seguramente no tenga la opción de disponible para usar en ámbitos activada. En mi caso, era lo que sucedía cuando quería usar en los ámbitos la propiedad de ContentType.

En el caso de que esto ocurra, y si queremos activar el uso en ámbitos para una determinada propiedad, nos vamos al servicio de búsqueda en la administración central de SharePoint y accedemos a las propiedades administradas rastreadas y mapeadas, seleccionamos aquella que queremos habilitar, damos a la opción editar y hacemos click sobre la casilla correspondiente como vemos en la siguiente imagen.

image (10)

image (11)

Cuando aceptamos y guardamos los cambios ya la tendremos disponible en las reglas de nuestro ámbito.

De esta forma podemos crear todas las reglas que deseemos y personalizar mucho los resultados de búsqueda que queremos obtener. En mi caso, por ejemplo, usando el valor de la propiedad ContentType, conseguimos limitar los resultados de búsqueda a una a serie de tipos de contenido concretos asociados a las listas cuyos elementos queríamos que aparecieran en las búsquedas, consiguiendo así cumplir con los requisitos preestablecidos para las búsquedas de dicho proyecto.

Creando el Grupo de Presentación

Para usar los ámbitos dentro de nuestro WebPart de búsqueda, vamos a asociar el mismo a un grupo de presentación, para luego establecer este mismo como predeterminado en dicho WebPart. Para ello, en el apartado de configuración de la colección de sitios, en los ámbitos de búsqueda, vamos a la opción de grupos de presentación y crear un nuevo grupo.

image (12)

En esta pantalla indicamos el nombre al grupo de presentación y los ámbitos que queremos que pertenezcan al mismo. Una vez hecho esto, lo que haremos será configurar el WebPart de Cuadro de Búsqueda o SearchBox WebPart para que funcione limitando las búsquedas a este ámbito que hemos creado.

Configurando el WebPart de Búsqueda

Lo primero que vamos a hacer es agregar un WebPart de Cuadro de Búsqueda en una página de nuestro sitio.

image (1)

Tras esto, vamos a las propiedades del WebPart para configurarlo. Es muy sencillo, por un lado, vamos a indicar el grupo de presentación que queremos que use este WebPart. Esto lo haremos en el apartado de varios tal y como vemos en la siguiente imagen.

image (2)

image (3)

Seleccionaremos el grupo de presentación que hemos creado en el apartado anterior. El último aspecto de configuración del WebPart está en la primera casilla de las propiedades del WebPart, con el modo de la lista desplegable, seleccionaremos la opción de “Mostrar pero no incluir ámbitos contextuales”, para que solo seleccione el ámbito que creamos y añadimos al Grupo de Presentación.

image (4)

En mi caso, no quería que el despegable se mostrara, aunque si que cogiera por defecto el ámbito que había creado, esto lo conseguí por medio de CSS, poniendo la propiedad display a none para la clase del despegable.

De esta forma, las búsquedas de mi aplicación se limitan por defecto al ámbito de los elementos que yo quiero, y se elimina todo lo demás, dando, en el caso de lo que queríamos conseguir, una mejor experiencia de usuario de una forma sencilla.

Esto, es lo que me ha parecido a mi más próximo a todo lo que podemos hacer con el SDD en SharePoint 2013. Evidentemente, no tenemos ni la navegación basada en metadatos ni las posibilidades de configuración de los WebPart de búsquedas, ni los display templates, pero nos permite bastantes personalizaciones.

Y esto es todo por hoy, poco a poco después de las vacaciones iré retomando la actividad del blog con cosas interesantes. Nos vemos pronto

Saludos a todos.

SPSD: SharePoint Solution Deployer. Script para hacer deploy de soluciones en SharePoint

Muy buenas a todos,

Hace unos meses os enseñaba mi primer script powershell con el que se podía hacer deploy de soluciones en diferentes WebApplications. Aunque el script cumplía sus funciones y para usarlo en los entornos de desarrollo y pruebas ha funcionado con buenos resultados, a la hora de usarlo en un entorno de producción, necesitábamos más información y poder hacer un mejor seguimiento del deploy y el resultado del mismo. Aquí os dejo un enlace al post donde se encuentra el script que os comentaba.

Script de PowerShell: Despliegue de soluciones automáticamente

Lo que hoy os quiero enseñar, aunque seguro que muchos ya lo conocéis, es SPSD: SharePoint Solution Deployer, que como en la misma web del proyecto indica:

SharePoint Solution Deployer helps you to deploy SharePoint solution packages (.wsp) to multiple SharePoint environments. It deploys, retracts and upgrades one or more WSPs and can be extended to perform additional custom tasks in PowerShell before or afterwards. Unlike the most of the available scripts on the net, it performs all necessary prerequisite checks and post-deployment actions on all servers in the farm to assure the deployment runs smooth.

Aquí os dejo el enlace a la web del proyecto en CodePlex, donde lo podéis descarga. Es muy sencillo de usar y muy completo, tiene un fichero de configuración muy potente en el que puedes configurar todo el aspecto del deploy de las soluciones. Toda la documentación es muy completa y puedes ver todas las opciones que tiene.

http://spsd.codeplex.com/

Como podréis ver en la página principal del proyecto con el fichero de configuración se podrán configurar aspectos tan diversos como:

  • TimeOut de espera del script, versión mínima de SharePoint, licencia mínima de SharePoint, etc.
  • Tipo de deploy que se va a realizar
  • Acciones a llevar a cabo después del deploy: reinicio de servicios, ejecutar warmup, etc.
  • Establecer que donde se debe hacer el deploy de cada solución

Si no lo conocíais ya, espero que os sea útil, yo estoy empezando a usarlo como script para el deploy de soluciones y estoy teniendo unos resultados muy buenos.

Un saludo a todos

Search Driven Development (III): El WebPart de Refinamiento

Muy buenas a todos de nuevo,

Antes de nada, os deseo una Feliz Navidad a todos. Hoy quiero seguir profundizando un poco más en el concepto de Search Driven Development. Vamos a trabajar con el WebPart de refinamiento. Al igual que el Content Search WebPart, el de refinamiento es completamente configurable de una forma muy sencilla. Mucho más que lo era el WebPart de refinamiento en SharePoint 2010.

Además, y aunque no es objeto de este post, también se pueden crear plantillas para estos refinadores de búsqueda, tal y como hacíamos con los tipos de resultado.

Para explicar como trabajar con el WebPart de refinamiento he planteado un escenario en el que dispongo de un catálogo de formaciones y he creado al igual que hacía en los anteriores post, su respectiva página de catálogo y elementos de catálogo, configurando posteriormente el Content Search WebPart de cada uno.

Primeros Pasos con SharePoint OnLine: Search Driven Development

Search Driven Development en SharePoint (II): Catálogos y Elementos de Catálogo

El tipo de Contenido que he creado para el catálogo es el siguiente:

Captura de pantalla 2014-12-26 a las 2.24.48

Una vez creado el catálogo y su funcionalidad, añadimos a la página del catálogo el WebPart de refinamiento, dándonos un aspecto como el siguiente.

Captura de pantalla 2014-12-26 a las 2.20.45

El caso es que para nuestro catálogo, no es suficiente con los refinadores por defecto que nos carga el WebPart de refinamiento, queremos establecer nuestros propios refinadores, basados en el tipo de contenido que hemos definido. En nuestro caso queremos poder refinar nuestro catálogo por: Tipo de Formación, Autor, Temática y Valoración.

Definiendo las propiedades administradas para el refinamiento

Todas las opciones de refinamiento de nuestro WebPart se basan en propiedades administradas de nuestro esquema de búsqueda. Pero lo harán en unas propiedades especiales que en nuestro esquema aparecen con el nombre de: RefinableString, RefinableInt, RefinableDouble, RefinableDate, en función del tipo de dato que representa cada una, disponiendo de un número elevado de cada una de ellas para poder configurar correctamente nuestras propiedades administradas de refinamiento.

Lo que tendremos que hacer es, asociar las propiedades rastreadas que queramos usar en el refinamiento a las propiedades administradas correspondientes. Vamos a ver como hacer esto.

Para empezar vamos a Configuración del sitio->Esquema de Búsqueda de la administración de la colección de sitios (a nivel de sitio no tenemos permisos para hacerlo) y accederemos al esquema de búsqueda de la colección de sitios.

Captura de pantalla 2014-12-26 a las 2.40.16

Lo que haremos ahora, es ir a las distintas propiedades administradas para asociarlas adecuadamente. En mi ejemplo, quiero añadir cuatro refinadores, tres pueden ser mapeados como cadena y uno como número. Las propiedades administradas de refinamiento tienen números correlativos asignados (por ejemplo RefinableString00 a RefinableString99), así que seleccionamos la propiedad que queremos mapear y entramos a ella.

Captura de pantalla 2014-12-26 a las 2.46.12

Una vez dentro, tenemos que asignar las propiedades rastreadas. Para ello, hacemos click en asignar propiedades.

Captura de pantalla 2014-12-26 a las 2.46.24

Captura de pantalla 2014-12-26 a las 2.46.48

Buscamos la propiedad rastreada que queramos mapear, por defecto SharePoint, para cada columna que hayamos definido crea dos propiedades rastreadas, como las que vemos a continuación:

Captura de pantalla 2014-12-26 a las 2.48.36

Para el refinamiento, tenemos que seleccionar la propiedad que tiene la forma ows_<nombre de la propiedad>. Seleccionamos ésta y damos a aceptar, luego guardamos los cambios hechos en la propiedad administrada y, en nuestro caso, como queríamos crear cuatro refinadores personalizados, repetimos la tarea para el resto de refinadores.

Personalizando el WebPart de refinamiento

Una vez que ya hemos definido los refinadores personalizados que vamos a utilizar, podemos ir a la página del catálogo para configurar el WebPart de refinamiento. Para ello nos iremos a las propiedades de dicho WebPart y la opción de “Elegir refinadores”.

Captura de pantalla 2014-12-26 a las 3.00.20

Captura de pantalla 2014-12-26 a las 3.00.38

Por defecto nos aparecen los refinadores que vemos en la imagen anterior. En nuestro caso, queremos cambiarlos por los que habíamos definido en el paso anterior. Por lo que cambiamos los refinadores por defecto por los siguientes: RefinableString01, RefinableString02, RefinableString03, RefinableInt01.

Captura de pantalla 2014-12-26 a las 3.03.36

Si hacemos click sobre cada uno de los refinadores podemos cambiar algunos aspectos de la visualización de los mismos. Entre otras cosas, nombre de ese refinador a  la hora de mostrarlo, tipo de plantilla (en función del tipo de refinador), y aspectos de configuración que varían en función del tipo de refinador que hayamos seleccionado.

Captura de pantalla 2014-12-26 a las 3.06.17

Captura de pantalla 2014-12-26 a las 3.06.35

Cuando hayamos configurado todos los refinadores, pulsamos aceptar y guardamos los cambios en el WebPart, con lo que ya tendremos nuestra página de Catálogo con unos refinadores personalizados y ajustados a nuestras necesidades. Es posible, que cuando se hayan definido los mismos, inicialmente, si no se ha realizado todavía una re-indexación de la lista posterior al mapeo adecuado de todas la propiedades administradas, no aparezca nada, esto se subsanará en cuestión de minutos, cuando la re-indexación se complete correctamente. Este es el aspecto que sin nada de diseño, nos queda del Content Search WebPart y el WebPart de refinamiento.

Captura de pantalla 2014-12-26 a las 3.11.27

Y nada más por hoy, espero que toda esta serie de artículos relacionados con el Search Driven Development, os estén siendo de utilidad. Os dejo algunos enlaces que me han servido a la hora de preparar el post.

http://blogs.technet.com/b/tothesharepoint/archive/2013/06/19/stage-14-configure-refiners-for-faceted-navigation.aspx

http://blogs.technet.com/b/tothesharepoint/archive/2013/11/11/how-to-add-refiners-to-your-search-results-page-for-sharepoint-2013.aspx

Un saludo.

Introducción al uso de Display Templates en SharePoint OnLine

Muy buenas de nuevo a todos,

En mis anteriores entradas he estado hablando sobre como podríamos usar los Content Search Web Part para hacer personalizaciones de nuestros sitios sin escribir ninguna línea de código. Habíamos conseguido una página que nos mostraba un catálogo de elementos y enlaces a la página donde podíamos ver el detalle de los elementos de dicho catálogo.

Primeros Pasos con SharePoint OnLine: Search Driven Development

Search Driven Development en SharePoint (II): Catálogos y Elementos de Catálogo

En ambas entradas os hablaba de la posibilidad de personalizar el diseño de esos resultados para hacerlos más atractivos e integrarlos con el branding de nuestro sitios. Para los que hayáis trabajado con la personalización de los resultados de búsqueda en SharePoint 2010, os habréis topado seguro con las plantillas XSL que nos obligaban a saber manejar XSLT para la creación de las mismas. Con SharePoint OnLine y 2013 todo este approach ha cambiado, dentro de toda la renovación de la plataforma para hacerla más ligera y cercana a las nuevas tecnologías. Ahora vamos a poder trabajar directamente con HTML y Javascript, lo que seguro que nos va a resultar muy interesante. Todo esto es lo que vamos a ver al hablar de los Display Templates. Nuestro objetivo va a ser, pasar de esto:

Captura de pantalla 2014-12-12 a las 19.58.55
Captura de pantalla 2014-12-13 a las 23.25.54

A una visualización de los resultados de nuestro Content Search Web Part como estos:

Captura de pantalla 2014-12-20 a las 15.28.29
Captura de pantalla 2014-12-20 a las 15.28.43

Aunque no se trata de un diseño muy elaborado, si que nos va a servir para ver que de una forma muy sencilla vamos a poder modificar la visualización de los resultados de búsqueda. Antes de nada, os voy a mostrar algunos enlaces que he utilizado para saber como usar los Display Templates.

http://blogs.technet.com/b/tothesharepoint/archive/2013/05/28/stage-11-upload-and-apply-display-templates-to-the-content-search-web-part.aspx

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

La información de nuestros Display Templates la vamos a encontrar en dos sitios. Si queremos editar las propiedades de las plantillas ya subidas, iremos al administrador de diseños al que podemos acceder de la siguiente manera, donde en el apartado de “Editar plantillas para mostrar”, encontraremos las plantillas ya cargadas:

Captura de pantalla 2014-12-20 a las 15.49.54

Si por el contrario queremos añadir nuevas plantillas lo haremos a través de Configuración del sitio->Páginas maestras y diseños de página->Display Templates->Content Web Parts

Captura de pantalla 2014-12-20 a las 15.53.45

Cuando accedemos al lugar que nos permitirá añadir nuevas plantillas, vemos que cada una de las plantillas ya subidas tiene dos archivos, uno .html y otro .js. Nosotros solo tendremos que crear el .html con la plantilla, el archivo con extensión .js se crea automáticamente al subir el anterior y es transparente para nosotros, este archivo contiene la sustitución que hace SharePoint de una serie de etiquetas especiales que se usan en las plantillas, por las correspondientes que haya que usar.

En nuestro caso, para lograr el objetivo que os he mostrado, vamos a crear dos plantillas, una para los elementos cuando están dentro del catálogo y otra para la página que muestra el detalle de uno de los elementos del catálogo

¿Como creamos una plantilla personalizada?

Como hemos dicho antes, una plantilla es un archivo .html con una serie de etiquetas especiales. Voy a mostraros como es una plantilla y después os explicaré algunos aspectos que hay que tener en cuenta.

<html xmlns:mso="urn:schemas-microsoft-com:office:office" xmlns:msdt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882">
<head>
    <title>Plantilla de Ejemplo</title>
  
    <!--[if gte mso 9]><xml>
    <mso:CustomDocumentProperties>
    <mso:TemplateHidden msdt:dt="string">0</mso:TemplateHidden>
    <mso:ManagedPropertyMapping msdt:dt="string">
        'Title'{Título}:'Title',
        'Skills'{Capacidades}:'CapacidadesOWSTEXT',
        'SecondaryFileExtension',
        'ContentTypeId'
    </mso:ManagedPropertyMapping>
    <mso:MasterPageDescription msdt:dt="string">Este es el ejemplo de una plantilla para resultados de elementos de busqueda</mso:MasterPageDescription>
    <mso:ContentTypeId msdt:dt="string">0x01006BCAA0AD8F40D041AD8D1579799074B6</mso:ContentTypeId>
    <mso:TargetControlType msdt:dt="string">;#Content Web Parts;#SearchResults;#</mso:TargetControlType>
    <mso:HtmlDesignAssociated msdt:dt="string">1</mso:HtmlDesignAssociated>
    </mso:CustomDocumentProperties></xml><![endif]-->
</head>
  
<body>
  
    <div id="ExampleSearchDrivenSolution">
  
<!--#_
    var encodedId = $htmlEncode(ctx.ClientControl.get_nextUniqueId() + "_exampleTemplate_");
  
    var linkURL = $getItemValue(ctx, "Link URL");
    linkURL.overrideValueRenderer($urlHtmlEncode);
  
    var title = $getItemValue(ctx, "Title");

  
    var skills = $getItemValue(ctx, "Skills");
  
    var containerId = encodedId + "container";
  
 _#-->
  
        <div id="_#= containerId =#_" style="float:left;width:25%;margin-left:0.5em;border:1px solid #CCC; min-height:25em;background-color:#EEE;cursor:pointer;position:relative;" onclick="window.location.href = '/sites/organizer/autores/_#= title =#_'">
            <span style="color:red;">_#= title =#_</span>
            <p style="text-decoration:underline;position:absolute;bottom:0.5em;">_#= skills =#_</p>
        </div>
  
    </div>
</body>
</html>
  • El primer aspecto importante se encuentra entre las líneas 5 y 18. Aquí se define un XML donde se definirán los parámetros de la plantilla. Lo más importante tiene que ver con lo que se define en la etiqueta “mso:ManagedPropertyMapping”, que es donde se definen las propiedades administradas que serán mapeadas en la plantilla y que usaremos después en la misma para mostrar los distintos campos del elemento devuelto por la búsqueda.
  • Con las etiquetas “<!–#_” y “_#–>” podremos escribir todo el código Javascript que queramos dentro de nuestra plantilla.
  • Haciendo uso de las etiquetas “_#=” y “=#_” podremos hacer uso de variables de Javascript que hayamos definido previamente
  • Es importante tener en cuenta que solo el contenido que aparezca en el primer ”
    <div>” será visible dentro de nuestra plantilla.

Este es el código que he usado para la plantilla de los elementos que forman parte del catálogo. A continuación os muestro la que he usado para el detalle de los elementos. La diferencia, a parte del diseño, se encuentra en las propiedades administradas que se mapearán en cada caso.

<html xmlns:mso="urn:schemas-microsoft-com:office:office" xmlns:msdt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882">
<head>
    <title>Plantilla de Ejemplo para elementos</title>
  
    <!--[if gte mso 9]><xml>
    <mso:CustomDocumentProperties>
    <mso:TemplateHidden msdt:dt="string">0</mso:TemplateHidden>
    <mso:ManagedPropertyMapping msdt:dt="string">
        'Link URL'{Dirección URL del vínculo}:'Path',
        'Title'{Título}:'Title',
        'Skills'{Capacidades}:'CapacidadesOWSTEXT',
        'Email'{Email}:'EmailOWSTEXT;,
        'WebSite'{Sitio personal}:'PersonalWebsiteOWSURLH;,
        'SecondaryFileExtension',
        'ContentTypeId'
    </mso:ManagedPropertyMapping><mso:MasterPageDescription msdt:dt="string">Este ejemplo se utiliza para el elemento de la lista</mso:MasterPageDescription>
    <mso:ContentTypeId msdt:dt="string">0x01006BCAA0AD8F40D041AD8D1579799074B6</mso:ContentTypeId>
    <mso:TargetControlType msdt:dt="string">;#Content Web Parts;#SearchResults;#</mso:TargetControlType>
    <mso:HtmlDesignAssociated msdt:dt="string">1</mso:HtmlDesignAssociated>
    <mso:HtmlDesignConversionSucceeded msdt:dt="string">True</mso:HtmlDesignConversionSucceeded>
    </mso:CustomDocumentProperties></xml><![endif]-->
</head>
  
<body>
  
    <div id="ExampleSearchDrivenSolution">
  
<!--#_
    var encodedId = $htmlEncode(ctx.ClientControl.get_nextUniqueId() + "_exampleTemplate_");
  
    var title = $getItemValue(ctx, "Title");
  
    var skills = $getItemValue(ctx, "Skills");

    var mail = $getItemValue(ctx, "Email");
  
    var website = $getItemValue(ctx, "WebSite");
  
    var containerId = encodedId + "container";
  
 _#-->
        <h2>Nombre: _#= title =#_</h2>

        <span style="display:block;margin-top:1em;font-weight:bold;font-size:1.2em;">Descripción de las habilidades</span>
        <p>_#= skills =#_</p>

        <span style="display:block;margin-top:1em;font-weight:bold;font-size:1.2em;">¿Deseas ir a su web para conocer más sobre este autor?</span>
        <a href="_#= website =#_">_#= website =#_</a>

        <span style="display:block;margin-top:1em;font-weight:bold;font-size:1.2em;">¿Quieres ponerte en contacto con este autor?</span>
        <a href="mailto:_#= mail =#_">_#= mail =#_</a>
  
    </div>
</body>
</html>

¿Cómo subimos una plantilla personalizada?

Una vez que ya hemos definido nuestras plantillas, vamos a añadirlas a nuestro sitio de SharePoint para poder usarlas. Para ello, seguimos la ruta que ya indicamos antes, para entrar al sitio donde podremos subirla. En nuestra Ribbon, desplegamos la opción de “Nuevo Documento” y hacemos click en “Plantillas para mostrar de elementos”:

Captura de pantalla 2014-12-20 a las 16.30.50

A continuación seleccionamos la plantilla a subir,

Captura de pantalla 2014-12-20 a las 16.31.12

Por último se carga la pantalla de propiedades de la plantilla, donde vemos precargadas las propiedades que ya definimos en el código de la misma. Si no lo hemos hecho en el código de la plantilla, aquí deberemos indicar el Tipo de Contenido asociado, el título de plantilla, el tipo de control de destino y el Archivo Asociado.

Captura de pantalla 2014-12-20 a las 16.31.30

Una vez hecho esto, veremos que la plantilla se ha añadido correctamente a nuestra lista de plantillas y que efectivamente se ha creado asociado al .html el .js . Para que esté disponible para ser usada, tenemos que ir al administrador de diseños y aprobar la plantilla que acabamos de subir que estará en estado “Borrador” en ese momento.

Captura de pantalla 2014-12-20 a las 16.49.46

Tras esto la plantilla ya estará disponible para usarla en nuestro Content Search WebPart. El proceso para subir una nueva plantilla lo repetiremos para las dos plantillas de nuestro sitio.

Usando la plantilla en el Content Search WebPart

El último paso que nos queda es cargar las plantillas en cada uno de los Content Search WebPart, por un lado el que se encuentra en la página que muestra el catálogo y por otro el de la página que nos muestra los elementos del catálogo, usando en cada caso la plantilla deseada

Para ello, editamos el web part de la página correspondiente, seleccionando la plantilla que queremos usar como vamos a ver a continuación.

Captura de pantalla 2014-12-20 a las 17.01.34

En el apartado de plantillas para mostrar de las propiedades del webpart, marcamos Usar una plantilla única para mostrar elementos y ahí seleccionamos nuestra plantilla

Captura de pantalla 2014-12-20 a las 17.01.58

Una vez hagamos esto con las dos plantillas, ya tendremos las mismas funcionando y podremos ver los resultados de búsqueda con el diseño que queríamos.

Espero que os resulte interesante la información. Un saludo a todos