Spazi dei nomi XAML e mapping dello spazio dei nomi

  • Articolo

Questo argomento illustra i mapping dello spazio dei nomi XML/XAML (xmlns) disponibili nell'elemento radice della maggior parte dei file XAML. Descrive anche come produrre mapping simili per tipi e gruppi personalizzati.

Correlazione tra gli spazi dei nomi XAML e le librerie di tipi e definizione del codice

Sia per utilizzo generico che per la programmazione delle app di Windows Runtime, XAML viene usato per dichiarare oggetti, proprietà di tali oggetti e relazioni tra proprietà oggetto espresse come gerarchie. Gli oggetti dichiarati in XAML sono supportati da librerie di tipi o altre rappresentazioni definite da altre tecniche e linguaggi di programmazione. Queste librerie potrebbero essere:

  • Set predefinito di oggetti per Windows Runtime. Si tratta di un set fisso di oggetti e l'accesso a questi oggetti da XAML usa la logica di attivazione e mapping dei tipi interna.
  • Librerie distribuite fornite da Microsoft o da terzi.
  • Librerie che rappresentano la definizione di un controllo di terzi che l'app integra e ridistribuisce il pacchetto.
  • La propria libreria, che fa parte del progetto e contiene alcune o tutte le definizioni di codice utente.

Le informazioni sul tipo di supporto sono associate a specifiche definizioni di spazio dei nomi XAML. I framework XAML, ad esempio Windows Runtime, possono aggregare più gruppi e più spazi dei nomi del codice per eseguire il mapping a un singolo spazio dei nomi XAML. Ciò consente il concetto di vocabolario XAML che copre un framework o una tecnologia di programmazione più ampio. Un vocabolario XAML può essere abbastanza esteso, ad esempio la maggior parte del codice XAML documentato per le app di Windows Runtime in questo riferimento costituisce un singolo vocabolario XAML. Un vocabolario XAML è anche estendibile: si può estenderlo aggiungendo tipi alle definizioni di codice di supporto, assicurandoti di includere i tipi negli spazi dei nomi del codice già usati come origini dello spazio dei nomi mappate per il vocabolario XAML.

Un processore XAML può cercare tipi e membri dai gruppi di backup associati a tale spazio dei nomi XAML quando crea una rappresentazione di oggetto in fase di esecuzione. Ecco perché XAML è utile come modo per formalizzare e scambiare definizioni di comportamento di costruzione di oggetti e perché XAML viene usato come tecnica di definizione dell'interfaccia utente per un'app UWP.

Spazi dei nomi XAML in un utilizzo tipico del markup XAML

Un file XAML dichiara quasi sempre uno spazio dei nomi XAML predefinito nel relativo elemento radice. Lo spazio dei nomi XAML predefinito definisce gli elementi che si possono dichiarare senza qualificarli con un prefisso. Ad esempio, se si dichiara un elemento <Balloon />, un parser XAML prevede che esista un elemento Balloon ed è valido nello spazio dei nomi XAML predefinito. Al contrario, se Balloon non è nello spazio dei nomi XAML predefinito definito, devi invece qualificare il nome dell'elemento con un prefisso, ad esempio <party:Balloon />. Il prefisso indica che l'elemento esiste in uno spazio dei nomi XAML diverso rispetto allo spazio dei nomi predefinito ed è necessario eseguire il mapping di uno spazio dei nomi XAML alla parte prefisso prima di poter usare questo elemento. Gli spazi dei nomi XAML si applicano all'elemento specifico in cui sono dichiarati e anche a qualsiasi elemento contenuto da tale elemento nella struttura XAML. Per questo motivo, gli spazi dei nomi XAML sono quasi sempre dichiarati sugli elementi radice di un file XAML per sfruttare questa ereditarietà.

Dichiarazioni dello spazio dei nomi XAML predefinito e del linguaggio XAML

All'interno dell'elemento radice della maggior parte dei file XAML sono disponibili due dichiarazioni xmlns. La prima dichiarazione esegue il mapping di uno spazio dei nomi XAML come predefinito: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Si tratta dello stesso identificatore dello spazio dei nomi XAML usato in diverse tecnologie Microsoft predecessori che usano anche XAML come formato di markup di definizione dell'interfaccia utente. L'uso dello stesso identificatore è intenzionale ed è utile quando si esegue la migrazione dell'interfaccia utente definita in precedenza a un'app di Windows Runtime usando C++, C# o Visual Basic.

