In questo periodo sono occupato quasi settimanalmente con lo Starting Innovation Tour, un ciclo di conferenze gratuite organizzate da Microsoft nelle principali città italiane per mostrare a sviluppatori e partner le principali novità di Vista e Office 2007. Dopo Catania, Napoli, Bologna, Bari e Roma, questa settimana tocca a Padova, poi Milano, Firenze e Torino. A mio parere la conferenza è davvero un'ottima occasione per chi non ha ancora visto con i propri occhi (o toccato con mano, con preferite) le nuove major release dei due prodotti principali di MS. Io mi occuperò delle sessioni su Office, ovvero:

• Sviluppo con Office 2007 Client Side: come sfruttare il nuovo formato XML dei documenti per modificare o creare nuovi documenti senza avere Office installato - da applicazioni desktop o web - nonchè una panoramica sulla creazione di add-in, Action Pane e ribbon custom.
• Windows SharePoint Services 3.0: nuove funzionalità per le liste e document library (cestino, supporto per versioning esteso, supporto RSS,...), nuovi template (blog e wiki tanto per essere moderni, ma altro ancora), utilizzo masterpage a-là ASP.NET 2.0, webpart, utilizzo workflow built-in o utilizzo del nuovo SharePoint Designer per la definizione dei propri flussi.
• Office SharePoint Portal 2007: Excel Services (il motore di calcolo di Excel direttamente sul server + rendering via browser + esposizione del motore tramite web service!), Forms Services (praticamente le form InfoPath via browser!) e Business Data Catalog (indicizzazione e visualizzzione di record presi da un qualunque database o fonte di accesso ai dati esterna)

Insomma, mi sembra ci sia un bel po' di roba da vedere Per non parlare delle bellissime e impressionanti demo grafiche fatte con WPF per Vista! Dai, ci vediamo ad una delle prossime tappe allora...

Mi sono appena accorto che sull' Office Developer center di MSDN Online è stato finalmente pubblicato il mio articolo Tips and Tricks for Developing with Windows SharePoint Services. L'articolo raccoglie una serie di tecniche utili a tutti gli sviluppatori SharePoint, sia che sviluppino web part che client di altro tipo. L'articolo è indicato soprattutto a chi ha iniziato da poco a sperimentare con SharePoint, e non ha ancora appreso le best-practice e le tecniche per ottimizzare le query ai database di SharePoint, modificarne i contenuti e personalizzarne l'interfaccia. Molto di quello che viene descritto non è in realtà assolutamente innovativo, nel senso che si trova anche altrove. Però questo è forse il primo articolo che raccoglie in un unico documento tutte quelle tecniche e trucchetti che sono altrimenti sparsi in giro in post di blog e articoletti poco dettagliati, e che quindi bisogna sempre rielaborarsi in proprio se si vuole capirli fino in fondo e applicarli alle proprie situazioni. E' stato il frutto di un lavoro di ricerca e sviluppo durante i mesi che ho passato nel nostro ufficio a Santeramo, implementando una complessa soluzione di workflow per SharePoint. Spero che possa risparmiare a qualcun'altro ore di ricerche e prove infruttuose

P.S: gran parte delle tecniche descritte sono già state tradotte e pubblicate in italiano su www.ugisharepoint.it, ma non c'è ancora tutto. Ad esempio, credo che sia particolarmente interessante la tecnica per aggiungere comandi custom al menu contestuale di una document library, a seconda del tipo di documento. L'esempio potrebbe essere esteso molto facilmente per aggiungere comandi diversi a seconda dello stato del documento (salvato come stringa o numero in una colonna nascosta della doclib, o in un database separato di supporto) che è proprio quanto viene fatto dalle soluzioni personalizzate di workflow.

