lunedì 3 maggio 2010

Publishing Site con WSS 3.0 – 3

Riprendendo il discorso dell’ultimo articolo, analizzeremo le funzionalità aggiunte al sito, utili per l’editore e la soluzione adottata per la gestione della Quick Launch.

New Web Part Page

Per creare una nuova pagina di tipo web part con lo stesso template della pagina di default del sito, ho dovuto personalizzare l’application page che gestisce la creazione delle pagine. Per la pagina custom di creazione delle web part page ho seguito quanto riportato in questo articolo Creating Custom Web Part Page Templates for Microsoft SharePoint Products and Technologies; l’unico dettaglio, come riportato da me nel forum su SharePoint (Web Part Page Template ?!?!), è che se si vogliono aggiungere i propri template di pagina ad una custom site definition bisogna creare nella cartella 1033 o 1040 una cartella con il nome della propria site definition e aggiungere la sottocartella DOCTEMP con all’interno la cartella SMARTPGS e in questa porre i propri template.



Master Page


In questo sito volevo che le visualizzazioni pubbliche avessero una master page diversa dalla master page delle pagine di servizio, dove con pagine di servizio intendo le pagine di gestione delle liste, non solo le pagine amministrative (ad es. /_layouts/Settings.aspx). Per ottenere questo risultato ho sfruttato il concetto di ~masterurl/default.master e ~masterurl/custom.master offerto da SharePoint. L’argomento l’ho già affrontato nel post Custom Master Page. Per questo motivo nella pagina che consente l’associazione delle master page ci sono due voci, default e custom. Il check box “Set children master page” permette di impostare la master page scelta anche a tutti i sotto siti del sito a cui si sta cambiando la master page.




Welcome Page


L’ultima funzionalità utile per l’amministratore del sito, presente in MOSS, ma non in WSS è la pagina che permette di associare al sito una nuova welcome page, diversa dalla pagina default.aspx. Purtroppo la funzionalità è veramente minimale nella sua realizzazione, pertanto è necessario digitare a mano la url della nuova welcome page. Questa infine sarà un nuova web part page, memorizzata nella lista Pages del sito. Il codice per cambiare la welcome page usando l’Object Model di SharePoint è il seguente:

using (SPSite siteCollection = new SPSite(http://server/sites/sandbox)) {
using (SPWeb site = siteCollection.RootWeb) {
SPFolder rootFolder = site.RootFolder;
rootFolder.WelcomePage = "Pages/home.aspx";
rootFolder.Update();
}
}

Per onestà intellettuale vi posto anche l’url del blog che mi ha spiegato come fare: Setting the Welcome Page in WSS 3.0.



Quick Launch

Per risolvere il problema della Quick Launch ho deciso di affidarmi a un Event Handler (PagesReceiver) associato alla lista Pages del mio sito. Il compito dell’Event Handler è quello di intercettare le azioni compiute sugli item della lista e di reagire di conseguenza. L’Event Handler della lista Pages crea una nuova entry nella Quick Launch in una posizione predefinita, ovvero come figlia dell’heading Pages (un articolo utile HOW TO: Programmatically customize site navigation in WSS 3.0 and MOSS 2007). Possiamo dire che questa è la parte semplice dell’eserc izio, anche se un problemino invero c’è. Quando creo una pagina con la pagina descritta precedentemente i metadati dell’item non sono ancora stati valorizzati, pertanto il nome della pagina corrisponde al nome file, estensione compresa.




Per modificare la label associata all’item della Quick Launch è necessario rieditare l’item e impostare la proprietà Title, che all’atto della creazione sarà non valorizzato.






Un’altra semplice attività è la rimozione della voce di menu quando cancello una pagina dalla lista. La cosa difficile invece è gestire la possibilità di nascondere la pagina dalla Quick Launch, senza rimuoverla dalla lista Pages. Ho provato a creare un algoritmo che si basa sul metadato Visible, che ho aggiunto alla lista Pages, ma francamente, per il momento, ho ottenuto un risultato assai scarso. Se qualcuno avesse suggerimenti in merito sarei più che felice di riceverli, per trovare una soluzione migliore. Cercherò di descrivervi in breve l’idea: alla mia lista Pages personalizzata, oltre ad una colonna Visible ho aggiunto una colonna ParentIDs, in cui tengo traccia di tutti i Node ID che precedono il nodo corrente, ovvero la pagina appena inserita in quicklaunch; questa colonna contiene una stringa con i valori separati da punto e virgola.
Quando cancello una pagina questa viene semplicemente rimossa dalla quicklaunch (evento ItemDeleted), mentre se cambio la proprietà Visible da true a false, allora cancello il nodo dalla quicklaunch ma non dalla lista Pages, quando riporto la proprietà Visible al valore originale leggo la proprietà ParentIDs per stabilire la posizione in cui inserire il nodo. Di seguito il metodo che ri-aggiunge il nodo alla quicklaunch, come dicevo non è perfetto, ma per la maggior parte dei casi funziona bene.
private void AddNode2Navigation(SPWeb web, SPNavigationNode rootLink, SPNavigationNode node, string parentIDs)
{
string[] ids = null;
SPNavigationNode tmp = null;
if (!String.IsNullOrEmpty(parentIDs))
{
ids = parentIDs.Split(';');
for (int i = ids.Length; i > 0; i--)
{
tmp = web.Navigation.GetNodeById(Int32.Parse(ids[i - 1]));
if (tmp != null)
{
rootLink.Children.Add(node, tmp);
return;
}
}
}
// if parent ids are null.
if (rootLink.Children.Count > 1)
rootLink.Children.AddAsLast(node);
else
rootLink.Children.AddAsFirst(node);
}

Se qualcuno avesse suggerimenti da darmi per migliorare il metodo o per realizzarne uno migliore non si faccia scrupoli a contattarmi.