Przestrzeń nazw XAML i mapowanie przestrzeni nazw dla WPF XAML

W tym temacie wyjaśniono również obecność i przeznaczenie dwóch mapowań przestrzeni nazw XAML, które często znajdują się w tagu głównym pliku XAML WPF. Opisano w nim również sposób tworzenia podobnych mapowań do używania elementów zdefiniowanych we własnym kodzie i/lub w oddzielnych zestawach.

Co to jest przestrzeń nazw XAML

Przestrzeń nazw XAML to tak naprawdę rozszerzenie koncepcji przestrzeni nazw XML. Techniki określania przestrzeni nazw XAML polegają na składni przestrzeni nazw XML, konwencji używania identyfikatorów URI jako identyfikatorów przestrzeni nazw, używaniu prefiksów w celu zapewnienia środków do odwołania się do wielu przestrzeni nazw z tego samego źródła znaczników i tak dalej. Podstawową koncepcją, która jest dodawana do definicji XAML przestrzeni nazw XML, jest to, że przestrzeń nazw XAML implikuje zakres unikatowości dla użycia znaczników, a także wpływa na to, w jaki sposób jednostki znaczników są potencjalnie objęte określonymi przestrzeniami nazw CLR i przywoływały zestawy. Na tę ostatnią uwagę ma również wpływ koncepcja kontekstu schematu XAML. Jednak na potrzeby współpracy WPF z przestrzeniami nazw XAML przestrzenie nazw XAML zazwyczaj można myśleć o przestrzeniach nazw XAML jako o domyślnej przestrzeni nazw XAML, przestrzeni nazw języka XAML i wszelkich kolejnych przestrzeniach nazw XAML zamapowanych przez znacznik XAML bezpośrednio na określone zapasowe przestrzenie nazw CLR i przywoływane zestawy.

Deklaracje przestrzeni nazw WPF i XAML

W deklaracjach przestrzeni nazw w tagu głównym wielu plików XAML zobaczysz, że zazwyczaj istnieją dwie deklaracje przestrzeni nazw XML. Pierwsza deklaracja mapuje ogólną przestrzeń nazw XAML klienta/platformy WPF jako domyślną:

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Druga deklaracja mapuje oddzielną przestrzeń nazw XAML, mapując ją (zazwyczaj) na x: prefiks.

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Relacja między tymi deklaracjami polega na tym, że mapowanie prefiksów obsługuje funkcje wewnętrzne, które są częścią definicji języka XAML, i jest jedną z implementacji, która używa języka XAML jako języka i definiuje słownictwo jego obiektów dla x: WPF języka XAML. Ponieważ słownictwo WPF będzie znacznie częściej używane niż użycie funkcji wewnętrznych XAML, słownictwo WPF jest mapowane jako domyślne.

Po konwencji prefiksów do mapowania obsługi funkcji wewnętrznych języka XAML następuje szablony projektów, przykładowy kod i dokumentacja funkcji językowych w x: ramach tego zestawu SDK. Przestrzeń nazw XAML definiuje wiele często używanych funkcji, które są niezbędne nawet w przypadku podstawowych aplikacji WPF. Na przykład w celu przyłączenia dowolnego kodu związanego z plikiem XAML za pośrednictwem klasy częściowej należy nazwać tę klasę jako atrybut w elemencie x:Class głównym odpowiedniego pliku XAML. Lub dowolny element zgodnie z definicją na stronie XAML, do których chcesz uzyskać dostęp jako zasób z kluczem, powinien mieć ustawiony atrybut dla x:Key określonego elementu. Aby uzyskać więcej informacji na temat tych i innych aspektów xaml zobacz XAML w WPF lub XAML Syntax In Detail.

Mapowanie na niestandardowe klasy i zestawy

Przestrzenie nazw XML można mapować na zestawy przy użyciu serii tokenów w obrębie deklaracji prefiksu, podobnie jak standardowe przestrzenie nazw XAML WPF i XAML-intrinsics są mapowane na xmlns prefiksy.

Składnia przyjmuje następujące możliwe nazwane tokeny i następujące wartości:

