Campi Person or Group in SharePoint Designer 2010

Con questo post vorrei inaugurare una serie di post dove condividere brevi pillole sugli argomenti più vari, ovviamente sempre nell’orbita del mondo SharePoint.

Se ho capito bene come fare dovreste trovare anche un link dove verranno raggruppati tutti i post di questa categoria.

Lavorando con SharePoint Designer alla creazione di Data Form Web Part o alla personalizzazione di stili per la Content Query Web Part, capita spesso di imbattersi in campi di tipo Person or Group, pensate anche semplicemente ai campi Autore o Autore Ultima Modifica.

SharePoint Designer 2010 ci offre la possibilità di “consumare” il nostro dato in forma diversa. L’immagine seguente è un dettaglio dell’origine dati SharePoint, dove Nome è un campo di tipo Person or Group.

image

Se ne deduce facilmente che nei nostri template xsl potremo utilizzare tutti e quattro i formati:

A mio avviso l’aspetto più pratico è quello di poter utilizzare il nome nell’utente senza dover per forza di cose o applicare una normalizzazione del dato o “ereditare” tutta la struttura HTML a supporto di questo tipo di campo.

Happy SPD
– Riccardo

Trasformazione di stringhe in XSLT

In generale gestire la trasformazione di una stringa, sia in linguaggi client side che server side, è una cosa semplice. Non è però così  immediato farlo all’interno di una data view via XSLT.

Gogolando ho trovato un template XSLT (qui) che permette in modo molto semplice di trasformare “mele” in “pere” o, citando casi più probabili “&” in “%26”. Eccolo qui:

<xsl:template name="replaceCharsInString">
<xsl:param name="stringIn"/>
<xsl:param name="charsIn"/>
<xsl:param name="charsOut"/>
<xsl:choose>
<xsl:when test="contains($stringIn,$charsIn)">
<xsl:value-of select="concat(substring-before($stringIn,$charsIn),$charsOut)" disable-output-escaping="yes" />
<xsl:call-template name="replaceCharsInString">
<xsl:with-param name="stringIn" select="substring-after($stringIn,$charsIn)"/>
<xsl:with-param name="charsIn" select="$charsIn"/>
<xsl:with-param name="charsOut" select="$charsOut"/>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$stringIn"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>

Il template si richiama, dove serve, passando tre parametri: la stringa originale, la stringa da sostituire, la stringa corretta.

<xsl:call-template name="replaceCharsInString">
<xsl:with-param name="stringIn" select="string(@iltuoTitolo)"/>
<xsl:with-param name="charsIn" select="'&amp;'"/><!-- ATTENZIONE, la stringa &amp; è inclusa tra apici singoli '&amp;' -->
<xsl:with-param name="charsOut" select="'%26'"/><!-- ATTENZIONE, anche questa stringa è contenuta tra apici singoli '%26' -->
</xsl:call-template>

Un aspetto interessante di questo template è che può essere utilizzato anche per gestire la presentazione dei campi di lookup a selezione multipla, trasofrmando un elenco di stringhe separate da punto e virgola in quello che volete (es. un elenco puntato/numerato). Per fare questo è necessaria una piccola modifica al template, giusto per inserire nell’output il codice HTML corrispondente alla nuova formattazione.

Un’altra trasformazione che spesso viene richiesta (per scelta o per forza vista l’estrema fantasia di editors e contributors… :)) è quella da maiuscolo a minuscolo o viceversa. In questo caso non è necessario utilizzare un template custom, è sufficiente creare due variabili e utilizzare la funzione OOTB translate. Ecco come fare (lowercase to uppercase, per gestire il processo inverso invertire la posizione delle due variabili nella funzione translate).

<xsl:variable name="vLowercaseChars_CONST" select="'abcdefghijklmnopqrstuvwxyz'"/>
<xsl:variable name="vUppercaseChars_CONST" select="'ABCDEFGHIJKLMNOPQRSTUVWXYZ'"/>
<xsl:variable name="normalizedChars" select="translate(@ilvostrocampoqui, $vLowercaseChars_CONST , $vUppercaseChars_CONST)" />

Una pecca di queste tre righe è quella di non prevedere la possibilità di inserire caratteri intermedi con uno stile diverso, come ad esempio una maiucola dopo un punto. Se qualcuno ha scritto un template per gestire questo aspetto è il benvenuto su queste pagine ;)