La seconda dichiarazione esegue il mapping di uno spazio dei nomi XAML separato per gli elementi del linguaggio definiti da XAML, eseguendone (in genere) il mapping al prefisso "x:": xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Questo valore xmlns e il prefisso "x:" a cui è mappato, è identico anche alle definizioni usate in diverse tecnologie Microsoft predecessore che usano XAML.

La relazione tra queste dichiarazioni è che XAML è una definizione di linguaggio e Windows Runtime è un'implementazione che usa XAML come linguaggio e definisce un vocabolario specifico in cui viene fatto riferimento ai relativi tipi in XAML.

Il linguaggio XAML specifica determinati elementi del linguaggio e ognuno di questi elementi deve essere accessibile tramite le implementazioni del processore XAML che funzionano con lo spazio dei nomi XAML. La convenzione di mapping "x:" per lo spazio dei nomi XAML del linguaggio XAML è seguita dai modelli di progetto, dal codice di esempio e dalla documentazione per le funzionalità del linguaggio. Lo spazio dei nomi del linguaggio XAML definisce diverse funzionalità di uso comune necessarie anche per le app windows Runtime di base che usano C++, C# o Visual Basic. Ad esempio, per unire code-behind a un file XAML tramite una classe parziale, è necessario denominare la classe come attributo x:Class nell'elemento radice del file XAML corrispondente. In alternativa, qualsiasi elemento come definito in una pagina XAML come risorsa con chiave in un resourceDictionary e riferimenti a risorse XAML deve avere l'attributo x:Key impostato sull'elemento oggetto in questione.

Spazi dei nomi del codice che eseguono il mapping allo spazio dei nomi XAML predefinito

Di seguito è riportato un elenco di spazi dei nomi di codice di cui è attualmente stato eseguito il mapping allo spazio dei nomi XAML predefinito.

  • Windows.UI
  • Windows.UI.Xaml
  • Windows.UI.Xaml.Automation
  • Windows.UI.Xaml.Automation.Peers
  • Windows.UI.Xaml.Automation.Provider
  • Windows.UI.Xaml.Automation.Text
  • Windows.UI.Xaml.Controls
  • Windows.UI.Xaml.Controls.Primitives
  • Windows.UI.Xaml.Data
  • Windows.UI.Xaml.Documents
  • Windows.UI.Xaml.Input
  • Windows.UI.Xaml.Interop
  • Windows.UI.Xaml.Markup
  • Windows.UI.Xaml.Media
  • Windows.UI.Xaml.Media.Animation
  • Windows.UI.Xaml.Media.Imaging
  • Windows.UI.Xaml.Media.Media3D
  • Windows.UI.Xaml.Navigation
  • Windows.UI.Xaml.Resources
  • Windows.UI.Xaml.Shapes
  • Windows.UI.Xaml.Threading
  • Windows.UI.Text

Altri spazi dei nomi XAML

Oltre allo spazio dei nomi predefinito e allo spazio dei nomi XAML del linguaggio XAML "x:", è anche possibile visualizzare altri spazi dei nomi XAML mappati nel codice XAML predefinito iniziale per le app generate da Microsoft Visual Studio.

