Tag

Alla SharePoint Conference di Las Vegas, fra le novità che più mi hanno entusiasmato lato Site Building, sono stati i miglioramenti introdotti nella Content Query Web Part, la cosiddetta regina delle web part (disponibile, come nel 2007, solo per chi ha le publishing features abilitate, ovvero Moss se si parla del 2007 o SharePoint Server se siamo in ambito 2010).

In particolare, sebbene lato scelta di origine di query non ci siano cambiamenti, ovvero rimangano valide le vecchie impostazioni:

  • tutta la site collection
  • da un certo sito in giù
  • una lista specifica

image ,

cosiccome lato “tipo” di lista e content type una volta individuata l’origine:

image

 

lato tipo di filtri, arriva la grande novità, ovvero possiamo utilizzare dei filtri dinamici che variano in base al contesto, ovvero:

  • valore di un campo
  • parametro via query string
  • data

image

In un contesto specifico, tutto ciò cosa significa?

Facciamo un esempio: immaginiamo di dover progettare un sito di un’azienda “GreenWheels” che vende prodotti (moto e bici); la redazione del sito ha un’area in cui presenta le schede di prodotto e un’altra in cui cura gli eventi dove questi prodotti sono presenti. Non sarebbe male se:

  • nella sezione eventi, se di parla del prodotto GreenBike e GreenCycle, piuttosto che del modello GreenMoss o GreenFoundation, fosse creato un link automatico alle schede di prodotto (tanti link quanti sono i prodotti di cui si parla);
  • nella sezione prodotti, in una fantomatica area “Siamo presenti a” fossero creati automaticamente i link alle pagine degli eventi.

La Content Query Web Part è la soluzione che fa al caso nostro. In che modo?

Innanzitutto dobbiamo crearci una site columnn “Modelli” (magari del nuovo tipo Managed Metadata, visto che stiamo lavorando con SPS 2010) in cui elencare i nostri prodotti, poi dobbiamo fare in modo che la nostra site column sia presente sia nel content type che gestisce gli eventi che in quello delle schede di prodotto.

A questo punto, costruiremo un page layout per gli eventi e uno per il prodotto.

Nel caso specifico degli eventi, inseriremo una CQWP che faremo puntare alla library Pages (del sottosito prodotti) con content type “prodotti”, poi sfrutteremo il filtro dinamico PageFiledValue facendolo puntare alla colonna modelli, ovvero [PageFieldValue:Modelli].

La stessa cosa per i prodotti: inseriremo una CQWP che faremo puntare alla library Pages (del sottosito eventi) con content type “eventi”, poi sfrutteremo il filtro dinamico PageFiledValue facendolo puntare alla colonna modelli, ovvero [PageFieldValue:Modelli].

E il gioco è fatto. Quando il redattore inserirà i contenuti (senza preoccuparsi della struttura della pagina e senza mettere a mano alla CQWP che non è neanche tenuto a conoscere) e compilerà il campo Modelli, automaticamente la CQWP restituirà i collegamenti voluti (anche se, ad esempio, negli eventi si farà riferimento a più di un evento).

Conclusione:

  • rispetto al 2007, non dovremo più costruire un page layout per ogni modello (questo ero lo “sporco” lavoro che ci toccava fare);
  • sempre rispetto al 2007, ora la CQWP supporta i campi di scelta multipla (e questa è una grande novità).

Affinché quest’ultimo punto sia vero è però indispensabile una condizione di fondo: quando si imposta l’origine, doppiamo puntare a una lista specifica (ultima delle 3 opzioni, quindi no tutta la site collection o da un certo sito in giù); in caso contrario, non vedremo la nostra site column fra quelle disponibili per l’impostazione dei filtri.

Per il momento è tutto, magari ci “rivediamo” presto con un bell’How-to sulla CQWP.

W la Content Query Web Part

Ciao

Barbara