PARTE 2 – CAPITOLO 3 – Server Control
I Server Control sono classi di ASP.NET create con lo scopo di mappare I rispettivi elementi visuali di una Web Form. Tutti i Server Control derivano dalla classe Control da cui ereditano metodi e proprietà di base come ClientID (per trovare l’ID univoco assegnato lato server), i controlli sul ViewState, sul data binding e il metodo FindControl per ricercare elementi. I Server Control più importanti sono HTML server controls, Web controls, Rich controls e Validation controls. Gli HTML server controls servono per mappare ed estendere i classici elementi HTML, i Web controls (come abbiamo visto nel capitolo precedente) dispongono delle stesse potenzialità delle HTML Server Controls offrendo allo stesso tempo molti controlli in aggiuntivi, i Rich controls servono per gestire controlli avanzati (ad esempio: Calendar) mentre i Validation controls servono per validare gli input presenti su una pagina. Ci sono altri controlli più specifici come Data controls, Navigator controls, Login controls, Web parts controls, AJAX controls, Mobile controls e molti altri ancora. Alcuni di questi verranno ripresi in seguito mentre altri vanno oltre lo scopo di questa mini-guida. HTML (e nemmeno ASP.NET) offrono soluzioni per impostare il focus di una pagina (definire dove si trova il primo controllo attivo dopo il caricamento della pagina). Fortunatamente all’interno della dichiarazione del form è possibile impostare la proprietà DefaultFocus con l’id dell’oggetto desiderato. ASP.NET si preoccuperà di aggiungere una porzione di codice Javascript capace di soddisfare questa richiesta. I controlli offrono anche la proprietà TabIndex che indica, con una numerazione crescente, come si sposterà il focus all’interno dei controlli sulla pagina quando viene premuto il tasto Tab.
HTML Server Control
Questo tipo di oggetti possiedono i metodi particolari innerText e innerHtml per modificare programmaticamente il contenuto di un controllo. La differenza tra i due comandi è che il primo convertirà i caratteri html in modo da mostrarli a video mentre il secondo inietta puro html all’interno del controllo. Tutti i controlli di questa classe espongono i metodi ServerClick e ServerChange per tentare di colmare il gap che li separa dai più completi Web Controls. La classe HTMLInputControl è la base da cui derivano tutti gli elementi input presenti in una form e che condividono gli attributi type e value. Naturalmente (come per qualsiasi altra classe) tutti questi oggetti possono essere creati programmaticamente, indicando la classe corretta che li definisca.
WEB CONTROLS
Che cosa sia un Web Control lo abbiamo spiegato nel precedente capitolo e lo riproponiamo velocemente prima di proseguire: si tratta di un controllo customizzato creato con lo scopo di mappare uno o più oggetti presenti nel vocabolario dell’html ed estenderne le potenzialità.
I Web Control si dichiarano con il rispettivo ClassName (ad esempio ”) invece che con i classici tag html. Altre differenze sono date dal contenuto, non più memorizzato nell’attributo Value ma in Text e dagli stili, con alcune caratteristiche definibili direttamente (ad esempio le dimensioni) lasciando comunque la possibilità di associare una classe CSS. Per quanto riguarda le dichiarazioni esplicite è necessario indicare l’unità di misura (ad esempio Width=”190px”).
A differenza dei classici HTML Server Control, questo nuovo tipo di controlli può essere definito solamente all’interno di un form HTML dichiarato con l’opzione ‘runat=”server”’.
Come già accennato precedentemente, i Web Control di tipo input possono avere associata una proprietà per impostare il focus (grazie all’uso di una funzione Javascript).
La gestione degli eventi è simile a quanto visto per gli HTML Server Control: l’evento ‘OnClick’ va a sostituire ‘ServerClick’ e, al posto di ‘ServerChange’ si introduce una personalizzazione con ‘OnXXXChange’ (dove XXX è lo specifico nome del controllo).
Tutti i Web Control supportano l’AutoPostback.
Una delle ultime innovazioni nel mondo dei Web Control riguarda le ListBox: si tratta di controlli che generano liste di oggetti (ad esempio CheckBox) tipicamente con una dichiarazione di Bind o con impostazioni hard-coded.
VALIDAZIONE
Per una corretta e sicura gestione dell’applicazione è necessario validare ogni tipo di input ricevuto. Pensando soprattutto ad applicazioni pratiche quali, ad esempio, un modulo di contatti, viene istintivo pensare che sia sufficiente un controllo Client-Side (svolto cioè mediante funzioni Javascript direttamente sul browser dell’utente) per assicurarsi che i dati siano corretti. Questo è uno degli errori più grossi che si possono compiere durante lo sviluppo di una applicazione: il controllo Client-Side è utilissimo perché permette di informare con un riscontro immediato l’utente circa dati inseriti in modo errato (evitando il Postback) ma è assolutamente necessario che ogni controllo svolto in questa maniera abbia un corrispondente Server-Side. I controlli effettuati grazie a funzioni Javascript sono infatti facilmente aggirabili se non addirittura eliminabili (disabilitando tale funzione dalle proprietà del browser). Dopo che i dati hanno superato (in qualsiasi modo) i controlli lato Client sarà il Server ad effettuare il controllo decisivo e, nel caso di errori, a prendere provvedimenti.
Scrivere controlli di validazione può rapidamente diventare un operazione noiosa visto che molti di tali controlli si ripetono in modo identico in diverse applicazioni ed addirittura all’interno di uno stesso progetto (un esempio su tutti: la validazione di un indirizzo e-mail). Fortunatamente ASP.NET viene in soccorso dei programmatori offrendo un set di validatori Client e/o Server preconfezionati che andranno solamente personalizzati. Di seguito un elenco con una breve descrizione per ogni elemento.
” è il più classico dei validatori e serve per controllare che un campo di testo non sia vuoto o, impostando a dovere la proprietà InitialValue, uguale ad un valore di default. In aggiunta questo controllo invalida un campo di testo in cui siano contenuti solo spazi bianchi.
”controlla che il dato inserito dall’utente cada all’interno di un range ben definito. Spesso si usa questo controllo in concomitanza di numeri o date. È possibile definire il tipo (Type) di dato e gli estremi del range (MinimumValue e Maximum Value).
” effettua un confronto tra il contenuto di un campo di testo e quello di un altro campo di testo o un valore prefissato. È possibile impostare uno dei classici operatori quali ‘maggiore’, ‘minore’, ‘uguale’, ‘diverso’ ecc..
” serve per testare l’aderenza di un input con un pattern definito dal programmatore.
” permette di definire controlli personalizzati. A differenza dei controlli precedenti, che vengono eseguiti automaticamente lato Client e lato Server, con il Custom Validator è necessario specificare manualmente la funzione di validazione Client-Side (ClientValidationFuncion) e/o quella lato Server (OnServerValidate). Sarà ovviamente necessario definire e programmare tali funzioni in modo da personalizzare il controllo. Le funzioni accetteranno in ingresso un sender e un argument e restituiranno True o False impostando lo stato di args.IsValid.
Ogni validatore possiede la proprietà Text in cui inserire il testo da mostrare all’utente in caso di errore di validazione (tipicamente un asterisco) e, in aggiunta, una proprietà ErrorMessage che contiene una spiegazione dell’errore da mostrare in un eventuale Validation Summary.
” è un raggruppamento logico all’interno della pagina all’interno del quale racchiudere i messaggi di errore di un ValidationGroup. Il ValidationGroup è un a proprietà definibile in ogni validatore che permette di raggruppare i validatori e gestirli in modo separato (per esempio associandoli a due bottoni diversi).
Gli elementi di tipo Button hanno la proprietà CausesValidation impostata a True di default. È possibile cambiare questo comportamento ed indicare solo un sottoinsieme (ValidationGroup) di validatori da far scattare.
I validatori possono essere abilitati o disabilitati programmaticamente agendo sulla proprietà Enabled. È possibile inoltre decidere se assegnare uno spazio fisso all’eventuale testo di errore (Display=”Static”) o calcolare questo spazio dinamicamente (Dispplay=”Dynamic”).
Per controllare (lato Server) che un controllo sia valido si può richiamare il rispettivo metodo IsValid mentre con Page.IsValid posso sapere se tutti i validatori che sono scattati hanno avuto esito positivo.
Quando si definisce una nuova classe è possibile preporre alla sua definizione l’attributo [ValidationProperty(“nome-proprietà”)] che indicherà la proprietà da validare.
Naturalmente ogni controllo di valutazione ha i propri metodi/proprietà.
Ogni controllo può avere associati più controlli di validazione diversi.
CUSTOM SERVER CONTROL
Quello del Custom Server Control è in realtà un concetto che in parte è già stato presentato.
Il Custom Server Control è un controllo lato Server che genera HTML ed eventi collegati in modo programmatico (ad esempio il Calendar). Questo tipo di controlli ereditano o dalla classe Control o da WebControls.WebControl (che fornisce qualche opzioni in più, soprattutto sulla personalizzazione grafica).
Il metodo utilizzato per generare il codice del controllo è Render. Non è possibile generare al suo interno Web Control in quanto supporta in output solo codice HTML puro.
ASP.NET, grazie alle potenzialità del Framework, può confrontare lo User-Agent del Client-Browser con quelli mappati per capire quali sono le funzionalità supportate e decidere, per esempio, con che Doctype e HTML-Version formattare il codice. In realtà non è un controllo sicuro perché un browser può supportare Javascript ma l’utente può averlo disabilitato. Si possono quindi intraprendere due strade: o si fanno dei test a basso livello o si deve tollerare un margine di errore. È possibile definire degli alias per identificare più velocemente un browser (sempre grazie allo User-Agent).
I Composite Controls sono quelli che generano html ricco ed indentato. Si rende necessario l’override del metodo CreateChildControls.
