Terza puntata dei post dedicati ad Avalon e Longhorn (puntata precedente)...
Semplificando si può affermare che le applicazioni per Longhorn consistono in un oggetto Application e in un insieme di pagine in XAML che rappresentano l'interfaccia utente. L'oggetto Application è di tipo singleton e rimane attivo durante l'esecuzione dell'applicazione. Questo oggetto non è altro che una istanza della classe MSAvalon.Windows.Application o di una sua derivata e fornisce l'entry point, nonchè consente di gestire lo stato, la sicurezza e gli eventi a livello applicativo. L'oggetto in questione determina anche il tipo dell'applicazione: 1) applicazione stand-alone (a finestra singola) oppure 2) applicazione navigabile. In questo secondo caso l'oggetto che rappresenta l'applicazione è una istanza della classe MSAvalon.Windows.Navigation.ApplicationNavigation che estende la classe vista in precedenza con il supporto per la navigazione (eventi di navigazione, gestione dello stato tra le pagine, condivisione di proprietà, ecc.).
Come detto sopra, solitamente le pagine che compongono la UI vengono scritte in XAML (eXtensible Application Markup Language), che, come si può capire dal nome stesso, è un linguaggio di markup basato su XML che permette di descrivere il modello degli oggetti utilizzati dall'applicazione. In pratica una pagina XAML descrive l'albero delle istanze delle classi che il runtime andrà a creare una volta lanciata l'esecuzione dell'applicazione. Quando il runtime crea la pagina, esso istanzia ogni elemento e ogni nodo indicato nel file XAML e crea in memoria un modello a oggetti corrispondente. Questi oggetti possono in ogni caso essere modificati via codice.
E' importante sottolineare che tutto ciò che può essere fatto utilizzando XAML può essere fatto anche in maniera programmatica (ovvero scrivendo del codice che dichiara e istanzia oggetti), ma non è vero il viceversa. Di fatto quello che si può fare tramite XAML è descrivere l'insieme gerarchico di oggetti che verranno creati dal runtime, impostarne le proprietà in modo statico o acquisendo i valori da qualche sorgente dati, memorizzare i valori delle proprietà in qualche sorgente dati, associare un event handler ad un evento.
Le applicazioni in Longhorn basano il loro modello di sicurezza sul modello Code Access Security (CAS) fornito dal CLR. Oltre a questo, Longhorn fornisce un ambiente sicuro e gestito denominato SEE (Secure Execution Environment) che protegge gli utenti da comportamenti non proprio consoni e corretti da parte delle applicazioni. Il Trust Manager fornisce un sistema basato su punteggi per determinare il livello di fiducia (trust appunto) che gli utenti possono assegnare alle applicazioni. Come accennato nei post precedenti, a differenza di quanto avviene oggi, dove le applicazioni girano con il set FullTrust, le applicazioni in Longhorn possano girate con la corretta policy (per esempio, uguale a quella del sito da cui l'applicazione è stata scaricata). Questo è possibile proprio grazie all'esistenza del manifest di deployment, in cui sono contenute le regole di sicurezza e isolamento.
To be continued...
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
- Finalmente disponibili i driver delle schede UMTS Vodafone per Windows Vista, il 12 marzo 2007 alle 09:50
- Installazione di Windows Vista, il 21 novembre 2006 alle 01:46
- WWF e WCF January 2006 CTP, il 21 gennaio 2006 alle 19:00
- ServiceContract e interfaccia di classe in Indigo, il 23 marzo 2005 alle 11:00
- Avalon e il data binding, il 19 gennaio 2005 alle 23:48
- XAML, di che si tratta?, l'8 gennaio 2005 alle 17:45