SERIE: IL CLIENT SIDE RENDERING DI SHAREPOINT 2013
- Introduzione al Client Side Rendering di SharePoint 2013 (questo post)
- Ridefinire la visualizzazione di un campo tramite il Client Side Rendering - Parte 1
- Utilizzare i namespace Javascript nella definizione di template per il Client Side Rendering
- Ridefinire la visualizzazione di un campo tramite il Client Side Rendering - Parte 2
- Ridefinire la modalità di inserimento di valori in un campo tramite il Client Side Rendering
- Gestire la modalità "Quick edit" all'interno di un display template
- Come applicare un plugin JQuery su un display template
- Aggiungere un tooltip per aiutare l'inserimento di valori tramite il Client Side Rendering
- Specificare più file Javascript all’interno della proprietà JSLink
- Utilizzare file CSS nei display template del Client Side Rendering
- Modificare il rendering delle righe di una lista tramite il Client Side Rendering
- Modificare l'intera visualizzazione di una lista tramite il Client Side Rendering
- Applicare il plugin MixItUp su liste SharePoint 2013 tramite il Client Side Rendering
- Provisioning di display template
- Ridefinire il rendering di un custom field tramite il Client Side Rendering
Il CSR non è altro che un framework Javascript (da qui il nome) che possiamo utilizzare per modificare quello che è l'aspetto di default che hanno le liste e le form di inserimento/modifica contenuti presenti in SharePoint, assieme ovviamente ad alcune delle loro funzionalità di base.
Come avrete capito, la personalizzazione viene fatta in Javascript (seguendo sicuramente i trend del momento) e l'idea di base è che:
La cosa bella è che SharePoint stesso utilizza questo framework per moltissime delle sue funzionalità.
Giusto per fare qualche esempio, il CSR viene sfruttato all'interno di liste e document library, nei risultati di una ricerca e nelle callout (di cui abbiamo già parlato al tempo). Quindi è sicuramente il modo migliore che abbiamo per modificare la UI in SharePoint e aggiungere/rimuovere funzionalità. Abbiamo un framework pronto per farlo.
Giusto per fare qualche esempio, il CSR viene sfruttato all'interno di liste e document library, nei risultati di una ricerca e nelle callout (di cui abbiamo già parlato al tempo). Quindi è sicuramente il modo migliore che abbiamo per modificare la UI in SharePoint e aggiungere/rimuovere funzionalità. Abbiamo un framework pronto per farlo.
Questa non è la prima volta che Microsoft ci prova a fare una cosa del genere. Se ci pensate bene, già nel 2007 ci avevano provato con CAML (un bagno di sangue), poi è stata la volta di XSLT e InfoPath (superati entrambi), ora siamo approdati nella nuova era delle applicazioni di front-end con HTML5 e Javascript. Speriamo sia la volta buona :)
Per utilizzare questo framework ci basta definire un template.
Un template non è altro che un oggetto Javascript, che viene iniettato all'interno dello stack di rendering client-side di SharePoint 2013 e che può essere decorato di una serie di proprietà e funzioni che a loro volta vengono utilizzate dal framework stesso per il rendering della UI e delle funzionalità che abbiamo deciso.
Ecco la struttura di base di questi template:
Ecco la struttura di base di questi template:
(function () { var ctx = {}; ctx.Templates = {}; ctx.Templates.Header = undefined; ctx.Templates.Footer = undefined; ctx.Templates.Item = undefined; ctx.Templates.OnPreRender = undefined; ctx.Templates.OnPostRender = undefined; ctx.Templates.Fields = {}; ctx.ListTemplateType = undefined; ctx.BaseViewID = undefined; SPClientTemplates.TemplateManager.RegisterTemplateOverrides(ctx); })();
Guardando la struttura di questo oggetto Javascript si possono capire la maggior parte delle funzionalità del CSR.
Definendo infatti delle nuove funzioni o dei nuovi oggetti da assegnare alle proprietà dell’oggetto "context" (la nostra variabile ctx per intenderci), abbiamo la possibilità di specificare:
Definendo infatti delle nuove funzioni o dei nuovi oggetti da assegnare alle proprietà dell’oggetto "context" (la nostra variabile ctx per intenderci), abbiamo la possibilità di specificare:
- il rendering di header e footer di una lista SharePoint
- il rendering di un’intera riga (cioè di un elemento) di una lista SharePoint
- le azioni da compiere prima o dopo il rendering della lista o del form
- i singoli campi di cui vogliamo personalizzare il rendering
- un singolo template di lista per cui questo template di rendering deve funzionare
- la view su cui questo template di rendering deve funzionare
Nota: la cosa importante che vi deve essere chiara è che tramite questo template possiamo modificare SOLO il rendering della lista (o della form). I dati e le configurazioni di visualizzazione con cui questi dati ritornano (filtri, ordinamenti, ecc..) dipendono sempre dalle configurazioni che si hanno all'interno della lista.
Punto importantissimo per il corretto funzionamento di questo template di rendering personalizzato è la chiamata al metodo RegisterTemplateOvverrides della classe SPClientTemplates.TemplateManager.
Questo metodo è quello che si preoccupa di inserire il nostro template all'interno dello stack di rendering di SharePoint 2013 e permetterne così l'esecuzione automatica.
La chiamata a questo metodo va necessariamente inserita all'interno di una funzione Javascript "self-invoking" (con le tonde aperte e chiuse in fondo per intenderci), così da essere eseguito non appena lo script viene inserito all'interno della pagina.
Ma come fa questo script ad essere renderizzato nella pagina?
Abbiamo visto la sintassi ad alto livello di un template CSR ed abbiamo detto che tale template viene iniettato all'interno dello stack di rendering client-side di SharePoint 2013.
Quello che ci manca infatti è capire come questo script Javascript viene legato ad una lista, una document library o a qualcuna delle loro form di inserimento/modifica.
E’ molto semplice.. SharePoint 2013 ha decorato le web part che vengono attualmente utilizzate per la visualizzazione di liste di dati e form di input, con una nuova proprietà: la proprietà "ScriptLink".
E’ molto semplice.. SharePoint 2013 ha decorato le web part che vengono attualmente utilizzate per la visualizzazione di liste di dati e form di input, con una nuova proprietà: la proprietà "ScriptLink".
Se decidiamo quindi di personalizzare una nostra lista di task (a puro titolo d'esempio), non dobbiamo far altro che preparare il nostro template Javascript, inserire tale template in un file .js e salvarlo all'interno di una directory o una document library che permetta di recuperarlo tramite una richiesta HTTP, modificare la web part tramite le funzionalità OOB di SharePoint 2013 e specificare la URI del nostro file Javascript all'interno della proprietà "ScriptLink" della web part.
Non so se avete capito bene.. senza sviluppare codice server-side e senza usare orribili barbatrucchi direttamente sulla pagina tramite qualche Content Editor Web Part o cose simili per modificare il comportamento di default di liste e form, abbiamo la possibilità di creare una personalizzazione SharePoint semplicemente creando un file Javascript e salvandolo in una document library. Vi assicuro che rispetto al passato questo è un bel vantaggio.
Come locazione di tale file Javascript, come vi dicevo, potete utilizzare quello che volete (una document library, la _layouts, un modulo, ecc…). Basta che il file .js siano disponibile tramite una URL (e che l'utente corrente possa accedervi ovviamente).
Come "hello world" per iniziare a scoprire il fantastico mondo del Client Side Rendering di SharePoint 2013 vi lascio questi esempi: http://code.msdn.microsoft.com/office/Client-side-rendering-JS-2ed3538a
Sono molto utili per scoprire il funzionamento di questa framework.
Nei prossimi post vedremo di scoprirlo assieme.