SharePoint Web Services e DataForm

In molte occasioni, in mancanza di altri mezzi, mi è capitato di utilizzare i web services di SharePoint per la visualizzione di dati cross site collection o cross farm. Se a qualcuno dovesse suonare nuovo quello che ho scritto si tratta di utilizzare i vari servizi che si trovano nella virtual directory _vti_bin di ciascun sito SharePoint e sfruttare uno dei metodi messi a disposizione come data source (XML Web Services) di una Data Form Web Part. Uno di questi servizi è lists.asmx, uno dei suoi metodi GetListItems (es. http://www.ilmiosito.it/_vti_bin/lists.asmx?op=GetListItems).

L’utilizzo di questo tipo di origine dati nasconde però molte insidie (che qualcuno chiama “configurazioni” :)). Vediamo alcuni dei parametri che devono essere compilati e come:

  1. listName [Obbligatorio]: il nome è parlante, si tratta del nome (nome visualizzato) della lista da cui si vogliono leggere i dati;
  2. viewName [Opzionale]: in questo caso il nome trae in inganno, non si tratta del nome della vista, ma del suo GUID. Ci interessa? Eccome! Tramite l’impostazione di questo valore possiamo scegliere quali dati saranno visibili nella dataform, con quali filtri e in che ordine. In pratica ci permette di spostare la logica di selezione ed ordinamento dei dati sulla visualizzazione e non sulla query, dall’interfaccia grafica e non da SharePoint Designer. In teoria ci sarebbe un parametro specifico per ciascuna di queste funzionalità, ma in pratica non sono mai riuscito ad utilizzarli (mancanza mia? bug? Più probabile la prima, ma è da molto che regolarmente faccio dei tentativi, tutti vani…). Se non impostato viene considerato come valore di default la visualizzazione predefinita;
  3. rowLimit [Opzionale]: Permette di specificare il limite di elementi da selezionare. Mooolto importante dal mio punto di vista in quanto sovrascrive il limite impostato nella visualizzazione specificata in precedenza. Ad esempio, se la vostra visualizzazione ha un limite di 100 elementi visualizzati potrete impostare quì un valore molto più alto, per essere certi che vengano mostrati tutti i dati. Da quello che ho potuto constatare, per quanto riguarda il limite di elementi nella visualizzazione, non si tratta di un valore assoluto, ma anche del valore di elementi per pagina. Di conseguenza, per evitare di correre il rischio di avere visualizzazioni con un numero eccessivo di elementi trovo importantissimo valorizzare questo parametro.Questa caratteristica non è un bug, ma è dovuto al fatto che il metodo GetListItems supporta la pagina lato server. Oggi ho scoperto (mio malgrado) un’altra caratteristica che deriva da questo parametro, cioè che anche per i campi di lookup pare valga la stessa logica. Mi spiego: tra i dati che visualizzo è presente una colonna di tipo lookup. La lista di riferimento di questo metadata ha più di 100 elementi e nella visualizzazione di default è impostato proprio questo limite di elementi per pagina. Bene (‘nsomma), nella mia dataform venivano visualizzati solo i dati di lookup presenti nella prima paginazione. In questo caso ho dovuto scegliere la strada più veloce, modificare cioè le impostazioni sulla vista, ma sicuramente in un momento di maggiore calma provvederò a correggere i parametri della dataform;
  4. WebId [Opzionale]: Se valorizzato permette di ridefinire lo scope di azione del servizio, agendo cioè su siti differenti da quello utilizzato per la connessione;

Ho omesso da questo elenco quei parametri che mi hanno sempre causato errori (query, viewFields, QueryOptions). Nel caso dovessi riuscire nei prossimi giorni sarò più che lieto di farvelo sapere :)

-Riccardo

XSLT e comparazione tra date

Di recente un’amica mi ha chiesto se, e come, fosse possibile gestire una sorta di scadenza degli elementi visualizzati in un DataForm utilizzando XSLT. La necessità è quindi quella di verificare che la data impostata come scadenza in un custom metadata sia maggiore dell’ora attuale. Mi aspettavo che una banale comparazione tra date funzionasse correttamente, si tratta in fondo di data type uguali (in teoria…), ma anche no.

E’ necessario normalizzare le date nel formato che più ci conviene. Prima cosa ottengo la data (ed ora) corrente utilizzando l’estensione ddwrt:TodayIso() e memorizzo il valore in una variabile.

<xsl:variable name="cheoresono" select="ddwrt:TodayIso()"></xsl:variable>

A questo punto creo altre due variabili nelle quali memorizzo le due date da paragonare “trasformate” in un valore numerico. L’obbiettivo è quello di ottenere una stringa del tipo 201007261734 (YYYYMMAAHHmm) – @TEST è la mia colonna di tipo Data e ora:

