1. Introduzione
In ASP.NET 2.0 è stata introdotta una nuova gerarchia di controlli denominati WebParts. Questi controlli permettono di personalizzare i siti web dando la possibilità all’utente finale di poter scegliere la posizione di questi controlli nella pagina.
Le WebParts riprendono in pieno la tecnologia già presente in Sharepoint Portal Server 2003 e Windows Sharepoint Services e sicuramente (almeno da fonti attentibili) andranno a sostituire lo sviluppo delle WebParts che attualmente è presente in questi due prodotti.
Se volete vedere già le WebParts in funzione potete navigare per esempio sul seguente sito:
http://it.my.msn.com/ ">My MSN.com



2. Le WebParts in Sharepoint
Sia Sharepoint Portal Server che Windows Sharepoint Services sono due piattaforme che si stanno diffondendo in questo ultimo periodo perché riescono a gestire in modo ottimo i portali, potendo creare dei sottoportali in modo semplice e immediato.
Ormai in internet c’è sempre più richiesta di creare non più siti ma portali dinamici, con molta attenzione ai contenuti e alla possibilità di personalizzare sia i contenuti che l’aspetto. In questo ambito queste tecnologie rispondono in modo ottimale con la possibilità di gestire delle librerie di documenti, ruoli ecc.

Non voglio soffermarmi troppo sull’utilità e le potenzialità di questi prodotti ma più che altro allo sviluppo che avviene attualmente delle WebParts.
Per sviluppare le WebParts in Sharepoint viene creato un progetto a parte all’interno di Visual Studio .NET 2003 e per far questo bisogna scaricare un template messo a disposizione da Microsoft e potete trovarlo qui: http://msdn.microsoft.com/library/en-us/odc_sp2003_ta/html/sharepoint_webparttemplates.asp ">WebParts Template

Per creare le WebParts si creano dei Custom Controls molto simili a quelli che si creano in ASP.NET con l’unica differenza che invece di ereditare dalla classe Control ereditiamo dalla classe astratta WebPart.
Oltre che come Custom Control le WebParts si possono sviluppare attraverso gli UserControl di ASP.NET, quindi all’interno del progetto si crea un nuovo UserControl e dalla classe base (che deve sempre ereditare da WebPart ) si può richiamare lo UserControl con il metodo LoadControl().
Una volta creato il progetto, dovrà essere istallato in Sharepoint, e per farlo nei migliori dei modi si crea un file Cabinet (.cab) che poi verrà istallato attraverso un Tool di Sharepoint. Ho spiegato molto rapidamente i passi che servono a creare le WebParts ma come potete capire non è proprio banale e il processo attualmente è molto macchinoso.

3. Costruzione delle WebParts in ASP.NET 2.0
Nella nuova versione di ASP.NET le WebParts non devono essere create come dei progetti come poco fa spiegato nel punto 2), ma sono nativamente supportate dale Framework 2.0 e quindi sono dei semplici Web Controls a disposizione nella ToolBox di Visual Studio .NET 2005. Infatti nella casella degli strumenti troviamo un’intera gruppo di oggetti per la gestione di queste WebParts.



Come potete notare ci sono diversi controlli e non ce n'è uno che si chiami WebPart.
Infatti WebPart è una classe astratta da cui bisogna ereditare, infatti per creare una singola WebPart abbiamo due modi diversi:

• Creare uno UserControl
• Creare un custom control che eredita dalla classe WebPart, (in pratica come avviene in SharePoint)

Immagino che vi starete già chiedendo ma perché devo creare uno UserControl o un Custom Control per creare una semplice WebPart?
Qua entra in gioco il discorso delle "Zone". Le Zone sono infatti aree apposite, dentro cui appariranno le WebParts, che permettono all'utente finale di personalizzare il sito e le pagine.
E'necessario infatti preventivamente definire le Zone. Un'istanza di WebPart può essere infatti inserita una una sola fra le seguenti tre zone:

• WebPartZone :in modalità di visualizzazione
• CatalagZone: nella modalità di scelta di catalogo
• EditorZone : nella modalità di modifica

Andiamo a creare le nostre prime WebParts:

Come prima cosa inserisco un WebPartManager:


<asp:WebPartManager ID="WebPartManager1" runat="server"></asp:WebPartManager>


Questo controllo è predisposto all’esecuzione e al rendering di tutte le WebParts e se ne può inserire al massimo uno solo per pagina. Senza di esso le WebParts non potrebbero funzionare.
Successivamente creo due WebPartZone, e all’interno di ognuna inserisco due semplici UserControl:




