Corso ASP.NET: quarta puntata

Esempio funzionante | Sorgente | Scarica il sorgente (zip)

La vera novità di ASP.NET è la possibilità di utilizzare particolari tag che diventano controlli dotati di proprietà ed eventi.

Sono i Server Controls, una serie di controlli posti all’interno della pagina che consentono l’uso di un modello di programmazione ad oggetti.

Sono di due tipi:

• Html Server Controls
• Web Form Server Controls

Gli Html Server Controls sono il modo più veloce per costruire controlli lato server in ASP.NET. Sono dei controlli in corrispondenza 1:1 con i tag Html: è sufficiente aggiungere ad un normale tag l’attributo runat=”server” per promuoverlo a Html Server Control.

I tag Html che traggono il maggior beneficio dalla promozione a Html Server Controls sono quelli che hanno in qualche modo a che fare con le form (i campi e i bottoni di submit), anche se ogni tag Html può diventare un Html Server Control.

L’oggetto HtmlAnchor, ad esempio, consente di intervenire via codice sulle proprietà del tag <a> in due modi:

• per definire un link “da seguire”
• per gestire eventi con le form di tipo postback

Vediamolo con un esempio

L’oggetto HtmlAnchor

Provate [nuova finestra] l’esempio online, visualizzate il codice sorgente oppure scaricatelo per vedere la pagina sulla vostra macchina.

La pagina consente due possibilità:

• cliccare su un link: viene aperta una finestra in cui si carica l’Homepage di FucinaWeb.com
• scatenare un evento in postback: cliccando viene eseguito il submit di una form di tipo PostBack

Nel secondo caso, la situazione che si presenta dopo il click è la seguente:

Il tag che genera il primo dei link è:

Nell’evento Page_Load della pagina sono successivamente definiti il link, il title (che compare posizionando il mouse sopra il link) e il target come proprietà dell’oggetto:

Invece di “scomodare” l’evento Page_Load avremmo potuto scrivere direttamente:

<a id="link" href="https://fucinaweb.com" title="La pagina di ingresso di FucinaWeb.com" target="_blank" runat="server">Home Page di FucinaWeb.com</a>

L’evento Page_Load ci consente però di chiarire che “link” è davvero un oggetto con le sue proprietà a cui è possibile assegnare un valore.

La seconda parte dell’esempio è composta da un link che in realtà è responsabile del submit di una form.

Il codice del controllo è:

L’unica differenza rispetto al link precedente è data dalla presenza di un evento: OnServerClick che è scatenato al click dell’utente sul collegamento.

Va anche notata la presenza di una form di tipo PostBack all’interno della pagina.

Quello che si verifica è che:

• l’utente preme il link
• viene effettuato il submit della form di tipo PostBack
• al secondo caricamento della pagina è eseguito il codice presente nella funzione linkevento_Click

Il codice della funzione linkevento_Click è particolarmente semplice:

Ma come è possibile che premendo un link venga inviata una form?

Quando il server ASP.NET riconosce un controllo con runat=”server” lo traduce in codice html e script che il client è in grado di eseguire.

In questo caso, la presenza dell’evento OnServerClick fa si che il server ASP.NET generi del codice Javascript che viene eseguito al click dell’utente sul link.

Questo codice esegue semplicemente il submit della form di tipo PostBack.

Se guardiamo il codice sorgente della pagina che è inviata dal server al browser, ci accorgiamo che ha una forma del tipo:

Anche il codice del link ha una forma leggermente diversa:

È facile intuire che al click del link si scatena un evento Javascript lato client che provoca a sua volta il submit della form.

È chiaro una volta di più come ASP.NET consenta al programmatore di usare oggetti, proprietà ed eventi quando in realtà nulla cambia per il browser, che riceve codice Html puro e codice Javascript.

Conclusione

Gli Html Server Controls sono dei semplici controlli Html che per lo sviluppatore si trasformano in oggetti dotati di proprietà ed eventi. Sono un comodo aiuto per gestire via codice il comportamento dei tag e simulare gli ambienti di programmazione tradizionale. Il server ASP.NET si preoccupa di riconoscere i controlli all’interno della pagina e di restituire al browser del puro codice Html.