<xsl:variable name="testconverted" select="number(concat(substring(string(@TEST),1,4), substring(string(@TEST),6,2), substring(string(@TEST),9,2), substring(string(@TEST),12,2), substring(string(@TEST),15,2)))" />
<xsl:variable name="cheoresonoconverted" select="number(concat(substring($cheoresono,1,4), substring($cheoresono,6,2), substring($cheoresono,9,2), substring($cheoresono,12,2), substring($cheoresono,15,2)))" />

A questo punto posso effettuare il confronto delle due date con il semplice xsl:if

<xsl:if test="$testconverted &gt; $cheoresonoconverted">@TEST è maggiore di questo momento (secondi esclusi)</xsl:if>

Non volendo inserire all’interno del template XSL questo tipo di filtro (forse più utile per formattazione condizionale che per filtro) potrei applicarlo allo stesso modo nella query XPath presente nella dataview all’interno del template dvt_1: 

<xsl:variable name="cheoresono" select="ddwrt:TodayIso()"></xsl:variable>
<xsl:variable name="cheoresonoconverted" select="number(concat(substring($cheoresono,1,4), substring($cheoresono,6,2), substring($cheoresono,9,2), substring($cheoresono,12,2), substring($cheoresono,15,2)))" />
<xsl:variable name="Rows" select="/dsQueryResponse/Rows/Row[number(concat(substring(string(@TEST),1,4), substring(string(@TEST),6,2), substring(string(@TEST),9,2), substring(string(@TEST),12,2), substring(string(@TEST),15,2))) &lt; $cheoresonoconverted]"/>

Per quanto riguarda XSLT è tutto. E per quanto riguarda CAML… (traggo spunto da una maglietta di mio figlio che raffigura la Banda Bassotti) Maybe Next Time :)

-Riccardo

– UPDATE –

Con Barbara abbiamo scoperto un comportamento “strano” di ddwrt:TodayIso(). In alcuni ambienti questa funzione mostra data e ora della time zone GMT, nel nostro caso quindi risulta indietro di due ore. Per risolvere questo “problema” basta memorizzare la variabile cheoresono già formattata utilizzando l’estensione ddwrt:FormatDate(ddwrt:TodayIso(),1040,5). Una volta fatto questo bisogna solo prestare attenzione a modificare i parametri della funzione substring utilizzata nella conversione della data in formato AAAAMMGGHHmm.

Ringrazio ovviamente Barbara per avermi fatto notare questo comportamento :)

Formattazione condizionale nei page layout (o quasi)

L’argomento di questo post è un piccolo trick da cui spero possiate prendere spunto per le più disparate varianti. Partiamo come sempre dal descrivre l’esigenza: formattare diversamente un elemento di un page layout a seconda del valore di un page field. In questo esempio andremo a cambiare lo stile del titolo della nostra pagina a seconda del valore di un page field visibile unicamente in fase di edit della pagina.

Abbiamo quindi (almeno) due page field: Titolo – single line of text – e Categoria – choice -. In base al valore di Categoria il titolo avrà caratteristiche (font, colore, dimensioni, ecc…) differenti.

Per prima cosa inserisco nel page layout un elemento HTML (div) che conterrà il valore del page field di controllo.

<div id=”valoreCategoria” style=”display: none”>
<SharePoint:FieldValue FieldName=”Categoria” runat=”server” />
</div>

Definisco quindi la posizione nel page layout del titolo della pagina.

<div id=”titoloPagina” class=”Default-Style”>
<SharePoint:FieldValue FieldName=”Title” runat=”server” />
</div>

Subito dopo aver definito questo elemento richiamo la funzione JavaScript che si occuperà della modifica dello stile del testo.

<script language=”javascript” type=”text/javascript”>CambiaStile();</script>

Immagino che a questo punto abbiate già capito cosa fa questa funzione, i passaggi sono semplici:

  1. Selezione del contenuto dell’elemento “valoreCategoria”
    1. var myDivContent = document.getElementById(“valoreCategoria”).innerText
  2. Impostare in base al valore della variabile myDivContent la classe CSS dell’elemento “titoloPagina”
    1. switch (myDivContent){
    2. case “Categoria 1”:
    3. document.getElementById(“titoloPagina”).style.className = “Categoria1-Style”;
    4. break;
    5. case “Categoria 2”:
    6. document.getElementById(“titoloPagina”).style.className = “Categoria2-Style”;
    7. break;
    8. default:
    9. document.getElementById(“titoloPagina”).style.className = “Generico-Style”;
    10. }
  3. Voilà! :)

Questo come ho già detto è un piccolo trick, non applicabile a tutte le esigenze di formattazione condizionale, e soprattutto è un esemepio che se utilizzato in ambienti di produzione deve essere ottimizzato, sia dal punto di vista della compatibilità browser (FireFox non mi pare supporti innerText ad esempio), ma soprattutto dal punto di vista delle performance. La mia intenzione in questo caso è solo quella di farvi accendere qualche lampadina :)

– Riccardo (virtualmente in nave verso la Sardegna…)