SERIE: IL CLIENT SIDE RENDERING DI SHAREPOINT 2013

La creazione di campi custom è una possibilità che abbiamo su SharePoint fin dalla versione 2007 (WSS 3.0). Su questo sito potete trovare infatti un vecchio articolo di introduzione all'argomento, che risulta tutt’ora valido.
Nel tempo il meccanismo di base è rimasto fondamentalmente invariato. Quello che è cambiato è la modalità con cui possiamo modificare il rendering del campo.
Facciamo un salto negli anni scorsi per arrivare ad oggi:

  • SharePoint 2007 – La visualizzazione di un campo custom all'interno delle Form di visualizzazione, inserimento e modifica, poteva essere implementata solamente attraverso uno User Control (.ascx) in cui si specificavano gli elementi HTML da visualizzare ed eventuali comportamenti personalizzati (per lo più tramite Javascript). La rottura di scatole di questo meccanismo era il passaggio del valore del campo dalla view alla parte di code-behind. Abbiamo anche un articolo che lo conferma.
    La visualizzazione del campo all'interno di una view invece, poteva essere modificata solo tramite CAML e precisamente valorizzando l'elemento RenderPattern. Questa era ancora peggio, perché le possibili modifiche erano limitate alle funzionalità di CAML.

  • SharePoint 2010 – In questa versione di prodotto è stata aggiunta la possibilità di modificare la visualizzazione tramite XSLT. Un po' meglio rispetto a prima eh, ma comunque per arrivare ad un risultato decente c’era da sudare.

  • SharePoint 2013 – Se avete seguito questa serie di post, avrete sicuramente capito che ora la view di un vostro campo custom può essere fatta semplicemente applicando un display template del Client Side Rendering. In questo modo, abbiamo la possibilità di ridefinire la visualizzazione all'interno delle varie Form di inserimento, modifica e dettaglio, assieme alla possibilità di specificare il rendering del campo all'interno di viste.
Secondo me siamo arrivati ad un ottimo punto e, visto che in quest'anno avremo modo di vedere una nuova versione del prodotto (SharePoint 2016), spero proprio che al posto di cambiare ancora una volta le cose, questa volta cerchino di irrobustire l'attuale meccanismo.

Bene, ritorniamo a noi.
Per utilizzare un display template all'interno di un campo custom, dobbiamo inserire nella nostra farm solution i seguenti oggetti:

  • Il file XML di definizione del campo custom (fldtypes_ChartFieldType.xml)
  • Una classe che eredita da uno dei campi base di SharePoint (nel mio caso sono partito da SPFieldNumber)
  • Il file Javascript contenente il nostro display template
  • Tutti i file CSS o Javascript utili al corretto funzionamento del nostro display template
Il file XML di definizione non lo vediamo. Non è cambiato niente da quel punto di vista rispetto a quanto si faceva nelle vecchie versioni.
Questa invece la classe a rappresentare il nostro campo custom:

public class ChartField : SPFieldNumber
{
    private const string JSLinkUrl = "~site/_layouts/15/D4S/Scripts/jquery-2.1.0.min.js"
            + "|~site/_layouts/15/D4S /Scripts/jquery.easypiechart.min.js"
            + "|~site/_layouts/15/D4S/Scripts/ChartField.js";
   public ChartField(SPFieldCollection fields, string name) : base(fields, name) { }
   public ChartField(SPFieldCollection fields, string typename, string name) : base(fields, typename, name) { }
    public override string JSLink
    {
        get
        {
            return JSLinkUrl;
        }
        set
        {
            base.JSLink = value;
        }
    }
}

Come potete vedere, è proprio in questo punto che abbiamo modo di specificare il valore della proprietà JS Link ed attaccare quindi il nostro display template al nostro campo custom.
Nel mio caso, assieme al display template ho attaccato anche JQuery e il plugin JQuery.EasyPieChart, utile a renderizzare dei grafici a torta.

Questo invece è il codice che ho scritto per il display template. Obiettivo di questo display template è prendere il valore numero del mio campo e renderizzare un grafico con la percentuale di completamento al suo interno (la percentuale di completamente è il valore che viene inserito all’interno del campo).

window.D4S = window.D4S || {};
window.D4S.SP2013 = window.D4S.SP2013 || {};
window.D4S.SP2013.CSR = window.D4S.SP2013.CSR || {};

D4S.SP2013.CSR.ChartFieldView = function(ctx) {
    var percentValue = ctx.CurrentItem[ctx.CurrentFieldSchema.Name];

    var html = '<span class="d4s-chart" data-percent="' + percentValue + '">';
    html += '<span class="d4s-percent"></span>';
    html += '</span>';

    return html;
};

D4S.SP2013.CSR.ChartFieldApplyCSS = function (ctx) {
    var css = '<link rel="stylesheet" type="text/css" href="/_layouts/15/D4S.SPOC14.DV313.CustomFields/Styles/ChartField.css" />';
    document.write(css);
};

D4S.SP2013.CSR.ChartFieldApplyChart = function (ctx) {
    $(".d4s-chart").easyPieChart({
        easing: 'easeOutBounce',
        lineWidth: 15,
        barColor: '#0072C6',
        trackColor: '#F1F1F1',
        size: 150,
        onStep: function (from, to, percent) {
            $(this.el).find('.d4s-percent').text(Math.round(percent));
        }
    });
};

(function () {
    var ctx = {};
    ctx.Templates = {};
    ctx.Templates.Fields = {
        'ChartField': {
            'View': D4S.SP2013.CSR.ChartFieldView,
            'DisplayForm': D4S.SP2013.CSR.ChartFieldView
        }
    };
    ctx.Templates.OnPreRender = D4S.SP2013.CSR.ChartFieldApplyCSS;
    ctx.Templates.OnPostRender = D4S.SP2013.CSR.ChartFieldApplyChart;

    SPClientTemplates.TemplateManager.RegisterTemplateOverrides(ctx);
})();

Rispetto ai display template che abbiamo visto fin'ora, l'unica differenza sostanziale è che per ridefinire il rendering di un campo custom, non possiamo più riferirci a tale campo tramite l'InternalName ma dobbiamo farlo tramite il nome della classe C# scelto per rappresentare il campo custom. Questo perché, ovviamente, non sapremo mai quale sarà il nome che verrà assegnato al campo una volta che verrà inserito all'interno di una lista.
Per il resto, in questo display template abbiamo applicato tutte le tecniche che abbiamo visto durante queste mini-serie di post, a partire dall'applicazione di plugin JQuery, per arrivare all'utilizzo di più file Javascript o CSS.
Questo il risultato finale del nostro campo custom.

Inserimento/modifica


Visualizzazione



Come potete capire attraverso questo ultimo post della nostra serie, tramite il Client Side Rendering abbiamo davvero la possibilità di ridefinire gran parte della UI di liste e campi SharePoint e dare quindi ai nostri utenti finali delle applicazioni veramente d'impatto. Il tutto sfruttando un linguaggio allo stesso tempo facile all'uso e veramente potete come Javascript.