clr-namespace: Przestrzeń nazw CLR zadeklarowana w zestawie, który zawiera typy publiczne, które mają być uwidocznialne jako elementy.

assembly= Zestaw, który zawiera część lub całą przywoływną przestrzeń nazw CLR. Ta wartość jest zwykle tylko nazwą zestawu, a nie ścieżką, i nie zawiera rozszerzenia (na przykład .dll lub .exe). Ścieżka do tego zestawu musi zostać ustanowiona jako odwołanie do projektu w pliku projektu zawierającym kod XAML, który próbujesz zamapować. W celu uwzględnienia kontroli wersji i podpisywania silnej nazwy wartość może być ciągiem zdefiniowanym przez , assembly a AssemblyName nie prostą nazwą ciągu.

Należy pamiętać, że znak oddzielający token od clr-namespace jego wartości jest dwukropkiem (:) natomiast znak oddzielający assembly token od jego wartości jest znakiem równości (=). Znak, który ma być między tymi dwoma tokenami, jest średnikiem. Ponadto nie należy uwzględniać żadnych białych spacji w żadnym miejscu w deklaracji.

Przykład podstawowego mapowania niestandardowego

Poniższy kod definiuje przykładową klasę niestandardową:

namespace SDKSample {  
    public class ExampleClass : ContentControl {  
        public ExampleClass() {  
        ...  
        }  
    }  
}  
Namespace SDKSample  
    Public Class ExampleClass  
        Inherits ContentControl  
         ...  
        Public Sub New()  
        End Sub  
    End Class  
End Namespace  

Ta klasa niestandardowa jest następnie kompilowana do biblioteki, która według ustawień projektu (nie jest wyświetlana) nosi nazwę SDKSampleLibrary .

Aby odwołać się do tej klasy niestandardowej, należy również dołączyć ją jako odwołanie do bieżącego projektu, co zwykle byłoby możliwe przy użyciu interfejsu użytkownika Eksplorator rozwiązań w Visual Studio.

Teraz, gdy masz bibliotekę zawierającą klasę i odwołanie do niego w ustawieniach projektu, możesz dodać następujące mapowanie prefiksów jako część elementu głównego w języku XAML:

xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary"

Aby to wszystko zrobić, poniżej przedstawiono kod XAML, który zawiera mapowanie niestandardowe wraz z typowymi mapowaniami domyślnymi i x: w tagu głównym, a następnie używa odwołania z prefiksem do tworzenia wystąpienia w tym interfejsie ExampleClass użytkownika:

<Page x:Class="WPFApplication1.MainPage"  
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"  
    xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary">  
  ...  
  <custom:ExampleClass/>  
...  
</Page>  

Mapowanie na bieżące zestawy

assembly Można pominąć, jeśli odwołanie jest definiowane w tym samym zestawie co kod aplikacji odwołujący się clr-namespace do klas niestandardowych. Alternatywnie w tym przypadku równoważną składnią jest określenie , assembly= bez tokenu ciągu następującego po znaku równości.

Niestandardowe klasy nie mogą być używane jako element główny strony, jeśli są zdefiniowane w tym samym zestawie. Nie trzeba mapować klas częściowych; Tylko klasy, które nie są klasą częściową strony w aplikacji, muszą być mapowane, jeśli zamierzasz odwoływać się do nich jako elementów w języku XAML.

Mapowanie przestrzeni nazw CLR na przestrzenie nazw XML w zestawie

WPF definiuje atrybut CLR, który jest zużywany przez procesory XAML w celu mapowania wielu przestrzeni nazw CLR na pojedynczą przestrzeń nazw XAML. Ten atrybut, XmlnsDefinitionAttribute , jest umieszczany na poziomie zestawu w kodzie źródłowym, który tworzy zestaw. Kod źródłowy zestawu WPF używa tego atrybutu do mapowania różnych typowych przestrzeni nazw, takich jak System.Windows i , na przestrzeń System.Windows.Controls http://schemas.microsoft.com/winfx/2006/xaml/presentation nazw.