Sorgenti: viewState.aspx

Scarica i sorgenti: aspnet03.zip

Articolo a cui si riferisce il codice: ASP.NET: Server Roundtrip e ViewState

ASP.NET (chiamato in una prima versione ASP+) è più di un semplice upgrade di Active Server Pages, la soluzione Microsoft per la realizzazione di siti dinamici.

Chi ha esperienza di sviluppo con questa tecnologia ne ha già ben chiaro i vantaggi e le lacune. A fronte di una elevata semplicità nella stesura del codice (un programmatore Visual Basic è produttivo con ASP dopo pochi giorni), esiste una difficoltà quasi cronica nella correzione degli errori (debugging). I documenti ASP, inoltre, sono tutt’altro che prestazionali, poiché richiedono l’esecuzione di un interprete di comando ad ogni accesso.

Microsoft ha lavorato tre anni per questa nuova versione, riscrivendo completamente il codice originario di ASP: il risultato è una piattaforma di lavoro più efficiente e decisamente più orientata agli oggetti, tanto che in ASP.NET i tag possono essere generati lato server piuttosto che lato client.

Le Web Forms

Fino ad oggi, chi ha intrapreso la programmazione Web migrando da un ambiente di sviluppo tradizionale qual è Visual Basic, ha dovuto rinunciare a malincuore a molte opportunità.

Come prima cosa, i tag HTML non sono dei veri controlli, e come tali non dispongono di un puro modello di programmazione ad oggetti. Inoltre, il codice HTML è molto spesso “amalgamato” con il contenuto della pagina: una modifica alla struttura del sito comporta anche una ristrutturazione dell’informazione.

Per ridurre questi effetti collaterali, Microsoft ha introdotto in ASP.NET una libreria di oggetti, chiamata Web Forms, con lo scopo di agevolare e rendere più chiara la stesura di codice all’interno di una pagina dinamica. L’idea è molto semplice. E’ possibile specificare un tag nella forma:

Quando il processore ASP.NET incontra il tag, lo trasforma nel corrispettivo HTML. Il vantaggio è che questi controlli dispongono di un certo numero di proprietà, metodi ed eventi che usano una nomenclatura coerente e modificabili da codice.

Inoltre, nel generare la pagina, il processore ASP.NET è in grado di riconoscere il browser dell’utente: può di conseguenza generare una pagina HTML che ne utilizzi solo le caratteristiche supportate.

Come ulteriore vantaggio, con questo modello ad oggetti è notevolmente semplificata la convalida dei dati provenienti dall’input degli utenti, che è così gestita sia lato client sia lato server. Con le Web Forms è anche possibile “simulare” il mantenimento di stato tra le pagine, con le cosiddette “postback form”.

Aumentano i linguaggi di sviluppo

La presenza del .Net Common Language Runtime consente allo sviluppatore l’utilizzo di una platea teoricamente infinita di linguaggi per la scrittura di pagine ASP.NET. Usare un linguaggio od un altro risulta indifferente, visto che si usano le classi presenti nelle librerie .NET. In questo modo è possibile adottare Visual Basic, C# oppure ad esempio Fortran: si userà il linguaggio con il quale si è più produttivi o quello che rappresenta lo standard aziendale. Il Common Language Runtime si comporta quindi da strato di interfaccia tra la complessità del sistema operativo (e delle sue API – Application Program Interfaces) e il linguaggio.

Con ASP.NET Microsoft da inoltre l’addio a Visual Basic Script, che è sostituito da un pieno supporto per Visual Basic, un suo sovrainsieme. Come conseguenza, Visual Studio .NET (il successore di Visual Studio 6) non contiene due ambienti di programmazione, uno per Visual Basic e uno per la stesura di codice ASP (Visual Interdev), ma un solo strumento integrato di sviluppo per tutti i linguaggi.

Le pagine ASP.NET sono compilate

L’unica soluzione all’inefficienza del codice interpretato è la sua compilazione. Una pagina ASP.NET è creata alla pari di una pagina ASP: quando è richiesta dall’utente viene processata dal parser di linguaggio.

