Anche oggi, da un cliente, in occasione di un progetto che prevede la personalizzazione di WSS (Windows SharePoint Services), mi sono imbattuto con le Site Definitions…

In parole povere, si tratta di un sacco di file e cartelle che danno vita e trasferiscono specifiche impostazioni agli Elenchi e Raccolte di WSS.

Il tutto è solitamente collocato in:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033
se si tratta della versione inglese di WSS/SPS o
C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1040
se si tratta di quella italiana.

Per ogni modello di Elenco o Raccolta c’è una specifica cartella sul file system del server, dentro alla quale sono collocate le pagine .aspx che rappresentano la gestione dei contenuti degli Elenchi e Raccolte create sulla base del relativo template. Oltre a questi file sono poi presenti alcuni file .xml di configurazione, per definire i campi presenti nei diversi form e le impostazioni generali delle liste.
Modificando ad esempio i file contenuti  nella cartella LISTS\EVENTS si andranno a modificare i comportamenti di tutte le liste Eventi (o Calendario) create in tutti i siti su WSS.

Per rimanere nell’esempio, una caratteristica poco gradita del modello Events è il fatto che all’aggiunta di un nuovo appuntamento è richiesto obbligatoriamente di specificare data/ora di inizio dell’appuntamento ma non la fine dello stesso… chi quindi utilizza questo oggetto per gestire la prenotazione di sale riunioni aziendali o altro all’interno della intranet, si trova con molti utenti che prenotano le sale indicando l’inizio della prenotazione… ma non la fine!

Una possibile soluzione è quella di lavorare sulla Site Definition di Events, indicando come required anche la compilazione del campo fine.

Le linee guida per lo sviluppo e il buon senso suggeriscono di evitare la modifica diretta di questi file, e di crearsi invece delle proprie Site Definitions personalizzate. Non è infatti sempre corretto intervenire con delle modifiche che si estenderanno su tutti i siti aziendali… ed inoltre, cosa accadrà di fronte all’installazione di un nuovo Service Pack? Che magari… guarda caso… decide proprio di aggiornare le Site Definitions standard?
Creandosene di proprie si potranno legare specifici comportamenti a particolari template personalizzati, da sfruttare soltanto nei siti dove effettivamente occorrono; ed infine non si correranno rischi di fronte ad un incontrollato Windows Update! 🙂

Per chi desidera approfondire, segnalo un post letto su di un blog che riassume (purtroppo solo parzialmente) la logica delle Site Definitions. Oltre a questo utile prospetto, segnalo da non perdere due articoli pubblicati su MSDN Online. Il primo è sui modelli, sui diversi tipi di file delle Site Definitions; il secondo approfondisce alcuni aspetti trattati nel primo articolo orientando alla corretta personalizzazione dei siti WSS ed SPS.