Przestrzeń nazw XAML i mapowanie przestrzeni nazw dla WPF XAML

  • Artykuł
  • Czas czytania: 6 min

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 opierają się na składni przestrzeni nazw XML, konwencji używania identyfikatorów URI jako identyfikatorów przestrzeni nazw, używaniu prefiksów w celu zapewnienia możliwości 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 mogą być objęte konkretnymi przestrzeniami nazw CLR i zestawami, do których istnieją odwołania. Na tę ostatnią uwagę ma również wpływ koncepcja kontekstu schematu XAML. Jednak na potrzeby współpracy WPF z przestrzeniami nazw XAML można ogólnie myśleć o przestrzeniach nazw XAML jako o domyślnej przestrzeni nazw XAML, przestrzeni nazw języka XAML i wszelkich dalszych 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 zwykle 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 prefiks x: .

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

x: 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, a WPF to jedna implementacja, która używa języka XAML jako języka i definiuje słownictwo jego obiektów dla języka XAML. Ponieważ użycie słownictwa WPF będzie znacznie częściej używane niż użycie funkcji wewnętrznych XAML, słownictwo WPF jest mapowane jako domyślne.

Po x: konwencji prefiksów do mapowania obsługi funkcji wewnętrznych języka XAML następuje szablony projektu, przykładowy kod i dokumentacja funkcji języka w 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 dołączenia dowolnego kodu związanego z plikiem XAML za pośrednictwem klasy częściowej należy x:Class nazwać tę klasę jako atrybut w elemencie głównym odpowiedniego pliku XAML. Lub dowolny element zdefiniowany na stronie XAML x:Key , do których chcesz uzyskać dostęp jako zasób z kluczem, powinien mieć ustawiony atrybut dla określonego elementu. Aby uzyskać więcej informacji na temat tych i innych aspektów języka XAML, zobacz XAML in WPF or XAML Syntax In Detail (Szczegóły składni języka XAML w WPF lub XAML).

Mapowanie na niestandardowe klasy i zestawy

Przestrzenie nazw XML można mapować na zestawy przy użyciu serii tokenów xmlns w obrębie deklaracji prefiksu, podobnie jak standardowe przestrzenie nazw XAML WPF i XAML-intrinsics są mapowane na 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 zawierający część lub całą przywoływną przestrzeń nazw CLR. Ta wartość jest zazwyczaj 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, który zawiera kod XAML, który próbujesz zmapować. W celu uwzględnienia kontroli wersji i podpisywania silnej nazwy wartość assembly może być ciągiem zdefiniowanym przez , a AssemblyNamenie prostą nazwą ciągu.

Należy pamiętać, że znak oddzielający clr-namespace token od jego wartości jest dwukropkiem (:) natomiast znak oddzielający assembly token od jego wartości jest znakiem równości (=). Znak do użycia między tymi dwoma tokenami jest średnikiem. Ponadto nie należy uwzględniać żadnych białych spacji w żadnym miejscu 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) ma 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 zazwyczaj 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 zsumować, poniżej przedstawiono kod XAML, który zawiera mapowanie niestandardowe wraz z typowymi mapowaniami domyślnymi i x: w tagu głównym, a ExampleClass następnie używa odwołania z prefiksem do tworzenia wystąpienia w tym interfejsie 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 clr-namespace jest definiowane w tym samym zestawie co kod aplikacji odwołujący się do klas niestandardowych. Alternatywnie równoważną składnią w tym przypadku jest assembly=określenie , bez tokenu ciągu następującego po znaku równości.

Klasy niestandardowe nie mogą być używane jako element główny strony, jeśli zostały 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, System.Windows takich jak i System.Windows.Controls, na przestrzeń http://schemas.microsoft.com/winfx/2006/xaml/presentation nazw.

Parametr XmlnsDefinitionAttribute przyjmuje dwa parametry: nazwę przestrzeni nazw XML/XAML i nazwę przestrzeni nazw CLR. Aby zamapować XmlnsDefinitionAttribute wiele przestrzeni nazw CLR do tej samej przestrzeni nazw XML, może istnieć więcej niż jeden. Po zmapowanych członkach using tych przestrzeni nazw można również odwoływać się bez pełnej kwalifikacji, jeśli jest to wymagane, podając odpowiednią instrukcje na stronie częściowej kodu. Aby uzyskać więcej informacji, zobacz: XmlnsDefinitionAttribute.

Przestrzenie nazw projektanta i inne prefiksy z szablonów XAML

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

WPF Designer for Visual Studio używa przestrzeni nazw projektanta, która jest zwykle mapowana na prefiks d:. Najnowsze szablony projektów dla platformy WPF mogą wstępnie mapować tę przestrzeń nazw XAML w celu obsługi wymiany kodu XAML między projektantem WPF dla Visual Studio i innych środowisk projektowych. 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 w przypadku funkcji takich jak d:IsDataSource, które umożliwiają źródła danych środowiska uruchomieniowego w projektancie.

Innym prefiksem, który może być zamapowany, jest mc:. mc: jest w celu zapewnienia zgodności ze znacznikami 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 związku z platformą WPF, zobacz Zgodność znaczników (mc:) Funkcje językowe.

WPF i ładowanie zestawu

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

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

  2. Jeśli nazwa jest kwalifikowana, wywołaj dla Assembly.Load(String) kwalifikowanej nazwy.

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

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

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

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

Skompilowany kod XAML dla WPF (generowany za pośrednictwem xamlBuildTask) nie używa już załadowanych zestawów AppDomain z (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 nie powinien również zawierać niekwalifikowanych nazw zestawu.

Zobacz też