Durante la WPC, sul forum di www.ugisharepoint.it e via e-mail parecchie persone mi hanno chiesto se sia possibile usare ASP.NET 2.0 con SharePoint. La risposta è: un po'
Più precisamente, è possibile installare ASP.NET 2.0 sullo stesso server dove avete WSS2, a patto che abbiate installato il suo SP2. Un SP2 esiste anche per il Portal, ma in questo caso la convivenza con ASP.NET 2.0 non è supportata (il che equivale a dire: potrebbe installarsi apparentemente senza problemi, ma se poi qualcosa non funziona sono affari vostri). Quindi, se sviluppate solo per WSS potete installare senza problemi VS2005, altrimenti dovrete continuare con VS.NET 2003.

Ma la novità, e il vero motivo di questo blog, è un'altra. Anche installando WSS2+SP2+VSNET2005 non è possibile scrivere webpart o user control ASP.NET 2.0, ed utilizzarli direttamente in SharePoint. E' possibile scrivere solo applicazioni custom (pagine web, e ovviamente client di altro tipo). Alla WPC ho mostrato come usare SmartPart per hostare all'interno di SharePoint dei normali user control di ASP.NET. La versione 1.1 arriva a supportare solo gli user control di ASP.NET 1.x, ma una nuova versione con il supporto per ASP.NET 2.0 era già stata annunciata. Purtroppo non è arrivata in tempo per la WPC quindi non ho potuto dimostrarla in pratica, ma ho utilizzato la versione corrente con user control di ASP.NET 1.1. Il 20 novembre è stata finalmente rilasciata l'attesa nuova versione, chiamata Son of SmartPart. Potete leggere qui l'annuncio del suo creatore, Jan Tielens. In quest'altro post invece c'è una mini guida per creare uno user control con VS2005 ed ospitarlo all'interno di SharePoint con Son of SmartPart. Insomma, non sarà tutto perfettamente integrato come nelle prossime versioni di SharePoint (che dovrebbero essere rilasciate verso fine 2006, assieme ad Office 12), ma già così ci si semplifica veramente moltissimo la vita.

P.S: poichè SPS non può essere installato assieme ad ASP.NET 2.0, la stessa limitazione continua ad esistere anche installando Son of SmartPart.

Tra una settimana avrò il piacere di tornare a WPC come speaker, per il secondo anno. Questa volta parlerò di SharePoint, la mia passione tecno(software)logica dell'ultimo anno. Assieme ad ASP.NET 2.0 ovviamente, quello è ormai un punto fermo In particolare, ecco le mie sessioni:

TUT011-012 SharePoint Tutorial (lun 14 nov)

In questo tutorial - diviso in due parti - verranno presentati tutti i principali servizi offerti da Windows SharePoint Services per la condivisione e collaborazione su documenti e progetti, e le differenze con SharePoint Portal Server. Verranno anche fornite delle nozioni sull'architettura dei componenti di WSS e SPS, in modo da capire meglio come funzionano le cose dal punto di vista dello sviluppatore. Il tutorial comprenderà anche delle dimostrazioni di integrazione con i vari componenti di Office 2003, e sulle possibili alternative per personalizzare i propri siti creati con SharePoint, in modo da integrarli al meglio con altre parti della Intranet, e per renderli più funzionali ed usabili.

SVI123 Applicazioni personalizzate con SharePoint (mar 15 nov)

In questa sessione dedicata allo sviluppo con SharePoint verrà presentato ed utilizzato sia il suo modello ad oggetti che i suoi web service, per accedere in lettura e scrittura a gran parte delle sue risorse principali (siti, liste, file, utenti). Non verranno trascurati i problemi di sicurezza, che bisogna spesso affrontare lavorando con SharePoint. Le nozioni apprese potranno essere applicate per estendere le funzionalità di SharePoint e sviluppare delle verticalizzazioni, sia sotto forma di applicazioni ASP.NET che WinForms.

SVI125 Sviluppare Web Parts per Sharepoint e ASP.NET 2.0 (mar 15 nov)

