Desde las primeras versiones de SharePoint, el equipo de desarrollo del producto lo ha dotado de un Framework de generación de formularios de elementos de listas o bibliotecas de documentos.
Esto nos permite, desde las páginas de configuración de las listas/bibliotecas, definir ciertas características que deben de cumplir los campos o metadatos asociados a esta. Así, cuando creamos un campo, configuramos las siguientes propiedades:
- Nombre y tipo de información que se va a almacenar en la columna
- Configuración adicional como descripción, si debe contener información, si se aplican valores únicos o aquellas asociadas al tipo de información seleccionada.
- Validación de la columna donde especificamos una fórmula para validar los datos de la columna cuando se guarda el elemento.
Además, podemos configurar el orden de visualización de las mismas en los formularios, pero poco más.
Hasta aquí vamos bien y para formularios de datos sencillos es más que suficiente, pero siempre nos encontramos con la misma sencilla pregunta: «¿Podemos hacer que el campo estado no se vea al crear un elemento? O ¿Podemos que ese campo estado sólo se vea para los usuarios del grupo Gestores?» y la respuesta siempre ha sido «Sí, con algo de desarrollo«. Y es aquí donde siempre le hemos pedido más a SharePoint y no hemos tenido la respuesta adecuada.
Lo habitual era modificar los XSLT y personalizar la visualización de los formularios, en función de las necesidades del negocio, pero la complejidad del código XSLT nos llevó a inyectar JavaScript para realizar esas personalizaciones, a lo que el equipo de producto ha respondido, en SharePoint 2013, con JSLink, un mecanismo soportado por los formularios de SharePoint para inyectar JavaScript, y con la ampliación del modelo de objeto de cliente (CSOM o REST), que nos permite interactuar con casi todos los servicios del producto. JSLink nos permite reducir el tiempo y el coste de personalización del formulario, pero sigue sin ser lo que esperamos del producto.
InfoPath fue el primer intento de diseñador de formulario entregado al usuario. En SharePoint 2010 se introdujo la posibilidad de cambiar los formularios estándares por formularios InfoPath asociados a las listas y, en cierto modo, cumplía con casi todo lo que los usuarios solicitaban, pero el mayor problema es que estos formularios asociados a InfoPath nos sacaban del estándar del mercado y la tecnología de renderizado XML que usaba no es la más adecuada para los navegadores y dispositivos actuales. Si a esto, le unimos la complejidad de entender como conectar el formulario con sistemas externos, mediante el uso de consultas XML, lo que provocaba un rechazo por parte del usuario que no tenía claro como hacer lo que quería con este. Aunque soportado en SharePoint 2013, el equipo de producto lo ha deprecado y no seguirá evolucionando sus funcionalidades, con lo que no es recomendable su uso y sería deseable plantearse la migración a otra tecnología con soporte en el futuro.
¿Qué posibilidades tenemos?
JSLink me parece una buena opción, con limitaciones, pero con muchas posibilidades, la pega es que requiere de un desarrollador que conozca bien JavaScript y no se lo podemos entregar a un usuario avanzado para que cree el formulario o lo mantenga.
Seamos sinceros ¿cuántos usuarios tiene la capacidad y el tiempo de crearse sus propios formularios? Pero ¿y si hablamos del departamento de IT? Esa combinación puede ser buena, un usuario de negocio y un integrante del departamento de IT tienen el tiempo y la capacidad de diseñar formularios pero necesitan esa herramienta que se lo permita.
Access 2013 puede ser otra opción, aunque siempre hay que tener en cuenta que cuando las publicamos en SharePoint 2013 se convierten en aplicaciones casi aisladas que nos permiten tener mantenimiento de datos pero poca integración con el resto de sistemas de la organización, por ejemplo, con nuestro sistema de procesos o flujos de trabajo. No es la opción ideal, pero yo no la descartaría para ciertos casos que necesitemos mantener información y entregarle al usuario formularios para que realice este trabajo.
Productos de terceros, como Nintex Forms o K2, son la opción ideal en SharePoint 2013. Teniendo en cuenta el coste de licenciamiento y la curva de aprendizaje, nos permiten personalizar los formularios, normalmente, desde la propias páginas de SharePoint, incluso poder conectar los campos del formulario a orígenes externos como puede ser nuestro directorio activo, bases de datos o servicios web, permitiéndonos enriquecer nuestros procesos de negocio y centralizar los procesos en un único punto que es la ya conocida intranet.
Para los que ya conocemos SharePoint esto suena a normal pero me sigue sorprendiendo las múltiples posibilidades que encontramos para poder extender y mejorar los servicios que trae de base, bien con productos de terceros o con nuestros propios desarrollos. ¿Conocéis alguna otra plataforma que nos ofrezca estas posibilidades? SharePoint no es el producto perfecto, pero es el que tiene más servicios y la posibilidad de extenderlos y hacerlos mejores o adaptados a nuestras necesidades de negocio.
¡Suscríbete!
