Uno de los grandes problemas que nos encontramos entre los equipos de desarrollo a la hora de poder realizar el trabajo de la forma mucho más sencilla posible, es la sincronización entre los diseñadores y los desarrolladores. Esto en SharePoint es un problema, ya que los miembros del equipo no pueden estar trabajando simultáneamente en la misma tarea y siempre es necesario que uno empiece a continuación del otro, o bien que trabaje más de la cuenta.
Por ejemplo, tenemos que desarrollar un listado con los últimos elementos de una lista, las tareas están claras a priori ¿no? Por un lado el equipo de Diseño se tiene que encargar de realizar el HTML y el equipo de desarrollo se tiene que encargar de introducir la lógica para mostrar la información de la lista de SharePoint. En teoría, son dos tareas que se pueden separar ya que las van a realizar dos personas totalmente distintas y que en principio no debe de haber ninguna dependencia. Pero esto, introducido dentro del entorno SharePoint se traduce en que tenemos que implementar un Visual Web Part, por lo que, puesto en la practica, los desarrolladores tenemos dos opciones:
- Esperar a que el equipo de diseño empiece a hacer el HTML para introducirlo en el WebPart
- Empezar a desarrollar, hacer un HTML básico e implementar la lógica del formulario
Desventajas
Naturalmente la gran desventaja es que tenemos que trabajar o bien más de la cuenta en la opción 2 o dependemos de que el equipo de diseño realice su trabajo para que nosotros podamos empezar. Esto, trasladado al mundo real es algo que no podemos permitirnos, no podemos depender de que otros terminen su trabajo para poder comenzar porque quizás el tiempo que tenga que emplear uno u otro no es el mismo.
Si lo miramos desde el prisma de un diseñador, esta opción tampoco es 100 % de su agrado. ¿Motivo? terminan su HTML, pero antes de ponerlo en producción necesitan añadir un nuevo campo que no estaba establecido, pues tienen que volver a enviar el HTML al desarrollador para volverlo a introducir en su desarrollo. Quizás un trabajo que podía ser 10 minutos pueda costar más de una hora en total. Lo cual hace que cada vez la productividad se vaya perdiendo.
¿Como podemos ser más productivos?
En este momento es en el que se introduce Mustache.js. ¿Que es Mustache.js? es una «famosa» libreria javascript que se utiliza para crear plantillas HTML en las que mediante JavaScript se pueden rellenar sus valores en tiempo de ejecución. Por explicarlo de alguna forma sencilla es como los Displays Templates que se utilizan en el Content By Search pero pudiéndolo emplear en cualquier parte de SharePoint. Utilizando Mustache.js tenemos la opción por un lado, de que el equipo de diseño cree la plantilla del Formulario y por otro, los desarrolladores implementen la lógica para guardar los datos introducidos en el formulario.
¿Como funciona Mustache?
Por un lado en el HTML tenemos que definir los campos que queremos que se rellenen de forma automatica mediante el simbolo «mustache» {{ }}. De tal forma que, por ejemplo, si queremos mostrar la lista de Clientes con sus determinados datos tendriamos que poner el siguiente HTML:
</pre>
<div id="customers-table-template">{{headers.Contact}}{{headers.Country}}{{headers.Edad}}
{{Contact}}{{Country}}{{Edad}}
<table id="customers">
<tbody>
<tr>
<th>{{headers.Company}}</th>
</tr>
<!– {{#customers}} –>
<tr>
<td>{{Company}}</td>
<!– {{/customers}} –></tr>
</tbody>
</table>
</div>
<pre>
Este HTML se puede introducir en SharePoint de dos formas:
- Mediante un PageLayout en caso de que lo queramos reutilizar.
- Mediante el WebPart de Fragmento de código, en caso de que sea un aspecto puntual y que solo se vaya a utilizar en ese momento.
Mi recomendación es que estas plantillas están guardadas en PageLayouts de forma que, conforme vayamos desarrollando cada vez estas plantillas las podamos reutilizar y si en los siguientes proyectos nos piden un listado de clientes solamente nos quedará ajustar los CSS 🙂
Una vez la parte de diseño está realizada, al mismo tiempo los desarrolladores pueden ir implementando la lógica para consultar la lista de SharePoint. Para que una vez tengamos los datos, Mustache se encargue de realizar la magia de cambiar la plantilla HTML por los valores obtenidos. Para ello implementamos un JavaScript como el siguiente:
Con esto tenemos el siguiente resultado:
jQuery.ajax({
url: "http://sharepoint.test/_api/web/lists/GetByTitle('Demo')/items",
type: "GET",
headers: {
"accept": "application/json;odata=verbose",
"content-type":"application/json;odata=verbose",
"X-RequestDigest": $("#__REQUESTDIGEST").val()
},
success: function (data) {
var customers=[];
for (var i=0;i<data.d.results.length;i++)
{
customers[i]={'Company':data.d.results[i].Title,
'Contact':data.d.results[i].Contact,
'Country':data.d.results[i].Country,
'Edad':data.d.results[i].Edad}
}
var tabledef = {headers: {Company: "Company",
Contact: "Contact",
Country: "Country",
Edad: "Edad"},
customers: customers};
$( '#customers-table' ).simpletable(tabledef);
},
error: function (x, y, z) {
alert("Oooooops... it looks like something went wrong uploading your file.");
}
});
¿Posibles Inconvenientes?
Esta claro (y no es parte de este post) que cada vez que se requiera una modificación será necesario que exista por lo menos una parte de diseño y otra parte de desarrollo. También es posible que desde desarrollo se dejen preparados más campos de los que se muestren pensando en que en un futuro se vayan a utilizar. Pero esta opción se tendría que desechar principalmente porque la consulta realizada no sería optima y se estaría trayendo más información que la extrictamente necesaria.
Esta forma de trabajar requiere de mucho compromiso entre las dos partes del equipo, pero estamos trabajando en un mundo en el que la relación entre los miembros del equipo debe de ser fluida y no que sean dos bloques independientes. Lo que buscamos con esta forma de trabajar es eliminar las dependencias entre unos y otros, no que se dejen de hablar 😛
Otro de los inconvenientes es que es necesario tener un escenario con los datos de prueba, de tal forma que la parte de diseño pueda comprobar realmente como ha quedado su diseño cuando tenga datos reales. Para solucionar este inconveniente la tarea es un poco más compleja y se saldría del contenido de este post. Pero seria preparar «algo» para que desde diseño se pudieran consultar los «mock». Como? pues con un generador de datos de prueba 🙂
Conclusión
Hemos visto como en SharePoint también se puede trabajar de forma ágil y rápida al igual que en otro tipo de proyectos de otras tecnologías. Para ello, por un lado es necesario el conocimiento en SharePoint, pero también una visión «diferente» y «crítica» de cómo se pueden hacer mejor las cosas y para esta parte el ser compañero de gente como Iwan (CTO de ENCAMINA) te facilita mucho las cosas, ya que cuando tu has pensado una solución el ya tiene la respuesta a la misma, aparte de su gran conocimiento.
Enlaces de Interes
¡Suscríbete a nuestras RRSS!
