InfoPath Browser Forms in un sito SharePoint aka come fare l’attach di una Master Page
Sarò breve. He he ... forse dal titolo non si direbbe :-)
Provo almeno ad essere schematico.
Esigenza: erogare funzionalità di data entry tramite form infopath renderizzate dal browser (via FormsServices) mantenendo, però, l’aspetto del sito SharePoint. In altre parole, inserire il “content” che IPFS ci mette a disposizione in una pagina che usi la master page del sito SharePoint in questione.
Soluzioni: ce ne sono un po’.
Una, ad esempio, che cito giusto per dovere di cronaca, è quella di usare una PageViewerWebPart che punti all’URL delle pagine aspx di FormsServices. Ammesso e non concesso che utilizzare un IFrame sia realmente necessario :-)
In alternativa (molto meglio a mio parere) si può usare il controllo XmlFormView (Microsoft.Office.InfoPath.Server.Controls.XmlFormView), che abbiamo a disposizione “aggratis”, giacchè alla fine la licenza di IPFS l’abbiamo pagata. E da buon ligure questo è già un motivo sufficiente.
XmlFormView è una web part piuttosto interessante - peraltro utilizzata anche dalle pagine native di IPFS - e dall’uso decisamente immediato. Talmente tanto da rendere possibile la creazione di interfacce semplici anche solamente mediante browser.
Il procedimento è abbastanza lineare, e potrebbe essere questo:
· Aggiunta del controllo suddetto all’elenco di SafeControls per la web application di interesse (un punto in più se decidete di fattorizzare la cosa in ottica di deploy ed inserite la modifica nel manifest di una solution ... anzi no ... due punti)
· Provisioning della web part sulla site collection (Site Settings -> Web Parts -> New -> Selezionare XmlFormView e cliccare su Populate Gallery)
· Si crea una document library dedicata alla memorizzazione delle pagine di data entry (nulla vieta di usarne una preesistente, se non una pura questione di separazione logica dei contenuti)
· Le si associa il content type WebPartPage (non necessario se in fase di creazione della document library abbiamo scelto WebPartPage come template per i nuovi documenti)
· Si crea ... indovinate ? … una WebPartPage :-)
· Si inserisce XmlFormView nella zona che maggiormente ci aggrada
· Si completa la configurazione della web part
Yep. Ma ci sono comunque un paio di considerazioni da tenere in conto.
Una, che vale un po’ sempre, è che ciò che facciamo via browser può arrivare ad un punto di non ritorno, quando le funzionalità out-of-the-box non sono sufficienti (giusto per anticipare la risposta alla domanda “ma come faccio a passare dei parametri alla form ?”).
Questo fa da contrappeso agli (indubbi) vantaggi che ci sono, uno su tutti la possibilità di delegare le operazioni ad un “power user”. Basta saperlo e scegliere di conseguenza.
L’altra considerazione che, invece, prescinde un po’ di più dalle prospettive è legata alle performance pure e semplici.
Una pagina creata come item di una document library è memorizzata in DB. Il che implica un peso non sempre trascurabile per il sistema, che si trova a non poter riutilizzare il codice compilato della pagina ASPX (la stessa cosa che succede per le famose pagine unghosted/customized che si ottengono, ad esempio, modificando un’istanza di pagina con SharePoint Designer).
Logicamente, se si riescono a fattorizzare le funzionalità di una “pagina host con master page”, la strada più conveniente è quella di definire un page template, creando poi istanze della pagina host nei siti di interesse.
Non è così complesso come può sembrare, basta giocare un po’ con le feature ... oops ... Feature di SharePoint 2007.
Ecco qualche riga di codice.
La pagina ASPX, innanzitutto, almeno le “parti salienti”:
<%@ Page Inherits="Microsoft.SharePoint.WebPartPages.WebPartPage" MasterPageFile="~masterurl/default.master" .... />
<%@ Register Assembly="Microsoft.Office.InfoPath.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.Office.InfoPath.Server.Controls" TagPrefix="ip" %>
<%@ Register Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.WebPartPages" TagPrefix="wss" %>
<asp:Content ID="cntMain" runat="server" ContentPlaceHolderID="PlaceHolderMain">
<div>
<ip:XmlFormView ID="frmViewer" runat="server" Height="100%" Width="100%" … />
</div>
</asp:Content>
Manca qualche “piccolo pezzo”, per dirne un il path del form template (o del documento InfoPath). Vi rimando alla documentazione del controllo XmlFormView su MSDN per ogni informazione riguardante i parametri necessari a mostrare documenti InfoPath al suo interno.
Scrivo qui, invece, l’element manifest di una feature che effettua, una volta attivata, il provisioning della page instance:
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Module Path="PageTemplatePathOnFileSystem" Url=”PageInstanceUrl”>
<File Url="FormViewer.aspx" Type="Ghostable"></File>
</Module>
</Elements>
L’attributo Path indica il percorso, sul file system del front-end e relativo alla directory della feature, a partire dal quale verrà copiato il file FormViewer.aspx.
L’attributo URL specifica, invece, il suo percorso relativo alla root del sito web sul quale la feature viene attivata.
Con un po’ di lavoro in più (non molto, alla fine) è infine possibile “parametrizzare” la pagina, valorizzando quindi le proprietà del controllo XmlFormView in maniera dinamica ed ottenendo, alla fine dei giochi, una pagina generica e riutilizzabile.
Voila. Enjoy InfoPath :-)