A differenza di ASP, però, dove la pagina è successivamente interpretata, con ASP.NET un compilatore si preoccupa della sua trasformazione in codice binario. Questa operazione è eseguita al primo accesso della pagina, oppure quando lo sviluppatore ne avrà alterato il contenuto. Tutti gli altri utenti della pagina ne riceveranno la versione già compilata, diminuendo di gran lunga i tempi di risposta, ma soprattutto il carico elaborativo. In caso di riavvio del server, la pagina non deve essere nuovamente compilata, giacché è memorizzata in una cache privata.

Il nuovo concetto di sessione

Le sessioni di ASP sono un comodo strumento per guidare l’utente tra più pagine di un sito e portare con sè le informazioni inserite. Si pensi ad un sito di commercio elettronico dove l’utente può in ogni momento verificare il contenuto del carrello e provvedere al pagamento. Sfortunatamente, le sessioni ASP richiedono l’utilizzo di cookie per il funzionamento. Non solo: le sessioni non possono essere utilizzate in realtà di tipo “Web Farm”, dove cioè più server si suddividono il carico elaborativo.

Con ASP.NET l’oggetto sessione è eseguito al di fuori del processo che gestisce l’applicazione Web: il risultato è che è possibile utilizzare le sessioni tra più server, e memorizzarne il contenuto in fonti di dati esterne, quali un file di testo oppure un server SQL. In caso di arresto critico del server, inoltre, la sessione può essere mantenuta e ristabilita. Un’ulteriore miglioria consente la fruizione delle sessioni anche a browser che non gestiscono i cookies, aggiungendo le informazioni come Querystring nell’URL.

Cache

Con ASP.NET è possibile costruire una cache per velocizzare la comunicazione con il browser e ridurre il consumo di risorse da parte del server. In base ad un discriminante la pagina è memorizzata in un’apposita cache e restituita al browser fino al verificarsi di una condizione che impone l’eliminazione e ricostruzione della cache. È una caratteristica molto versatile e potente. Una pagina può risiedere in memoria ad esempio fino allo scadere di un intervallo stabilito o fino a quando non cambia un file da cui dipende.

Debugging e tracing

Fino ad oggi mancavano delle tecniche efficienti per la correzione degli errori e l’analisi del codice, se non utilizzando le estensioni lato server rese disponibili da Visual Interdev. ASP.NET include un vero debugger (una versione più completa è distribuita con Visual Studio .NET) che è possibile configurare con i “breakpoint” e i “watches”, come se ci trovassimo in Visual Basic. Il file config.web (che si affianca a global.asax) può essere invece modificato per consentire il tracing del codice: informazioni rese disponibili sono tra le altre il dettaglio di richiesta della pagina, l’albero di generazione dei controlli, il contenuto delle variabili lato server e delle intestazioni HTTP.

Convivenza di ASP e ASP.NET

ASP e ASP.NET possono essere installati sullo stesso server senza interferire le une con le altre. Per ASP.NET l’estensione da utilizzare è solitamente .aspx (a differenza di .asp utilizzato per i documenti .ASP). E’ importante sottolineare che non è garantita la compatibilità 100% tra ASP e ASP.NET e che le due tecnologie non condividono lo spazio di memoria degli oggetti session e application: la comunicazione tra pagine ASP e ASP.NET sullo stesso server deve basarsi su componenti scritti ad hoc o sul passaggio di parametri “nascosti”.

Riscrivere il codice da zero

Se state valutando la possibilità di migrare un progetto ASP verso ASP.NET, dovete sapere che tutto il codice deve essere riscritto per poter sfruttare appieno le potenzialità di questa tecnologia. L’uso di controlli lato server e di form postback, unito alla possibilità di separare il codice dallo strato di presentazione, rende praticamente impossibile il riutilizzo del codice precedente.
Sarà improbabile che vengano realizzati in futuro dei tool di conversione automatici per la migrazione del codice (come invece è avvenuto con “l’upgrade wizard” di Visual Basic): le differenze sono di concetto più che di sintassi.

Conclusione

Molte le novità che distinguono ASP.NET dal predecessore, dal modello ad oggetti alle caratteristiche migliorate o completamente nuove.

Se siete incuriositi, siete pronti per il nostro corso online di ASP.NET!