– Riccardo

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

Ancora su Data Form Web Part & SQL Server

In questo periodo sto lavorando molto sulla visualizzazione di dati provenienti da basi dati esterne (SQL Server). Esclusi BDC e terze parti quello che rimane è la tanto cara Data Form Web Part. In questo “giro” ho scoperto un parametro con il quale non mi era ancora capitato di incontrarmi/scontrarmi.

Ma andiamo con ordine. Lavorando con fonti dati SQL cerco sempre di non utilizzare query “in-line”, del tipo SELECT A,B,C FROM TABLE, ma di utilizzare stored procedure, spostando così la logica di selezione dati su SQL Server. Il mio obbiettivo è quello di semplificare tutte quelle attività legate all’estrazione dei dati e non alla loro presentazione.

Per rendere dinamici i dati estratti la stored procedure di turno richiedeva 4 parametri di cui solo due obbligatori. E qui viene il bello. Come impostazione predefinita i tag <asp:SqlDataSource … /> e <SharePoint:SPSqlDataSource … /> hanno la proprietà “CancelSelectOnNullParameter” impostata a True! Di conseguenza, prima di scoprirlo, non ero in grado di ottenere alcuna informazione dalla mia query.

Altre volte mi era capitato di lavorare con stored procedure che richiedevano più parametri, ma la query era differente da quest’utlima e impostando, lato Data Form Web Part, la proprietà ConvertEmptyStringToNull a False nella definizione dei parametri (nel data source) questo problema non mi si era mai posto. Peccato, mi avrebbe risparmiato un po’ di mal di testa :)

Infine… avete mai provato a concatenare due origini dati di tipo SQL Server che utilizzano entrambe stored procedure? Tutte le volte che ho provato io SharePoint Designer non si è dimostrato molto collaborativo… ho dovuto impostare data source e stylesheet a mano… comodo…

– Riccardo

Abilitare i filtri nella toolbar delle Data Form Web Part con data source SQL Server

Personalmente penso che le Data Form Web Part siano lo strumento più potente che abbiamo a disposizione in SharePoint Designer, io ne sono un grande fan. In alcuni casi sembra però che ci siano delle limitazioni. Ad esempio in una data view (aka Data Form Web Part) con origine dati SQL Server sembra che sia possibile abilitare la toolbar unicamente con funzionalità di ordinamento e raggruppamento.

Sicuramente c’è una qualche motivazione valida dietro a questa scelta, fatto stà che nel merito di un progetto che ho seguito ultimamente avevo bisogno di questa funzionalità, era diventata una questione di vita o di morte (ehm… forse un tantino esagerato). Abbandonata la UI di SPD mi sono così concentrato sul codice XSL.

Come primo passo ho copiato da una Data View “classica” i template XSL relativi alla gestione della funzionalità di filtering (al secolo dvt_1.toolbar, dvt.filterfield, dvt.filteroption) e li ho inclusi nel mio stylesheet, così come i parametri che vengono dichiarati a livello “globale” quando si utilizza la toolbar di ordinamento, filtro e raggruppamento.

A questo punto a livello grafico ero già in grado di vedere le diverse drop down valorizzate con i dati corretti. Unico “piccolo” problema che modificando la selezione del campo non accadeva nulla, ad eccezione di un postback.

Il secondo passo è stato quindi quello di occuparmi della gestione del filtro. Per questo ho modificato la funzione javascript che viene chiamata al verificarsi dell’evento “onchange” sulla drop down. La mia scelta sul come operare è stata dettata dal tipo di soluzione adottata per la selezione dati, cioè un origine dati SQL che interroga una stored procedure. La stored procedure accetta tre parametri in ingresso: filtro “full text” (non consideratelo ora), campo da filtrare, valore da filtrare.

Via javascript, all’evento onchange, richiamo quindi la stessa pagina “aggiungendo” nel querystring i due paramentri relativi al filtro. Ottentere questi valori è semplice: il primo, cioè il nome del campo da filtrare è una variabile già presente nel template dvt.filterfield, mentre il secondo, cioè il valore, lo si può recuperare facilmente via javascript. Infine ho modificato il template dvt.filteroption per fare in modo che al refresh della pagina la drop down mostrasse il valore selezionato dall’utente.

– Riccardo