Lo sviluppo di Web Part all'interno di un'architettura basata su Windows SharePoint Services 3.0 è sicuramente l'attività di personalizzazione più comune, in quanto permette l'aggiunta di funzionalità custom che possono essere poste in una qualsiasi delle pagine web facenti parte dell'interfaccia con cui l'utente finale ha a che fare.
Molto importante risulta quindi il meccanismo con cui queste personalizzazioni vengono installate all'interno di SharePoint, poiché esistono varie tecniche, ciascuna con pro e contro, che devono essere comunque intraprese per permettere l'effettivo utilizzo dei nostri componenti custom all'interno dei siti SharePoint. Alcune di queste tecniche vedono anche l'utilizzo del concetto di solution.
Installazione manuale di una web part
La prima tecnica con cui avete la possibilità di utilizzare le vostre web part personalizzate all'interno di siti SharePoint è quella di inserire la definizione di queste ultime manualmente.
Una volta che l'assembly contenente la web part è stato inserito all'interno della GAC del server (quindi correttamente segnato tramite strong name), l'installazione può essere facilmente completata tramite due semplici operazioni:
- aggiunta di un nuovo elemento di tipo "SafeControl" all'interno del file web.config, proprio della site collection in cui avete deciso di effettuare il deploy del componente personalizzato;
- generazione del modulo web part tramite l'interfaccia grafica di SharePoint.
La prima delle due operazioni consiste nell'aggiungere la seguente configurazione all'interno dell'elemento "SafeControls" presente nel file web.config della site collection in cui vogliamo utilizzare la web part.
<SafeControl Assembly="WebPartDeploymentWithFeature, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7e95914ad1d744b2" Namespace="WebPartDeploymentWithFeature" TypeName="*" Safe="True" />
Come è possibile vedere, l'elemento definisce il nome dell'assembly che deve essere considerato come "sicuro" dal motore di SharePoint e il namespace al di sotto del quale sono state dichiarate tutte le web part che abbiamo sviluppato. Nel caso in cui avessimo più web part, definite in namespace differenti, dovremmo aggiungere un elemento di tipo "SafeControl" per ogni namespace.
La seconda operazione deve essere eseguita tramite interfaccia grafica. Seguendo il percorso: "Site Settings > Galleries > Web Parts" a partire dal sito di root della site collection, abbiamo la possibilità di visualizzare tutte le web part che sono correntemente installate all'interno dell'architettura SharePoint e di aggiungerne delle altre, facendoci generare in automatico dal sistema il modulo relativo alle web part presenti all'interno del namespace che abbiamo definito precedentemente. Facendo click sul pulsante "New" possiamo infatti vedere l'elenco delle web part che possiamo aggiungere in funzione degli assembly segnati come sicuri all'interno del web.config, così da poter selezionare la nostra web part e fare click sul pulsante "Populate gallery" (come visibile in figura 1).
Figura 1 - Maschera di SharePoint per l'aggiunta di web part
In questo modo il motore di SharePoint è in grado di generare in automatico un file .webpart contenente la relativa definizione, salvarselo all'interno delle sue strutture dati e rendere disponibile il componente all'interno di tutti i sottositi della site collection corrente.
Questa tecnica appare sicuramente molto veloce e ottima durante tutto il periodo di sviluppo e test della web part. Come metodo di deployment però, è veramente pessimo in quanto all'interno delle interfacce utente, la web part viene presentata direttamente con il nome della classe, senza poter quindi aver un nome più user-friendly o addirittura localizzato in base alla lingua di installazione; inoltre non è possibile applicare tante altre piccole configurazioni grafiche e non, che rendono il componente completo e re-distribuibile. Inoltre, a fronte di attività amministrative di vario tipo, è molto probabile che le web part installate in questo modo raggiungano uno stato di errore o di generale corruzione.
Installazione di web part tramite una feature
Come abbiamo visto, per installare le web part all'interno di siti o intere site collection esistono procedure da effettuare manualmente, sicuramente molto veloci, ma che si allontanano da quel concetto di flessibilità che invece risulta essere proprio della piattaforma di collaborazione. Infatti, per fare un banale esempio, a fronte dell'installazione di una web part su una farm avente più server di front-end, lo sviluppatore deve effettuare a mano l'installazione del componente una volta per ogni server. La presenza delle feature all'interno di SharePoint facilita notevolmente il deployment di web part e la sua relativa gestione.
Esistono due metodi differenti per installare una web part all'interno di una farm SharePoint utilizzando le feature, lasciando perdere lo sviluppo del componente vero e proprio, almeno per ora. Questi si differenziano solamente sul contesto in cui la feature può essere installata, se per singoli siti o se per un'intera site collection.
Attenzione: Questo articolo contiene un allegato.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Installare le Web App site extension tramite una pipeline di Azure DevOps
Sostituire la GitHub Action di login su private registry
Triggerare una pipeline su un altro repository di Azure DevOps
Eseguire script pre e post esecuzione di un workflow di GitHub
Usare una container image come runner di GitHub Actions
Creare un webhook in Azure DevOps
Disabilitare automaticamente un workflow di GitHub (parte 2)
Visualizzare le change sul plan di Terraform tramite le GitHub Actions
Ottenere un token di accesso per una GitHub App
Code scanning e advanced security con Azure DevOps
Creare una custom property in GitHub
Rinnovare il token di una GitHub App durante l'esecuzione di un workflow