Web Controls
• Abbiamo detto che vengono introdotti anche gli Eventi nella programmazione Web. Forse questo è il concetto più alieno allo sviluppatore web, ma anche quello più caratterizzante le pagine Asp.NET. Il programmatore in realtà vede l’applicazione come ospitata sul server, e la programma come se l’utente agisse direttamente sulla GUI che è stata disegnata. L’utente interagisce con gli elementi della pagina, e questi “sollevano eventi” sul server. Chiaramente questo è realizzato tramite delle normali chiamate http, insieme ad una tecnologia sottostante che realizza il permanere dello stato degli oggetti. Vediamo anche in questo caso un esempio.• Concettualmente si possono vedere gli eventi Asp.NET divisi per eventi di pagina ed eventi di controllo. Gli eventi di pagina sono quelli che vengono generati dalla pagina, ovvero non necessariamente sono dovuti ad un POST http (postback in gergo .NET), ma possono essere generati anche dallo stato della pagina, per esempio dall’inizializzazione, come nel caso di prima richiesta della pagina da parte di un utente. Eventi di questo tipo possono essere Page_Init e Page_Load. Si ricordi che tutti questi eventi attivano elaborazioni sul server. Per esempio il codice seguente:
Private void Page_Load
( object sender, System.EventArgs e)
{
if (!this.IsPostback)
{
CalendarioConcerti.SelectedDate=System.D
ateTime.Now();
}
}
viene eseguito al momento del caricamento della pagina da parte del server. Il codice aggiorna la data selezionata del controllo calendar CalendarioConcerti alla data odierna. Quello che verrà fatto in realtà sarà che il generatore di codice produrrà del codice Html (una serie di TABLE) tale da mostrare un calendario, con le caratteristiche impostate a design time, e con una cella evidenziata in corrispondenza della data scelta. Questo codice Html verrà inviato, insieme al resto della pagina, al client.
• Si noti come nel codice riportato si controlla che la pagina non sia in situazione di PostBack: if (!this.IsPostback) (una pagina è in postback quando viene ricaricata in seguito ad un input dell’utente: ad esempio un bottone è stato premuto o un evento è stato sollevato) infatti la pagina deve aggiornare il calendario solo alla prima composizione del codice Html.
Chi conosce la mancanza di stato del protocollo http potrebbe eccepire che invece ad ogni produzione della pagina tutte le impostazioni di stato della “vista” dovrebbero essere riesaminate. In effetti, qui entra in gioco un meccanismo molto potente di Asp.NET: il VIEWSTATE.
Lo stato della pagina, in generale lo stato dei controlli (ad esempio tutti i valori nelle TextBox) e quant’altro caratterizza la pagina in un dato momento, viene in realtà mantenuto in un elemento <INPUT> di tipo hidden in forma criptata.
Quindi, ad ogni POST, la pagina passa il suo stato al server, che elaborerà la richiesta, modificherà la pagina, e riprodurrà il codice Html atto a dare l’illusione che la pagina non sia stata richiesta e rigenerata, ma processata localmente.
A loro volta anche i controlli Web, oltre alla pagina, producono eventi. L’ordine di processo degli eventi, qualora vengano sollevati, è riportato in figura 6. Per chiarire quanto appena esposto, ed introdurre il concetto di CodeBehind, si veda il codice d’esempio, dalla pagina Converti.aspx (per chiarezza il codice è stato depurato dalle istruzioni di posizionamento e formattazione che VisualStudio.NET aveva aggiunto):
<%@ Page language=”c#”
Codebehind=”Converti.aspx.cs”
AutoEventWireup=”false”
Inherits=”testWA.Converti ” %>
<Html>
<body MS_POSITIONING=”GridLayout”>
<form id=”WebForm2”
method=”post” runat=”server”>
<asp:TextBox
id=”VALORE”
runat=”server”></asp:TextBox>
<asp:Button
id=”btnConverti
runat=”server”></asp:Button>
<asp:Label
id=”ValoreInEuro” runat=”server”>0
</asp:Label>
</form>
</body>
</Html>
in questo codice viene implementato un semplice convertitore Lira-Euro. Si veda come vengono definiti tre controlli: una TextBox dove verrà introdotto l’importo da convertire, un Button che avvierà la conversione, e una Label che mostrerà il risultato della conversione.
Sembrerebbe che non ci sia traccia però del codice che va ad eseguire la conversione vera e propria. In realtà, è presente l’istruzione Codebehind=”Converti.aspx.cs” che fa riferimento ad un file .cs (un file cioè che contiene un programma C#). Infatti il codice funzionale è del tutto separato dal codice aspx-Html, e viene inserito un file a parte, che verrà compilato come unità a sé stante. Questo nell’ottica di dividere la parte business dalla parte più propriamente WEB (un po’ come si fa ora mettendo il business layer in componenti ActiveX). L’uso del CodeBehind è il default in Visual Studio.NET, ma non è obbligatorio per scrivere pagine aspx.
Clicca qui per scaricare il listato di Converti.aspx.cs.
Facendo doppio click sul Button, Visual Studio crea la funzione di gestione dell’evento in modo automatico. A noi resta solo il compito di riempirla con il codice funzionale. Il resto del file (niente paura, è generato da Visual Studio) importa i namespaces necessari, crea istanze di oggetti relativi ai controlli, e soprattutto “dichiara” i gestori di evento, segnatamente
this.btnConverti.Click += new
System.EventHandler(this.btnConverti_Click
);
per quanto riguarda la pressione del bottone. La pagina html generata è quella in figura 7, dopo che è stata eseguita una conversione.
Non abbiamo ancora visto come entra in gioco il VIEWSTATE. Se si va ad esplorare il codice Html generato, si incontra:
<form name=”WebForm2” method=”post”
action=”WebForm2.aspx” id=”WebForm2”>
<input type=”hidden”
name=”_VIEWSTATE” value=”dDwtMTA4MzE0MjEwNTt0PDtsPG
k8MT47PjtsPHQ8O2w8aTw1Pjs+O2w8dDx
wPHA8bDxUZXh0Oz47bDwwLDAz4oKsOz
4+Oz47Oz47Pj47Pj47PumRsq4FSzhiCSXLZ
AI7zxeShNb9” />
In questa stringa (codificata Base-64) è presente lo stato dei controlli della pagina. Questo vorrà dire che lo sviluppatore non si dovrà preoccupare di farsi passare i valori correnti di tutti i controlli, e ripopolarli al momento della produzione della pagina. Si può anche vedere il VIEWSTATE come un “sacco” (statebag) dove è possibile inserire dati riguardanti lo stato della pagina, o della sessione. È possibile infatti utilizzare il VIEWSTATE per memorizzare valori non necessariamente inseriti in controlli, mediante l’utilizzo di coppie chiave-valore.
Per esempio il codice:
ViewState[“Modello”]= “Stratocaster”
memorizza nel VIEWSTATE un valore, “Stratocaster”, richiamabile al prossimo postback:
string ModelloDiChitarra= (string)
ViewState[“Modello”] Per essere sicuri che l’utente non possa modificare il campo _VIEWSTATE, si può abilitare una autenticazione MAC (Message Authentication Code) ovvero il server appende al _VIEWSTATE un hash combinato con una chiave crittografica di validazione. Ad ogni postback, il sistema può verificare quindi se il _VIEWSTATE è stato modificato. Per abilitare questo controllo, occorre includere :
<%@ Page EnableViewStateMac=”true” %>
all’inizio della pagina aspx.
Sempre nell’ottica dell’illusione della elaborazione locale, è possibile far sì che, qualora la pagina sia più grande dell’area visibile nel browser e l’utente abbia fatto uno scorrimento verso il basso (scrolling), la posizione sia mantenuta fra un post e l’altro. Questo risultato si ottiene impostando la proprietà SmartNavigation:
<%@ Page SmartNavigation=”true” %>
Fra i Web Controls più utili sono i controlli di Validazione. La validazione dell’input è una funzionalità comune alla grande maggioranza delle applicazioni Web, e ogni sviluppatore sa quanto può essere complesso e tedioso lo scrivere codice che la realizzi.
I Web Controls RequiredFieldValidator, RangeValidator, RegularExpressionValidator, CompareValidator e ValidationSummary servono a fornire un meccanismo comune e facilmente utilizzabile allo sviluppatore. Essi producono sia codice JavaScript per effettuare parte della validazione sul client, che codice per la validazione sul server. Vediamo un esempio. In figura 8 si vede come abbiamo aggiunto al nostro convertitore un RequiredFieldValidator, e di questo abbiamo impostato alcune proprietà. Il codice generato da Visual Studio.NET (e ripulito dalla formattazione) è:
<asp:RequiredFieldValidator
id=”RequiredFieldValidator1”
runat=”server”
ErrorMessage=”Inserire un valore!”
ControlToValidate=”VALORE”>
</asp:RequiredFieldValidator>
dobbiamo cioè specificare quale controllo validare, e possiamo specificare il messaggio d’errore. In figura 9 vediamo il messaggio d’errore in seguito ad un tentativo di premere il bottone lasciando vuota la TextBox.
Questo articolo è stato solo una panoramica sulle caratteristiche della nuova tecnologia Asp.NET. In uno dei prossimi articoli esamineremo più a fondo la creazione di controlli da parte dell’utente, ovvero la creazione di User Controls e Custom Controls.




Ancora nessun commento.