Parametr przyjmuje dwa parametry: nazwę przestrzeni nazw XmlnsDefinitionAttribute XML/XAML i nazwę przestrzeni nazw CLR. Więcej niż jeden XmlnsDefinitionAttribute może istnieć do mapowania wielu przestrzeni nazw CLR do tej samej przestrzeni nazw XML. Po zamapować elementy członkowskie tych przestrzeni nazw mogą być również przywoływane bez pełnej kwalifikacji, jeśli jest to wymagane, dostarczając odpowiednią instrukcje na stronie kodu using klasy częściowej. Aby uzyskać więcej informacji, zobacz XmlnsDefinitionAttribute .

Przestrzenie nazw projektanta i inne prefiksy z szablonów XAML

Jeśli pracujesz ze środowiskami programistycznych i/lub narzędziami do projektowania dla języka WPF XAML, możesz zauważyć, że istnieją inne zdefiniowane przestrzenie nazw/prefiksy XAML w ramach znaczników XAML.

Projektant WPF dla Visual Studio używa przestrzeni nazw projektanta, która jest zwykle mapowana na prefiks d: . Najnowsze szablony projektów dla WPF mogą wstępnie mapować tę przestrzeń nazw XAML w celu obsługi wymiany kodu XAML między projektantem WPF Visual Studio i innymi środowiskami projektowym. Ta projektowa przestrzeń nazw XAML służy do utrwalania stanu projektu podczas rundy interfejsu użytkownika opartego na języku XAML w projektancie. Jest on również używany dla funkcji, takich jak , które umożliwiają źródła danych d:IsDataSource środowiska uruchomieniowego w projektancie.

Innym prefiksem, który może być zamapowany, jest mc: . mc: Jest ze zgodnością znaczników i jest wykorzystujący wzorzec zgodności znaczników, który nie musi być specyficzny dla języka XAML. Do pewnego stopnia funkcje zgodności znaczników mogą służyć do wymiany kodu XAML między platformami lub poza innymi granicami implementacji zapasowej, pracy między kontekstami schematu XAML, zapewnienia zgodności dla ograniczonych trybów w projektantach i tak dalej. Aby uzyskać więcej informacji na temat pojęć dotyczących zgodności znaczników i ich relacji z platformą WPF, zobacz Zgodność znaczników (mc:) Funkcje językowe.

Ładowanie WPF i zestawu

Kontekst schematu XAML dla platformy WPF integruje się z modelem aplikacji WPF, który z kolei używa koncepcji zdefiniowanej w języku CLR AppDomain . W poniższej sekwencji opisano, jak kontekst schematu XAML interpretuje sposób ładowania zestawów lub wyszukiwania typów w czasie uruchamiania lub projektowania na podstawie użycia WPF i AppDomain innych czynników.

  1. Iteruj po pliku , szukając już załadowanego zestawu, który pasuje do wszystkich aspektów nazwy, począwszy od ostatnio AppDomain załadowanego zestawu.

  2. Jeśli nazwa jest kwalifikowana, Assembly.Load(String) wywołaj na kwalifikowaną nazwę.

  3. Jeśli krótka nazwa + token klucza publicznego kwalifikowanej nazwy pasuje do zestawu, z których załadowano znacznik, zwróć ten zestaw.

  4. Użyj krótkiej nazwy i tokenu klucza publicznego, aby Assembly.Load(String) wywołać .

  5. Jeśli nazwa jest niekwalifikowana, Assembly.LoadWithPartialName wywołaj .

Luźny kod XAML nie używa kroku 3; nie ma żadnego załadowanego zestawu.

Skompilowany kod XAML dla WPF (generowany za pośrednictwem xamlBuildTask) nie używa już załadowanych zestawów z AppDomain (krok 1). Ponadto nazwa nigdy nie powinna być niekwalifikowana z danych wyjściowych XamlBuildTask, więc krok 5 nie ma zastosowania.

Skompilowany kod BAML (generowany za pośrednictwem aplikacji PresentationBuildTask) używa wszystkich kroków, chociaż baml również nie powinien zawierać niekwalifikowanych nazw zestawu.

Zobacz też