Sviluppare Web Parts per Sharepoint e ASP.NET 2.0 Questa sessione è interamente dedicata allo sviluppo di Web Part personalizzate per SharePoint, argomento fondamentale per chiunque intenda sviluppare su questa piattaforma. Si parlerà delle diverse alternative per scrivere Web Part efficaci e senza troppo sforzo, e delle possibili modalità di deployment, anche relativamente alla sicurezza. Verrà inoltre presentato un breve confronto con il sistema di Web Part che è stato aggiunto in ASP.NET 2.0, parzialmente compatibile con il Service Pack 2 di Windows SharePoint Services 2, e sul quale si baserà invece completamente Windows SharePoint Services 3.

Diciamo che seguire tutte e tre le sessioni (la prima riempie 2 slot) sarebbe come seguire un mini corso intensivo su SharePoint, e di sicuro vi farete un'ottima idea sulle possibilità offerte dalla piattaforma attuale, out-of-the-box o che è possibile sviluppare in proprio. Nei giorni seguenti poi anche altri speaker parleranno di SharePoint, riguardo lo sviluppo di una soluzione per una Intranet aziendale, le novità del recente SP2, e l'integrazione con InfoPath 2003 (consulta l'agenda). La presenza piuttosto massiccia di sessioni su SharePoint è certamente misura del successo che questa tecnologia e i prodotti correlati (SharePoint Portal Server su tutti, ovviamente) stà avendo in Italia e in giro per il mondo.

Quello che posso dire già ora è che la versione attuale di SharePoint ha delle limitazioni, e se intendete utilizzarlo dovete pianificare di scrivere del software. Le sessioni presentate di sicuro aiutano a partire più velocemente. La prossima versione di SharePoint - presentata con alcune sessioni alla scorsa PDC - aggiungerà tantissime novità entusiasmanti (che cercherò di citare brevemente) sia per lo sviluppatore, che per l'amministratore, che per l'utente avanzato. Quando uscirà sono certo che SharePoint avrà ancora più successo di quello attuale...dovrà per forza essere così, ne sono sicuro al 100%, perchè da quello che si legge farà il suo compito il maniera eccezionale. E credo che qualunque sviluppatore ASP.NET dovrà conoscerlo, perlomeno a livello introduttivo...a meno che non si senta particolarmente masochista e voglia ricostruirsi da zero un sacco di servizi che SharePoint già offre, e che oggettivamente sono richiesti da molti siti Intranet, ma anche Internet. Del resto, dal momento che SharePoint v3 sarà costruito completamente su ASP.NET 2.0, sarà come imparare un'estensione di ASP.NET. Tutto questo per dire che SharePoint ha un futuro radioso a mio parere, e che è senz'altro una buona mossa cominciare a investirci già ora...perlomeno come conoscenza! Quindi...ci vediamo a WPC!

Ho appena ricevuto un pacchettino da Microsoft, contenente un simpatico orologio della Skintek con una pendrive USB da 128MB integrata nel cinturino. Mi è stato inviato come riconoscimento del mio lavoro di community sul sito www.ugisharepoint.it. Che dire, vedere che il proprio lavoro (fatto solo per passione, almeno per quanto riguarda quel sito e quello che state leggendo) viene apprezzato fa sicuramente tanto tanto piacere, e stimola a continuare a farlo! Microsoft regalerà altri gadget simili a questo nei prossimi mesi, a chi si dimostrerà attivo nella community. Quindi, se avete scritto una webpart interessate per SharePoint, avete scoperto dei trucchi o avete informazioni utili e derivanti dall'esperienza pratica sullo sviluppo di soluzioni personalizzate, l'installazione e configurazione, l'integrazione con Office, la personalizzazione grafica o altro ancora, scriveteci e proponete la vostra collaborazione! Non avete idee ma volete comunque contribuire? Anche tradurre articoli in inglese pubblicati su MSDN Online è un'opzione. Con qualche buon articolo potreste essere premiati!

Devo ringraziare l'MVP Gabriele Del Giovine per aver proposto il mio nome e quello di Romeo Pruno (ottimo collaboratore di www.ugisharepoint.it, grazie anche a lui!), e ad Alessandro Teglia di MS per aver ascoltato il suo suggerimento
P.S: ero senza orologio da un mese, quindi nessun regalo sarebbe potuto essere più azzeccato

Problema: docking di controlli .NET direttamente nella client area di Outlook con VSTO per Visual Studio 2005

Il file contenente il codice sorgente: HtmlViewModified.zip (256.37 KB)

Impegnato per conto di un cliente che sta ricrivendo una serie di applicazioni direttamente dentro Office System con .NET 2.0 e VS2005 – e Outlook 2003 in particolare - mi sono imbattuto in un “piccolissimo” problema non di poco conto. Benche’ con gli altri      prodotti di Office sia particolarmente semplice mostrare e usare form di ogni genere preparate in .NET, con Outlook 2003 ci siamo subito imbattuti in una serie di limiti che inizialmente sembravano insuperabili e decisamente antipatici. Per la precisione, a prima vista sembra che sia impossibile “dockare” le proprie form .NET all’interno dell’area client principale di lavoro di Outlook (l’area della inbox per intenderci) per scrivere applicazioni di produttivita’ utilizzando .NET, direttamente dentro Outlook. Pero’ ... con un po’ di fortuna e di intuito posso ora dire che l’empasse e’ durata relativamente poco. Infatti scaricato il preziosissimo esempio HtmlView disponibile sul sito di MSDN, che mostra come fare un po’ di report con del HTML plasmato via .NET, l’idea di ospitare le form (controlli windows form) .NET all’interno del HTML viewer (e’ il controllo del browser IE embedded dentro outlook) si e’ fatta subito strada. Devo ammettere che la mia bassissima conoscenza di HTML (che proprio non mi entra in testa - che ci volete fare) e’ stata, alla fine, la parte piu’ complessa del tutto. Per il resto il lavoro di inserimento delle form (controlli .NET) dentro Outlook e’ stato tutto in discesa e senza troppi problemi o intoppi. Descrivo brevemente per punti una serie di considerazioni e consigli da seguire per studiare il materiale allegato che mostra la soluzione del problema:

-          aggiornate la connection string nel .config che fa una piccola query sul db northwind per mostrare un diagramma a torte dentro un report embedded nella form schiacciando uno dei due pulsanti che troverete in testa alla vista dentro Outlook dopo aver lanciato l’applicazione e selezionata la cartella HtmlView figlia della cartella Inbox.

-          la classe BaseActiveXContainer (che ho copiato da qualche parte e modificato – l’autore mi perdoni per questo)  contiene del pratico codice per registrare i controlli .net come componenti COM

-          Generate tutte le volte un nuovo GUID per ogni nuovo controllo. Non usate la tecnica CCP (Cut Copy e Paste J - Copyright del mio amico Pierpaolo R.) con gli occhi bendati. Brutte sorprese vi aspettano.

-          Nel file AssemblyInfo.cs (aggiunto a manina perche’ in disuso con vs2005 – decideremo una best practice spero tra pochissimo ...) ho inserito degli attributi assembly wide per evitare problemi di security per caricare dll che non sopportano di essere chiamate da assembly “partially trusted”.Senza, molte LoadAssembly dinamiche rischiano di dare parecchi problemi.

[assembly: AllowPartiallyTrustedCallers]

[assembly: FileIOPermission(SecurityAction.RequestMinimum, Unrestricted = true)]

[assembly: SecurityPermission(SecurityAction.RequestMinimum, Execution = true)]

[assembly: RegistryPermission(SecurityAction.RequestMinimum, Unrestricted = true)]

[assembly: UIPermission(SecurityAction.RequestMinimum, Unrestricted = true)]

-          In testa alla classe HtmlViewContainer trovate una serie di attributi che vi permetteranno di riesporre attravers COM i vostri controlli .NET da “agganciare” dentro Office. La stessa classe contiene una serie di proprieta’ statiche che espongono globalmente nella applicazione i puntatori alle istanze di alcuni oggetti importanti di Outlook per interoperare con lo stesso con interfacce duali COM per supportare Automation.

-          Il file “.htm” del progetto allegato mostra come invocare metodi dell’oggetto ospitato dal HTML, che ospita il controllo .NET nella pagina, via jscript e automation.

-     Preparatevi mentalmente ad usare caspol o l'utility presente negli administrative tools per dare full trust ad eventuali DLL esterne bisognose di essere trattate in tal modo. Sappiate che il vostro assembly dentro la sandbox di Outlook e partially trusted. Vi consiglio di firmare digitalmente le vostre DLL e fare full trust su machine con le strong name degli assembly o direttamente un certificato buono. 

- altre ed eventuali ... prossimamente :) stay tuned

