Come cambia il Web
Di Dino Esposito
Con l’avvento di AJAX, oramai tre anni fa, si è innescata una reazione a catena che è ancora lontana dall’avere termine, anche se sui risultati finali sembra esserci un generale accordo. Il Web deve cambiare. Anzi, per fare i dotti, potremmo scomodare il Gattopardo di Tomasi di Lampedusa e parafrasare così: perché il Web resti così com'è, bisogna che tutto cambi.
Funzionalmente parlando, il Web di oggi sta bene a tutti. Si fa e-commerce, si fa publishing, si costruiscono portali, si blogga, si pubblicano data feed, si fanno ricerche. Non vi sono limiti significativi se la mettiamo in termini di funzionalità. Il problema semmai è nell’implementazione di queste funzionalità, che sconta i limiti dei browser e la vetustà tecnologica del paradigma Web.
Per andare oltre, e possibilmente mettere al mondo la prossima generazione di applicazioni Web, è necessario cambiare il paradigma di progettazione e aggiornare gli strumenti in dotazione sul client. Sembra facile, ma i problemi nascono man mano che ci si addentra nei dettagli.
In questa pagina
Un nuovo paradigma
Com’è fatto il browser
Il ruolo del Partial Rendering
L’idea di Silverlight 2.0
Perché Silverlight 2.0 è un Breakthrough
Conclusioni
Un nuovo paradigma
Il Web nasce nel 1991 al CERN di Ginevra. E nasce per mettere in rete documenti scientifici fatti di testo, grafici, e riferimenti bibliografici. L’idea fondamentale dei fondatori Tim Berners-Lee e il meno conosciuto Robert Cailliau è stata di creare un protocollo di rete e un linguaggio di markup per definire documenti e per creare collegamenti ipertestuali tra documenti dello stesso tipo. In sostanza, il concetto è che se ho in fondo al documento un riferimento ad un altro, vorrei poter cliccare sul nome per aprire proprio quel documento e consultarlo—hyperlinking. Oggi ci viene naturale perché 15 anni fa se lo sono inventato.
Il protocollo HTTP è stato fatto su misura per scambiare — in un mondo ristretto — documenti testuali. Quindi niente sicurezza e niente stato, ma semplicità allo stato puro. Nel corso degli anni, dopo che il CERN ha rinunciato a brevettare il Web, a HTML si sono aggiunte numerose funzionalità compreso JavaScript. E le pagine finite nei siti sono divenute sempre più complesse e articolate. Al punto che il protocollo HTTP ha cominciato a vacillare.
Il paradigma utilizzato appena al di sopra del protocollo di rete HTTP è quello del request/response: ti mando una form, mi restituisci una pagina. La transizione di un sito Web prevede il passaggio di pagina in pagina. Il che va bene se la pagina è leggera, fatta di puro testo senza troppe informazioni di layout, senza script e con pochissime immagini perlopiù salvate nella cache dei browser. Ma oggi non è più così. Ed ecco che fare il refresh completo della pagina ad ogni richiesta al server non è più sostenibile. Signori, si cambia paradigma. E ti arriva AJAX.
Nell’ottica AJAX, ogni richiesta viene fatta per dei dati di output, di qualunque tipo. E questi dati vengono calcolati in funzione di altri dati (generici). In sostanza, il paradigma diviene: ti mando dei dati, mi mandi dei dati. E chi si occupa dell’utente? La pagina da cui parte la richiesta dovrà contenere del codice per preparare la richiesta, manipolare i risultati e aggiornare l’interfaccia utente.
Com’è fatto il browser
Il browser è il client di riferimento nel mondo Web e la sua diffusione capillare è la chiave del successo del Web in quanto tale. Ora che per una rarissima congiunzione astrale ci troviamo ad avere che il 90% dei browser usati nel mondo supporta le stesse funzionalità non possiamo reinventare un modello di client di un’applicazione Web diverso e più ricco. Dobbiamo tenerci il browser così come è—con tutti i suoi limiti di anzianità.
Il browser implementa solo il classico paradigma Web. Il paradigma AJAX va implementato a mano: dallo sviluppatore o dal framework che questi utilizza. Secondo il paradigma AJAX un’applicazione Web ha un back-end fatto di servizi e un’interfaccia annidata nel Web. Per i servizi non vi è che l’imbarazzo della scelta quanto a tecnologia: ASP.NET Web services oppure WCF services. Per i data-transfer object si usa JSON. (Figura 1)
Figura 1 — Il paradigma AJAX
Il vero problema è l’interfaccia utente. Una volta che i servizi hanno portato i dati sul client, ogni forma di elaborazione deve essere affidata a JavaScript. La cosa non è affatto problematica per un semplice aggiornamento di alcuni elementi HTML. Diventa, invece, una faccenda piuttosto complessa e articolata se aumenta il carico di lavoro lato client e la ricchezza dei layout supportati: popolare una griglia oppure eseguire codice di presentation sono problematiche di peso nell’economia di scala di un’applicazione con molte pagine. Come fare?
I limiti sono due: JavaScript e il formato HTML. Da un lato servirebbe un linguaggio più ricco e possibilmente compilato. Dall’altro, un formato di documento più adatto a rappresentare l’output di uno strato di presentation. Tuttavia, almeno HTML deve rimanere il contenuto base, l’involucro esterno di ogni pagina Web.
Una risposta a queste problematiche la offre Microsoft Silverlight. Rilasciato lo scorso settembre in versione 1.0, Silverlight è atteso in versione 2.0 nella primavera 2008. La versione 2.0 si annuncia come una vera e propria rivoluzione in quanto a funzionalità. E ancor di più, si annuncia notevole il suo impatto sulle architetture Web. Con Silverlight 2.0, abbiamo in un colpo solo un sostituto di JavaScript (linguaggi managed) e di HTML (il formato XAML di WPF). Il modello di Figura 1, cioè, troverebbe in Silverlight 2.0 il motore ideale per la presentation layer logic. Ma prima di guardare meglio a Silverlight 2.0 facciamo una breve panoramica sul partial rendering di ASP.NET AJAX.
Il ruolo del Partial Rendering
Ci sono due forze opposte che si applicano al Web di oggi. Una è la forza dell’evoluzione rappresentata da AJAX; l’altra è la forza della continuità che tende a far evolvere gli scenari applicativi più lentamente senza rompere bruscamente con il passato e il presente. Questa seconda forza si esplica nel partial rendering.
In termini architetturali, il partial rendering non è nulla di nuovo. È il classico modello del Web adattato e migliorato per ottimizzare il rendering grafico della pagina. Si tratta di un approccio che funziona “parzialmente”; vale a dire che è un’ottima soluzione a breve termine per aggiungere capacità AJAX ad una pagina. Non è invece un cambio di architettura. Detto questo, però, non si può ignorare che molte applicazioni oggi hanno solo bisogno di un po’ di plastica facciale. E dunque il partial rendering è proprio il rimedio perfetto.
L’idea di Silverlight 2.0
Microsoft Silverlight è un plug-in cross-browser e cross-platform per costruire Rich Internet Applications su piattaforma Windows e Mac e prossimamente Linux. Per dettagli su Linux si può dare un’occhiata a https://www.mono-project.com/moonlight.
Silverlight permette ad applicazioni ASP.NET (ma non solo) di apparire e comportarsi come applicazioni desktop.
Con Silverlight 2.0 a bordo, un’applicazione Web si ritrova con una versione ridotta della CLR che significa supporto per i linguaggi managed, un po’ di .NET Framework (socket, eccezioni, LINQ, XML) e tutto il set di tag XAML. La Figura 2 illustra il modello di hosting di Silverlight 2.0 in una pagina ASP.NET o HTML. Questo modello è lo stesso in Silverlight 1.0 e Silverlight 2.0.
Figura 2 — Comunicazione tra Silverlight e Web pages
Silverlight è un plug-in che ospita un documento WPF e che comunica con il resto della pagina usando JavaScript. In aggiunta, in Silverlight 2.0 la comunicazione tra oggetti WPF avviene tramite linguaggi managed come C#, Visual Basic .NET e persino linguaggi dinamici come IronPython e Managed JScript.
Perché Silverlight 2.0 è un Breakthrough
Silverlight è annidato in una pagina come <object> e più oggetti Silverlight sono ammessi nella stessa pagina. L’oggetto Silverlight può essere largo quanto l’intera pagina od occupare solo una frazione di essa. Con Silverlight 2.0 disponibile, il presentation layer di applicazioni WPF e Web può essere, almeno in alcuni casi, lo stesso con un linguaggio managed e un sottinsieme del .NET Framework a dare support. Tutto ciò rappresenta una chiara svolta per architetti e sviluppatori. Silverlight ha bisogno di essere inizializzato in una pagina ASP.NET:
<script type="text/javascript"> function pageLoad() { var parent = $get("host"); createSilverlightHost(parent); } </script>
L’elemento chiamato host è un segnaposto HTML destinato a contenere l’oggetto Silverlight. Solitamente si tratta di un tag <span> o <div>.
<span id="host" />
La funzione createSilverlightHost è una funzione JavaScript definita dal programmatore che crea e configura il motore Silverlight. La sua tipica struttura è la seguente:
function createSilverlightHost(parentElement) { Silverlight.createObject( "xaml/customerview.xaml", parentElement, "SilverlightControl1", { width:'350', height:'120', background:'#111111', version:'1.0' }, { onError:null, onLoad:null }, null); }
Lo script crea un sottoalbero HTML il cui nome è SilverlightControl1. Questo sottoalbero include il documento WPF rappresentato dal file XAML. In ASP.NET AJAX gli script necessari possono essere incorporati tramite il controllo ScriptManager:
<asp:ScriptManager ID="ScriptManager1" runat="server"> <Scripts> <asp:ScriptReference Path="Silverlight.js" /> <asp:ScriptReference Path="CustomerView.aspx.js" /> </Scripts> </asp:ScriptManager>
Il file silverlight.js fa parte del Silverlight SDK e va installato sul Web server. L’altro file normalmente contiene il resto degli script necessari alla pagina.
In Silverlight 1.0 solo un sottinsieme limitato della sintassi XAML è supportato. Importanti funzionalità quali data binding, stili, layout e input non sono riconosciute. In Silverlight 2.0 verrà supportata l’intera sintassi XAML.
Gli elementi XAML con l’attributo x:Name possono essere raggiunti via script, come nell’esempio seguente:
var host = $get("SilverlightControl1"); var textBlock = host.content.findName("Customer-Data"); textBlock.text = ...;
Ciò significa che qualsiasi pezzo d’informazione che la pagina riesce a collezionare può essere passato a Silverlight per il display. Nella versione 2.0, però, sarà lo stesso documento XAML a poter avere un code-behind, ad eseguire operazioni e ad aggiornare l’interfaccia di conseguenza.
Conclusioni
Il Web è arrivato probabilmente alla fine della sua fase di vegetazione spontanea. Più di tanto non può dare. Se ci si accontenta, bene. Altrimenti bisogna cercare miglioramenti radicali a livello architetturale piuttosto che studiare nuovi e più creativi trucchi. Il Web non può prescindere dal suo client — il browser — e dalle sue intrinseche caratteristiche — JavaScript e HTML. È qui che bisogna lavorare per avere linguaggi più potenti per sviluppo e delivery e poter finalmente muovere a passi decisi verso architetture più desktop-like.
Silverlight 2.0 è ancora di là da venire. Ma le sue caratteristiche annunciate fanno presumere che il vero punto di svolta sia oramai prossimo. Nel frattempo che fare? Beh, la risposta è piuttosto scontata. Dal momento che Silverlight 2.0 è 100% WPF, cominciamo da lì. Facciamoci una scorpacciata di WPF sia manuale sia utilizzando tool di design come Microsoft Expression Blend 2.