Come probabilmente saprete è stata rilasciata la beta Silverlight 2.0.

Ovviamente da fan di WPF non ho resistito dal provarla subito. Sinceramente, delle scorse preview ero rimasto un po' deluso, poiché conoscendo WPF mi rendevo conto di quante cose mancassero diventando così frustrante giocarci. Beh invece con Silverlight 2.0 mi ritengo soddisfatto e entusiasta come un bambino che scarta i regali a Natale :-D

Per prima cosa il setup installa runtime, template per Visual Studio 2008 e SDK. Una parte del SDK è rivolta al server e l'altra al client.

Lato server una nuova System.Web.Silverlight.dll contiene i controlli Silverlight e MediaPlayer. Il primo semplicemente crea il markup per istanziare il plugin, include il codice JavaScript e non è più necessario includere script esterni ecc. MediaPlayer è un controllo più evoluto che permette con due click di inserire un player di video con tanto di marcatori e capitoli basandosi su Silverlight. Il tutto completamente skinnabile, con una decina di skin già presenti nel SDK. Molto maschio.

Lato client l'architettura è rimasta invariata e il runtime, di soli 4,3MB, è installato in %ProgramFiles%\Microsoft Silverlight\2.0.30226.2. Rispetto alla alpha abbiamo in più System.ServiceModel (WCF quindi) con BasicHttpBinding, supporto a REST e JSON. L'assembly System.Windows è stato ampliato con altre classi base con niente popo di meno che: StackPanel, Grid, Border, TextBox, ItemsControl (i principali).

Incredibile, c'è la classe Binding con IValueConverter, BindingMode, Source, ma nessun altra tipologia di binding. In molti aspetti Silverlight assomiglia da fuori a WPF, ma dentro l'implementazione è decisamente diversa, tendente al risparmio (non poteva essere diversamente). I controlli sono basati su DependencyProperty (anche Attached Property), ma non è presente nessun meccanismo di triggering o metadati aggiuntivi, mentre gli eventi invece sono quelli normali del CLR; quindi niente Attached Event, niente bubbling o tunneling ed eventi di preview.

I controlli si basano su Template che vengono caricati tramite Style avente come TargetType il tipo del controllo da personalizzare. Gli Style non hanno trigger, quindi nel metodo ApplyTemplate ogni controllo cerca elementi nel template dal nome prefissato (es: RootElement), ne intercettono gli eventi e interagiscono in base a quest'ultimi. Questa tecnica esiste in modo identico anche in WPF, ma si usa raramente preferendo l'uso di trigger in modo da legare il meno possibile il codice al markup. Continuando con il paragone con WPF, niente Command, CollectionView e WeakEvent.

Tutto sommato quindi, le cose che si potevano implementare sono state copiate da WPF e questo non può farmi che piacere :-), ma ovviamente per non esagerare nella dimensione degli assembly è stato sacrificato qualcosa.

Da Visual Studio o Blend 2.5 possiamo creare un progetto Silverlight 2.0 e rispetto a prima, si sviluppa una specie di class library avente già pronti i file App.xaml, che è l'entry point, e un file Page.xaml: lo UserControl principale. Ovviamente hanno il relativo code-behind dove possiamo scrivere in C# 3.0 o VB 9.
Il risultato della compilazione è un file .xap, l'unico file da distribuire, che è un file .zip contenente un file di metadati, i file che abbiamo incluso nel progetto con target Content e la nostra dll compilata. Quest'ultima contiene nelle risorse i file XAML, ma non compilati in BAML (diversamente da WPF). Probabilmente questa scelta è dovuta al fatto che l'ottimizzazione di caricamento del markup è stata ritenuta sacrificabile, mentre la compressione è già ottenuta grazie allo ZIP.

Per ultimo una cosa inaspettata: nel progetto di Visual Studio troveremo referenziati altre dll che verranno poi incluse nel file xap. Queste normalmetne sono: System.Windows.Controls e System.Windows.Controls.Extended. Queste dll, più altre, si trovano normalmente nella cartella del SDK (C:\Program Files\Microsoft SDKs\Silverlight\v2.0\Libraries\Client) e non sono incluse nel setup di Silverlight. Peccato che quest'altre 18 dll contengano: Ruby, Python, Managed JScript, le classi Syndacation RSS/Atom di WCF, Linq To Xml, controlli come Thumb (per il drag&drop), Button, CheckBox, ListBox, RadioButton, Slider, ScrollBar, ScrollViewer, ToolTip, ToggleButton, DataGrid, Calendar, DateTimePicker, GridSplitter, WatermarkedTextBox.

Prima di tutto stupisce che ci siano controlli che WPF non ha e sia Silverlight il primo ad implementarli, ma soprattutto ecco spiegato perché il runtime è piccolo. Infatti tutte le altre dll le mandiamo noi all'utente inglobandole nel file xap. Così l'installazione del plugin è piccola, mentre l'utente navigando su più siti si ritrova a scaricare solo le dll che effettivamente l'applicazione usa, con il rischio ovviamente di scaricare più volte la stessa dll in pacchetti diversi. Furbini vero? :-D

Non l'ho ancora guardato benissimo, ma Silverlight così mi piace decisamente e non ha rivali sul web. Se volete vederlo all'opera potete venire al Real Code Launch che terremo a Roma. Dovete assolutamente venire; chi c'è, c'è, chi non c'è... eh non c'è.