Una piccola schermata che mostra quello che si puo' fare dentro Outlook con .NET e VSTO per VS2005 completato in treno mentre tornavo a casa :). Nel codice trovate tutto quello che serve per far parlare il vostro controllo con Outlook dall'interno dell'explorer html di Outlook.

Enjoy !

Sto lavorando su dei proof of concept per Microsoft per Office Word ed Excel avanzatissimi. Spero di condividere al piu' presto con voi il materiale che sto producendo.

Giuseppe

L'altro giorno Alberto mi ha girato il link a questa pagina sul sito di Microsoft, dalla quale si possono scaricare ben 30 (e dico trenta!) nuovi template per Windows SharePoint Services! Le applicazioni fornite permettono di implementare siti SharePoint per la richiesta di ferie, la collaborazione su file di progetto, la condivisione di snippet per sviluppatori, la revisione di documenti legali, la gestione delle risorse aziendali, materiale di supporto per corsi di aggiornamento, e molto altro ancora. Non ho postato subito il link perchè volevo prima toccare con mano questi template - cosa che ho appena fatto...perlomeno con 10 dei 30.

Le applicazioni sono scaricabili come file ZIP, al cui interno si trovano due file .stp (il formato dei custom template di SP) che devono essere caricati all'interno della site template gallery di un sito WSS esistente. Fatto ciò è possibile creare dei sottositi basati su questi template. (Nota: per creare dei siti top-level è necessario caricare i template a livello di Central Administration Gallery, tramite il tool stsadm da riga di comando). I template sono due per ciascuna applicazione: il primo definisce tutte le document library, liste e la struttura della homepage specifica per l'applicazione, il secondo aggiunge una personalizzazione grafica del tutto. Devo dire che questa scelta mi ha un po' deluso :-( il fatto che l'applicazione sia impacchettata sotto forma di semplice custom template fa immediatamente capire che il tutto si basa solo sulle caratteristiche standard di SharePont, al limite integrato con Word e InfoPath per la compilazione di form complessi. Non ci sono webpart o pagine ASPX custom, che sono quasi sempre necessarie per l'implementazione di applicazioni reali, con workflow effettivi, controlli avanzati sull'imput immesso, gestione di relazioni complesse, ecc. Quindi non vi aspettate di trovare qualcosa che va oltre le personalizzazioni che si possono effettuare da browser e FrontPage 2003. In effetti io non le chiamerei "applicazioni", ma appunto "template" che forniscono una struttura (per quanto riguarda homepage, tipo di document library e liste da usare, con le varie colonne e viste custom) preconfigurata per molte situazioni e necessità tipiche (appunto quelle elencate sopra: gestione risorse umane, ferie, documenti di un progetto ecc.). Avrei anche preferito che il template fosse stato fornito sotto forma di Site Definition XML, in modo da semplificarne la traduzione in italiano e l'estensione con codice custom.

