[GREENPOINT#2] gp_RegExpField
Abbiamo appena reso disponibile su GreenPoint una nuova release del progetto (1.0.1.0) che contiene due custom field type, anch'essi rielaborazione (più che altro cosmetica) del materiale della SharePoint Conference 2008: gp_RegExpField e gp_CoordinatesField.
Per una disquisizione sullo sviluppo di custom field per SharePoint vi rimando ad MSDN, qui.
Mi soffermo, invece, molto rapidamente sul primo dei due esempi disponibili in GreenPoint (inutile dire che la parte due è in arrivo ASAP :-P)
gp_RegExpField
Esempio classico, che più classico non si può.
Definisce un field di tipo text (derivato da SPFieldText, dal punto di vista della gerarchia di classi) che aggiunge alle funzionaliltà di base il supporto alla validazione parametrica, affidata ad una regular expression.
Se ne trovano molti, probabilmente perchè la realizzazione è semplice e l'utilizzabilità è discreta (al di là del fatto che, poi, le regular expressions piacciano o siano parte del bagaglio delle nostre competenze).
A fronte del deploy del solution package e a seguito dell'aggiunta di una colonna (su una lista o come site column a livello di web), tra le opzioni a disposizione c'è anche:
In fase di selezione del tipo di dato che deve essere configurato, SharePoint interroga la field definition per verificare:
- L'esistenza di un field editor control (al quale verrebbe delegato il rendering della sezione di pagina utilizzata per le proprietà specifiche di ogni campo)
- L'esistenza di field properties (aka metadata properties) per le quali è possibile fornire un rendering out-of-the-box che non faccia affidamento su controlli custom
Nel caso di gp_RegExpField, il sistema estrae la definizione delle property custom è propone all'utente l'area di selezione seguente:
Non rimane che impostare il campo Regular Expression Pattern (e qui... vai di copia e incolla :-P) ed un campo atto a contenere il messaggio di errore che sarà visualizzato in caso di mismatch.
Voila, almeno relativamente alla configurazione della colonna.
In fase di editing, l'utente avrà di fronte un campo del tutto simile a quello di testo standard (non sono state effettuate personalizzazioni al di fuori della logica di validazione):
Ma in seguito all'inserimento di un valore "invalido", il salvataggio è inibito:
Dal punto di vista del funzionamento interno, qui trovate i sorgenti.
Il punto di intervento, in questo caso, è stato davvero minimo: per definire una logica di validazione è sufficiente effettuare l'override del metodo GetValidatedString, che riceve in input un generico object contenente il dato da validare e deve restituire la versione serializzata dello stesso (senza aggiunte relative alla logica di rendering, che nei custom field è delegata ad altri componenti).
Insomma, pochissimo sforzo e, tutto sommato, un buono spettro di utilizzo :-P