<table style="width: 100%; height: 100%" cellspacing="0" cellpadding="0" border="0">
<tr>
<td style="width: 328px" valign="top">
<asp:WebPartZone ID="WebPartZone1" runat="server">
<ZoneTemplate>
<uc3:title ID="Title1" runat="server" />
</ZoneTemplate>
</asp:WebPartZone>
</td>
<td valign="top">
<asp:WebPartZone ID="WebPartZone2" runat="server" Width="350px">
<ZoneTemplate>
<uc4:author ID="Author1" runat="server" />
</ZoneTemplate>
</asp:WebPartZone>
</td>
</tr>
</table>


Come potete vedere all’interno del controllo WebPartZone viene creata una ZoneTemplate dove all’interno vengono inseriti i controlli (le nostre webpart).

Manca la ciliegina sulla torta. Se gli oggetti/controlli che abbiamo inserito fino ad ora sono necessari e fondamentali per il buon funzionamento delle WebParts, ne manca uno altrettanto importante per la gestione della personalizzazione della pagina. Questo controllo si chiama WebPartManager.

Per esempio nel WebPartManager possiamo inserire una DropDownList con varie possibilità di gestione delle WebParts:
• Browse
• Design
• Catalog
• Edit
• Connect

Selezionando voci diverse nella DropDownList cambiamo anche lo stato attuale della pagina Web. Selezionando per esempio Design la pagina andrà in modalità progettazione e potremo finalmente trascinare con il Drag&Drop le WebParts da una zona all'altra personalizzando di fatto il contenuto e l'interfaccia della pagina.



Si può modificare lo stato della pagina anche tramite codice, in questo modo:


WebPartManager1.DisplayMode = WebPartManager.DesignDisplayMode;


La cosa sensazionale è che al successivo accesso l’utente ritroverà le WebParts posizionate come aveva scelto lui e tutto questo senza che il programmatore si debba preoccupare di dover gestire i Settings e le Zone.

E' possibile inoltre modificare le proprietà di ogni singola WebPart. Si può ottenere questo risultato inserendo un EditorZone. All'interno dell'EditorZone andremo ad aggiungere le seguenti WebParts:

• AppearanceEditorPart (serve a modificare l’altezza, la larghezza, la direzione(orizzontale o verticale) il titolo, il testo e il bordo)
• BehaviorEditorPart (serve a modificare i l'aspetto della WebPart per esempio pulsante di edit oppure pulsante di chiusura, ecc. o le immagini da visualizzare nel menù della WebPart)
• LayoutEditorPart (serve a modificare la zona e lo stato)
• PropertyGridEditorPart (se si vogliono inserire delle proprietà personalizzate)

Se volessimo dare all'utente la possibilità di modificare il titolo della nostra WebPart possiamo fare in questo modo:


<asp:EditorZone ID="EditorZone1" runat="server">
<ZoneTemplate>
<asp:AppearanceEditorPart runat="server" ID="AppearanceEditorPart1" />
<asp:LayoutEditorPart runat="server" ID="LayoutEditorPart1" />
</ZoneTemplate>
</asp:EditorZone>


Per visualizzare questi controlli dobbiamo impostare la visualzzazione a EditDisplayMode, poi cliccare sulla WebPart che vogliamo modificare e infine selezionare Edit:



In seguito apparirà questa pagina:



Qui sarà possibile modificare al volo le proprietà e l'aspetto della WebPart selezionata. Una volta terminate le modifiche per renderle attive basterà premere su "Apply".

E' possibile inoltre importare WebParts di terze parti, oppure creare un catalogo cioè un elenco di WebParts a disposizione dell'utente. Per applicazioni più avanzate c'è inoltre la possibilità di inserire WebParts collegate a livello di dati per rappresentare per esempio tabelle linkate in modalità Master/Detail.

Conclusioni
Quando ho saputo che in ASP.NET 2.0 c’erano le WebParts ero molto curioso e anche un po’ diffidente visto che già ci avevo lavorato con difficoltà in Sharepoint.
Dopo aver installato Visual Studio .NET 2005 e aver fatto alcuni tentativi sono rimasto subito sbalordito dalla semplicità e l'intuitività di questa nuova tecnologia.
Sicuramente sviluppare siti Web di successo in futuro sarà un'attività sempre più facile e forse sarà anche alla portata di molti programmatori non troppo esperti. Noi in compenso avremo più tempo per concentrarci sulla business logic delle applicazioni piuttosto che al design e alla gestione delle customizzazioni dell'utente, attività spesso noiosa e che richiede tempo.