A parte questi svantaggi, devo dire che sono comunque impressionato dallo sforzo che Microsoft ha e stà tuttora compiendo per aiutare gli sviluppatori a implementare soluzioni efficaci con SharePoint. A differenza di qualche anno fa, non si può certo dire che oggi non si trovi materiale su SharePoint, anzi ci sono diverse community (tra cui la nostra, che stà crescendo bene ), forum e siti di supporto, e la stessa Microsoft pubblica parecchi articoli (anche molto avanzati) su MSDN. E' mia opinione che SharePoint non sia ancora un prodotto al massimo della maturità...bisogna ammettere che ha dei limiti che in alcune situazioni possono essere molto significativi, limiti che magari altri concorrenti più anziani nell'ambito delle applicazioni di collaboration hanno superato e risolto negli anni. In effetti, quando tengo un corso su SP cerco di sottolineare quanto più possibile il fatto che SharePoint non lo prenderei così com'è, ma lo intendo piuttosto come un'ottima piattaforma, un framework per svilupparci sopra, utilizzando da codice tutte le sue funzionalità di ricerca, gestione documenti, gestione permessi, ecc. ecc. Certamente Microsoft farà crescere molto SharePoint, e sono molto ottimista che la prossima versione risolverà molti dei probremi e mancanze che ci sono attualmente. Nel frattempo però si possono tranquillamente costruire soluzione anche complesse, se non si ha paura di sporcarsi le mani con un po' di codice. Alcuni concorrenti permettono più cose out-of-the-box, ma personalmente preferisco avere qualche cosa in meno di default, ma avere un ambiente e una tecnologia che conosco bene (.NET e VS.NET) per sviluppare estensioni e personalizzazioni, rispetto magari ad un linguaggio/tecnologia proprietaria e una community inesistente o di micro-nicchia.