d: (http://schemas.microsoft.com/expression/blend/2008)

Lo spazio dei nomi XAML "d:" è destinato al supporto della finestra di progettazione, in particolare il supporto della finestra di progettazione nelle aree di progettazione XAML di Microsoft Visual Studio. Lo spazio dei nomi XAML "d:" abilita gli attributi della finestra di progettazione o della fase di progettazione negli elementi XAML. Questi attributi dello strumento di progettazione influiscono solo sugli aspetti di progettazione relativi al comportamento di XAML. Gli attributi dello strumento di progettazione vengono ignorati quando lo stesso codice XAML viene caricato dal parser XAML di Windows Runtime durante l'esecuzione di un'app. In genere, gli attributi dello strumento di progettazione sono validi per qualsiasi elemento XAML, ma in pratica esistono solo alcuni scenari in cui l'applicazione di un attributo della finestra di progettazione è appropriata. In particolare, molti attributi della finestra di progettazione sono progettati per offrire un'esperienza migliore per interagire con i contesti dati e le origini dati durante lo sviluppo di codice e XAML che usano il data binding.

  • Attributi d:DesignHeight e d:DesignWidth: questi attributi vengono talvolta applicati alla radice di un file XAML creato automaticamente da Visual Studio o da un'altra area di progettazione XAML. Ad esempio, questi attributi vengono impostati nella radice UserControl del codice XAML creato se si aggiunge un nuovo UserControl al progetto dell'app. Questi attributi semplificano la progettazione della composizione del contenuto XAML, in modo da prevedere alcuni vincoli di layout che potrebbero esistere una volta che il contenuto XAML viene usato per un'istanza del controllo o per un'altra parte di una pagina dell'interfaccia utente più grande.

Nota Se si sta eseguendo la migrazione di XAML da Microsoft Silverlight, si potrebbero avere questi attributi sugli elementi radice che rappresentano un'intera pagina dell'interfaccia utente. In questo caso potrebbe essere necessario rimuovere gli attributi. Altre funzionalità degli strumenti di progettazione XAML, ad esempio il simulatore, sono probabilmente più utili per progettare layout di pagina che gestiscono correttamente gli stati di ridimensionamento e visualizzazione rispetto a un layout di pagina a dimensione fissa usando d:DesignHeight e d:DesignWidth.

mc: (http://schemas.openxmlformats.org/markup-compatibility/2006)

"mc:" indica e supporta una modalità di compatibilità del markup per la lettura di XAML. In genere, il prefisso "d:" è associato all'attributo mc:Ignorable. Questa tecnica consente ai parser XAML in fase di esecuzione di ignorare gli attributi di progettazione in "d:".

local: e common:

"local:" è un prefisso che viene spesso mappato automaticamente all'interno delle pagine XAML per un progetto di app UWP basato su modelli. Viene mappato per fare riferimento allo stesso spazio dei nomi creato per contenere l'attributo x:Class e il codice per tutti i file XAML, incluso app.xaml. Finché definisci le classi personalizzate che vuoi usare in XAML in questo stesso spazio dei nomi, puoi usare il prefisso local: per fare riferimento ai tipi personalizzati in XAML. Un prefisso correlato proveniente da un progetto di app UWP basato su modelli è common:. Questo prefisso fa riferimento a uno spazio dei nomi "Common" annidato che contiene classi di utilità, ad esempio convertitori e comandi, ed è possibile trovare le definizioni nella cartella Common nella vista Esplora soluzioni.

vsm:

Non utilizzare. "vsm:" è un prefisso che a volte viene visualizzato nei modelli XAML meno recenti importati da altre tecnologie Microsoft. Lo spazio dei nomi ha originariamente risolto un problema di strumenti dello spazio dei nomi legacy. È consigliabile eliminare le definizioni dello spazio dei nomi XAML per "vsm:" in qualsiasi CODICE XAML usato per Windows Runtime e modificare eventuali utilizzi di prefissi per VisualState, VisualStateGroup e oggetti correlati per usare invece lo spazio dei nomi XAML predefinito. Per altre info sulla migrazione XAML, vedere Migrazione di Silverlight o XAML/codice WPF a un'app di Windows Runtime.

Mapping di tipi personalizzati a spazi dei nomi e prefissi XAML

Puoi eseguire il mapping di uno spazio dei nomi XAML in modo da poter usare XAML per accedere ai tipi personalizzati. In altre parole, si sta eseguendo il mapping di uno spazio dei nomi del codice così come esiste in una rappresentazione di codice che definisce il tipo personalizzato e assegnando uno spazio dei nomi XAML insieme a un prefisso per l'utilizzo. I tipi personalizzati per XAML possono essere definiti in un linguaggio Microsoft .NET (C# o Microsoft Visual Basic) o in C++. Il mapping viene eseguito definendo un prefisso xmlns. Ad esempio, xmlns:myTypes definisce un nuovo spazio dei nomi XAML a cui si accede anteponendo tutti gli utilizzi con il token myTypes:.

Una definizione xmlns include un valore e la denominazione del prefisso. Il valore è una stringa che si trova tra virgolette, seguendo un segno uguale. Una convenzione XML comune consiste nell'associare lo spazio dei nomi XML a un URI (Uniform Resource Identifier), in modo che esista una convenzione per l'univocità e l'identificazione. Vedere anche questa convenzione per lo spazio dei nomi XAML predefinito e lo spazio dei nomi XAML del linguaggio XAML, nonché per alcuni spazi dei nomi XAML meno usati da XAML di Windows Runtime. Tuttavia, per uno spazio dei nomi XAML che esegue il mapping dei tipi personalizzati, anziché specificare un URI, si inizia la definizione del prefisso con il token "using:". Dopo il token "using:", si assegna quindi il nome allo spazio dei nomi del codice.

Ad esempio, per eseguire il mapping di un prefisso "custom1" che consente di fare riferimento a uno spazio dei nomi "CustomClasses" e di usare classi di tale spazio dei nomi o assembly come elementi oggetto in XAML, la pagina XAML deve includere il mapping seguente sull'elemento radice: xmlns:custom1="using:CustomClasses"

Non è necessario eseguire il mapping di classi parziali dello stesso ambito di pagina. Ad esempio, non sono necessari prefissi per fare riferimento a gestori eventi definiti per la gestione degli eventi dalla definizione dell'interfaccia utente XAML della pagina. Inoltre, molte delle pagine XAML iniziali dei progetti generati da Visual Studio per un'app di Windows Runtime usando C++, C# o Visual Basic eseguono già il mapping di un prefisso "local:", che fa riferimento allo spazio dei nomi predefinito specificato dal progetto e allo spazio dei nomi usato dalle definizioni parziali della classe.

Regole del linguaggio CLR

Se si scrive il codice sottostante in un linguaggio .NET (C# o Microsoft Visual Basic), è possibile usare convenzioni che usano un punto (".") come parte dei nomi degli spazi dei nomi per creare una gerarchia concettuale degli spazi dei nomi del codice. Se la definizione dello spazio dei nomi contiene un punto, il punto deve far parte del valore specificato dopo il token "using:".

Se il file code-behind o il file di definizione del codice è un file C++, esistono alcune convenzioni che seguono ancora il modulo del linguaggio CLR (Common Language Runtime), in modo che non vi sia alcuna differenza nella sintassi XAML. Se si dichiarano spazi dei nomi annidati in C++, il separatore tra le stringhe dello spazio dei nomi nidificate successive deve essere "." anziché "::" quando si specifica il valore che segue il token "using:".

Non usare tipi annidati (ad esempio annidare un'enumerazione all'interno di una classe) quando si definisce il codice da usare con XAML. Non è possibile valutare i tipi annidati. Non esiste alcun modo per il parser XAML per distinguere che un punto fa parte del nome del tipo annidato anziché parte del nome dello spazio dei nomi.

Tipi e gruppi personalizzati

Il nome del gruppo che definisce i tipi di supporto per uno spazio dei nomi XAML non viene specificato nel mapping. La logica per cui i gruppi sono disponibili è controllata a livello di definizione dell'app e fa parte dei principi di base per la distribuzione e la sicurezza delle app. Dichiarare qualsiasi gruppo che si desidera includere come origine di definizione del codice per XAML come assembly dipendente nelle impostazioni del progetto. Per altre informazioni, vedere Creazione di componenti Windows Runtime in C# e Visual Basic.

Se si fa riferimento a tipi personalizzati dalla definizione dell'applicazione o dalle definizioni di pagina dell'app primaria, questi tipi sono disponibili senza ulteriori configurazioni di assembly dipendenti, ma è comunque necessario eseguire il mapping dello spazio dei nomi del codice che contiene tali tipi. Una convenzione comune consiste nel eseguire il mapping del prefisso "local" per lo spazio dei nomi del codice predefinito di una determinata pagina XAML. Questa convenzione viene spesso inclusa nei modelli di progetto iniziale per i progetti XAML.

Proprietà associate

Se si fa riferimento alle proprietà associate, la parte di tipo proprietario del nome della proprietà associata deve essere nello spazio dei nomi XAML predefinito o deve essere preceduta da prefisso. È raro anteporre gli attributi separatamente dai relativi elementi, ma questo è un caso in cui a volte è necessario, in particolare per una proprietà associata personalizzata. Per altre informazioni, vedere Proprietà associate personalizzate.