Di niente, di meno, sul mondo dell'informatica....

Questa mattina dopo tanto studio sono finalmente risucito a dare l'esame 70-541. Debbo dire che me lo aspettavo più complicato di quello che è stato in realtà; peccato per alcuni argomenti che non ho fatto in tempo a studiare e che potrebbero aver messo a rischio la riuscita dello stesso :-(

Adesso ancora giù a studiare perché venerdì mi aspetta l'esame 70-542.

 Un file Schema.xml definisce in modo completo ogni tipo di lista che è presente all’interno di SharePoint. Nel file sono contenute le definizioni di eventuali campi speciali utilizzati nella lista, delle viste predefinite, delle toolbar e di eventuali form personalizzati che possono essere utilizzati nella visualizzazione e modifica dei campi della lista.

Esiste un file Schema.xml per ogni tipo di lista presente in un sito SharePoint; questi files possono essere contenuti nella cartella di definizione della tipologia di sito \TEMPLATE\SiteTemplates\{nome template}\Lists\{nome lista} oppure nella cartella contenente le features del sistema \TEMPLATE \FEATURES\{nome feature}; in entrambi i casi nel file Onet.xml, che contiene la “Site Definition” sarà presente il riferimento alla lista, ma nel primo caso sarà inserito nella sezione <ListTemplates> con indicato il nome della lista, mentre nel secondo caso il link con l’ID della features sarà inserito nella sezione <Configuration>.

All’interno del file Schema.xml è possibile definire una serie di importanti informazioni:

• L’elenco dei Content Type che saranno abilitati nella lista nella sezione <ContentTypes>.
• Eventuali campi personalizzati che possono essere utilizzati nella lista nella sezione <Fields>.
• Le viste che debbono essere generate automaticamente al momento della creazione della lista nella sezione <Views>.
• Le form da utilizzare per l’inserimento, la modifica e la visualizzazione dei dati nella sezione <Forms>.
• La descrizione predefinita di quella lista nella sezione <DefaultDescription> (elemento obbligatorio).

Eventuali toolbar custom nella sezione <Toolbar>.

Quando viene installato SharePoint viene creato un file Onet.xml che contiene le configurazioni globali ed un file Onet.xml per ognuna delle “Site Definitions” installate. Questo file è il cuore della configurazione del sito e permette un elevato numero di personalizzazioni. Il primo elemento del file è il nodo <Project> che da solo già permette una serie di personalizzazioni molto utili:

• Specificare un CSS alternativo (attributo “AlternateCSS”).
• Specificare un file javascript contenente delle funzioni personalizzate (attributo “CustomJSUrl”).
• Specificare una pagina ASPX alternativa per l’intestazione (attributo “AlternateHeader”).

Subito dopo troviamo la sezione <NavBars> con una collection di nodi <NavBar> dove è possibile personalizzare le aree di navigazione (sia quella superiore che quella laterale).

Troviamo poi la sezione <ListTemplates> con una collection di nodi <ListTemplate> dove sono elencate le tipologie di liste che sono disponibili per quel “Site Definitions”. Un attributo importante da tenere in considerazione è “type”, perché è proprio quell’attributo che definisce la tipologia della lista che stiamo mettendo a disposizione. Per un elenco completo delle tipologie di liste è possibile consultare la documentazione Microsoft.

Solo per il file Onet.xml contenuto nella cartella \TEMPLATE\GLOBAL\XML troviamo una collection di nodi <BaseType> che definiscono le liste di base presenti in SharePoint.

Successivamente troviamo una sezione <DocumentTemplates> contenente una collection di nodi <DocumentTemplate> dove vengono specificati i template disponibili ed i relativi file che debbono essere utilizzati per ogni template.

Una volta descritto tutto quello che avremo a disposizione nel nostro sito una volta creato, viene ora descritto che cosa viene creato automaticamente quando il sito viene creato. Di questo si occupa la sezione <Configurations> che contiene una collection di nodi <Configuration>; ogni nodo <Configuration> rappresenta la configurazione di ogni singolo sito che fa riferimento a questa definizione, l’abbinamento viene fatto tramite l’attributo “ID” che deve corrispondere all’attributo “ID” del nodo <Configuration> contenuto nel file WebTemp.xml.

All’interno di ogni nodo <Configuration> è possibile inserire delle collection di nodi <List>, <Module>, <SiteFeatures> e <WebFeatures> in base agli elementi che debbono essere creati automaticamente. E’ inoltre possibile effettuare delle operazioni post-creazione del sito inserendo un nodo <ExecuteUrl> all’interno del nodo <Configuration> e specificando l’indirizzo della pagina a cui bisogna essere rediretti una volta che la creazione del sito è finita.

