Condividi tramite

Mappatura degli spazi dei nomi XAML e lo spazio dei nomi

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 assembly personalizzati.

Relazione tra namespace XAML, definizione del codice e librerie di tipi

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 utilizza la logica interna di mapping dei tipi e di attivazione.
  • Librerie distribuite fornite da Microsoft o da terze parti.
  • Librerie che rappresentano la definizione di un controllo di terze parti che la tua app incorpora e il pacchetto ridistribuisce.
  • 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ù assembly 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: puoi 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 dagli assembly 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 di Windows Runtime.

Spazi dei nomi XAML nell'uso 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 puoi dichiarare senza qualificarli con un prefisso. Ad esempio, se dichiari 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, associandolo (in genere) 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 del linguaggio e Windows Runtime è un'implementazione che usa XAML come linguaggio e definisce un vocabolario specifico a cui fanno riferimento i 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 da modelli di progetto, codice di esempio e documentazione per le funzionalità del linguaggio. Lo spazio dei nomi del linguaggio XAML definisce diverse funzionalità di uso comune necessarie anche per le app di Base di Windows Runtime. Ad esempio, per unire qualsiasi code-behind a un file XAML tramite una classe parziale, devi denominare tale classe come attributo x:Class nell'elemento radice del file XAML pertinente. 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 mappano 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 per i progettisti, in particolare al supporto per i progettisti nelle aree di progettazione XAML di Microsoft Visual Studio. Lo spazio dei nomi XAML "d:" abilita gli attributi per il design o il design-time negli elementi XAML. Questi attributi della finestra di progettazione influiscono solo sugli aspetti di progettazione relativi al comportamento di XAML. Gli attributi della finestra 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 della finestra 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 degli attributi del progettista sono destinati a offrire un'esperienza migliore per interagire con i contesti dati e le origini dati durante lo sviluppo di XAML e codice che utilizzano 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 esegui la migrazione di XAML da Microsoft Silverlight, potresti 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à delle finestre 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.

  • Attributo d:DataContext: È possibile impostare questo attributo come radice di una pagina o in un controllo per sostituire qualsiasi DataContext esplicito o ereditato che l'oggetto potrebbe avere.

  • Attributo d:DesignSource: Specifica un'origine dati in fase di progettazione per collectionViewSource, che esegue l'override di Source.

  • estensioni di markup d:DesignInstance e d:DesignData: Queste estensioni di markup vengono usate per fornire le risorse dati in fase di progettazione per d:DataContext o d:DesignSource. Non verrà descritto in modo completo come usare le risorse dati in fase di progettazione qui. Per ulteriori informazioni, vedi Attributi Design-Time. Per alcuni esempi di utilizzo, vedere Dati di esempio nell'area di progettazione e per la creazione di prototipi.

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:".

locale: e comune:

"local:" è un prefisso che viene spesso mappato automaticamente all'interno delle pagine XAML per un progetto di app UWP basato su modelli predefiniti. 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à come convertitori e comandi ed è possibile trovare le definizioni nella cartella Common nella visualizzazione Esplora soluzioni .

vsm:

Non usare. "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, vedi Migrazione di Silverlight o XAML/codice WPF a un'app di Windows Runtime.

Mappatura dei tipi personalizzati agli spazi dei nomi e ai prefissi di XAML

Puoi eseguire il mapping di uno spazio dei nomi XAML in modo da poter usare XAML per accedere ai tuoi tipi personalizzati. In altre parole, si sta eseguendo la mappatura di uno spazio dei nomi del codice così come è rappresentato nel codice che definisce il tipo personalizzato, assegnandogli 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 segue un segno di uguale e si trova tra virgolette. 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. Vedi 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 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 di supporto in un linguaggio .NET (C# o Microsoft Visual Basic), è possibile usare convenzioni che utilizzano un punto (".") come parte dei nomi dei namespaces per creare una gerarchia concettuale di namespaces di 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 namespace annidati in C++, il separatore tra i namespace annidati consecutivi 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 definisci il codice da usare con XAML. Non è possibile valutare i tipi annidati. Non c'è modo per il parser XAML di comprendere se un punto faccia parte del nome di tipo annidato o del nome dello spazio dei nomi.

Tipi personalizzati e assembly

Il nome dell'assembly che definisce i tipi di supporto per uno spazio dei nomi XAML non viene specificato nella mappatura. La logica per cui gli assembly 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 assembly che si desidera includere come origine di definizione del codice per XAML come assembly dipendente nelle impostazioni del progetto. Per altre info, vedi 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 info, vedi Proprietà associate personalizzate.

  • Last updated on