Sto usando da alcuni giorni la webpart "SmartPart" di Jan Tielens (blog: http://weblogs.asp.net/jan/) che trovo straordinaria per sviluppare velocemente componenti web per sharepoint usando dei semplici ASCX. Ho aggiunto il supporto diretto ai menu attraverso un contratto software aggiuntivo a quello di base "IUserControl" per chi conoscesse gia' il componente in questione. Ho chiamato il nuovo contratto software "IUserControlMenuSupport" che implementa soltanto un metodo all'interno del quale e' possibile rilocare il codice per gestire i menu ed il relativo supporto degli eventi di ogni singolo menuitem. Ho fatto anche dei test con mozilla ed il risultato e' veramente straordinario. Ecco un piccolo esempio per aggiungere un menu parent ed un sotto menu con eventi lato client e lato server:

#region IUserControlMenuSupport Members

public void CreateWebPartMenu(Microsoft.SharePoint.WebPartPages.WebPart sender, Microsoft.SharePoint.WebPartPages.Menu webPartMenu)
{
  MenuItem mnuItemParent = new MenuItem("Parent Menu", "", "mnuItemParent");
  MenuItem mnuItemChild = new MenuItem("Child Menu with Client-Server handlers", "javascript:alert('Client Side Handler for Child ran!')");
  mnuItemChild.MenuID = "mnuItemChild";
  mnuItemChild.OnClick += new EventHandler( mnuItemChild_OnClick);
  mnuItemParent.MenuItems.Add( mnuItemChild);
  MenuItem mnuMinimize = webPartMenu.MenuItems.ItemFromID("MSOMenu_Minimize");
  mnuMinimize.Enabled = true;
  webPartMenu.MenuItems.Insert( 
     webPartMenu.MenuItems.IndexOf(webPartMenu.MenuItems.ItemFromID("MSOMenu_Minimize")) + 1
     , mnuItemParent
  );
  mnuItemParent.BeginSection = true;
  MenuItem mnuHelp = webPartMenu.MenuItems.ItemFromID("MSOMenu_Help");
  mnuHelp.BeginSection = true;
  mnuHelp.ClientEvent = "javascript:alert('No Help available')";
  mnuHelp.Enabled = true;
  mnuHelp.Visible = true;
}

ecco un piccolo sample grafico di come sembra alla fine:

Ho scritto una mail a Jan per capire come poter dare via le poche righe per fare questa cosa insieme al resto del suo lavoro.

Giuseppe

Sempre l'altro giorno in MS ho scoperto con Renato dei trucchetti semplici semplici, che però ci hanno fatto perdere qualche minuto perchè non ci era ancora mai capitato di dover fare queste cosette:

1. Se da un sito WSS linkato ad un Portal volete aggiungere un link alla pagina di ricerca avanzata del Portal (maari sotto il box di ricerca standard di WSS) l'Url che dovete usare è "/Search.aspx?tp=". Se non mettete il "?tp=" verrà caricata una pagina che mostra zero risultati, come risposta ad una richiesta di ricerca per una keyword nulla. Non è immediato scoprire questo Url perchè se andate nel Portal e cliccate l'icona con la lente di ingrandimento, per andare nella ricerca avanzata, l'Url sarà semplicemente /Search.aspx, e quindi uno giustamente si copierebbe quella. Il fatto è che quel link non fa un semplice redirect, ma esegue un javascript che rimepi alcuni campi nascosti e fa il submit della form HTML. La pagina Search.aspx poi legge i valori postati, e mostra o meno la UI di filtri avanzati in base a quei valori. Mettendo il "?tp=" potete caricarla tramite un semplice link diretto invece.
    
2. Per cambiare/aggiungere/rimuovere link dalla barra di navigazione standard dei siti WSS (quella in cima alla pagina, con i link Home, Documents and Lists, Create, Site Settings e Help) basta aprire la pagina con FrontPage 2003, e cliccare "Link Bar Properties" dal menu contestuale della barra. Quando inserite un nuovo link, il bottone OK della finestra di dialogo non verrà abilitato finchè non inserite un Url di destinazione. E se voleste solo inserire un elemento di separazione, come | ? In questo caso potete aggiungere un nuovo link il cui Url è "javascript:;" ovvero uno script che non fa nulla! All'inserimento del secondo separatore però scoprirete anche che non potete creare più link che puntino allo stesso Url. Poco male, perchè per ogni nuovo separatore basterà inserire uno spazio in più all'interno dello script, ovvero "javascript: ;", "javascript:  ;" ecc.
    
3. Per mostrare in ogni pagina del sito l'elenco delle Document Libraries disponibili potete aprire da FrontPage la pagina di default dove questo elenco è già disponibile, selezionare la Navigation Bar cliccandola (ad es. quella per le Doc Lib, ma sarebbe lo stesso se voleste copiare dappertutto quella per la liste) e copiare il codice HTML corrispondente, che dovrebbe essere uguale a quanto segue:
    
   <!--webbot bot="Navigation" S-Btn-Nobr="FALSE" S-Type="sequence" S-Rendering="html" S-Orientation="Vertical" B-Include-Home="FALSE" B-Include-Up="FALSE" U-Page="sid:1004" S-Bar-Pfx="<table border=0 cellpadding=4 cellspacing=0>" S-Bar-Sfx="</table>" S-Btn-Nml="<tr><td><table border=0 cellpadding=0 cellspacing=0><tr><td><img src='_layouts/images/blank.gif' ID='100' alt='Icon' border=0>&amp;nbsp;</td><td valign=top><a ID=onetleftnavbar#LABEL_ID# href='#URL#'>#LABEL#</td></tr></table></td></tr>" S-Target TAG="BODY" -->
    
   Il codice copiato può essere infine copiato in ciascuna pagina dove l'elenco debba essere disponibile. NB: come vedete all'interno di quel codice c'è del codice HTML che definisce come renderizzare la lista (il prefisso  e suffisso dell'elenco, e il template di ogni elemento), che potreste personalizzare ad esempio per mostrare gli elementi come elenco puntato o numerato.
    
4. Sempre riguardo la Navigation Bar che mostra l'elenco di librerie e liste, si nota subito che questo elenco non è ordinato in base al nome degli elementi, ma piuttosto l'ordine è cronologico (dalla prima all'ultima libreria creata). Questo può facilmente diventare un problema se l'elenco potrebbe includere parecchie decine o anche centinaia di liste (come in effetti era nel nostro caso). La soluzione che abbiamo seguito è stata di togliere completamente quella barra di navigazione, e inserire piuttosto una Data View che recuperasse i dati tramite il metodo GetListCollection del web service Lists di SharePoint (http://sito/_vti_bin/Lists.asmx), e che ordinasse i record in base al campo Title. Per mostrare solo le document library e non le liste semplici basta aggiungere un filtro ServerTemplate=101