Esiste poi una sezione <Modules> che contiene una collection di nodi <Module>; ogni nodo <Module> contiene uno o più nodi <File> che indicano i files da includere nella creazione del sito. Ogni file può essere aggiunto all’interno di una Document Library oppure come file di sistema.

La successiva sezione <Components> permette di indicare una serie di componenti da creare nel sito.

L’ultima sezione <ServerEmailFooter> permette di specificare il footer delle email che verranno inviate dal server.

Anche in questo caso, come nel caso del file WebTemp.xml, Microsoft consiglia di non modificare i file preinstallati dal sistema, questo sia per evitare di perdere le modifiche in caso di aggiornamento del prodotto, ma anche per evitare perdite di dati su siti già creati con le versioni non modificate!!!

Come fare allora ad aggiornare delle “Site definitions” esistenti? Innanzi tutto vale la regola di non togliere niente di quello che esisteva per evitare effetti indesiderati sui siti esistenti. Per fare delle aggiunte esistono poi diversi sistemi:

• Nel caso si cerchi di aggiungere dei nuovi <DocumentTemplate> sarà sufficiente creare dei file con il nome doctemp*.xml (dove * rappresenta una stringa di caratteri a piacere) contenente il nodo <DocumentTemplates> con al suo interno una collection di nodi <DocumentTemplate> che specificano i template da aggiungere.
• Per tutte le altre personalizzazioni non sono ancora riuscito a fare dei test adeguati, penso comunque che l’aggiunta di nodi dovrebbe risultare abbastanza stabile (anche se è una pratica da evitare assolutamente sui siti di base forniti da SharePoint), mentre in caso di modifiche bisognerà lavorare molto con l’object model di SharePoint.

Quando vengono creati dei nuovi “Site Definitions” va configurato il file WebTemp.xml per informarlo dell’esistenza delle nuove definizioni. Il file WebTemp.xml però non andrebbe mai modificato manualmente dall’utente, in quanto eventuali installazioni di aggiornamenti o ServicePack di SharePoint potrebbero causare la sovrascrittura di questo file con la conseguente perdita delle modifiche.

Per ovviare a tale problema Microsoft ha dato la possibilità di generare dei file di configurazione personalizzati; la regola da seguire è quella di memorizzarli nella stessa cartella del file WebTemp.xml e di aggiungere una stringa al nome del file (es.: WebTempCustom.xml). SharePoint provvederà ad effettuare il merge dei vari file in modo tale da essere in grado di mantenere intatte le personalizzazioni anche in seguito ad eventuali aggiornamenti.

Il file contiene una collection di nodi <Template> ed ogni nodo <Template> può contenere una collection di nodi <Configuration>. Un nodo <Template> corrisponde ad una definizione del sito contenuta nella cartella \SiteTemplates\{nome template} (dove {nome template} corrisponde al valore dell’attributo “Name”).

Ogni nodo <Configuration> corrisponde ad ogni singolo modello di sito disponibile per quella tipologia che sarà visibile nella pagina di “creazione sito”. Su ogni nodo <Configuration> è inoltre possibile definire un attributo “category” per specificare la categoria alla quale appartiene il modello di sito.

Una delle caratteristiche che mi ha più impressionato nella nuova versione di SharePoint è la possibilità di creare delle “Site Definitions”. Sebbene dal nome possano essere confusi con una sorta di “template” di siti (anche questa funzionalità presente in SharePoint) si tratta invece di qualcosa di molto più potente, infatti questa caratteristica non si limita a delle personalizzazioni di aspetto fondamentalmente grafico, ma permette di creare una sorta di applicazioni personalizzate basate sulla tecnologia SharePoint. Per fare un esempio delle potenzialità di questa caratteristica basti pensare che il sito di amministrazione di SharePoint non è altro che una “Site Definitions” creata appositamente per svolgere tutti i compiti amministrativi; tale “Site Definitions” è però definita come HIDE in modo tale da risultare invisibile all’utente nel momento in cui si effettua la creazione di un nuovo sito.

Se vogliamo costruire un nostro browser personale per esplorare il contenuto delle cartelle di SharePoint è possibile utilizzare la collection “Files”  contenuta nella classe SPFolder, semplicemente conoscendo l’URL della cartella di cui si desidera conoscere il contenuto.