Przestrzeń nazw XAML i mapowanie przestrzeni nazw dla WPF XAML

  • Artykuł

W tym temacie opisano obecność i przeznaczenie dwóch mapowań przestrzeni nazw XAML tak często, jak często w tagu głównym pliku WPF XAML. Opisano w nim również sposób tworzenia podobnych mapowań na potrzeby używania elementów zdefiniowanych we własnym kodzie i/lub w oddzielnych zestawach.

Co to jest przestrzeń nazw XAML

Przestrzeń nazw XAML jest naprawdę rozszerzeniem 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, przy użyciu prefiksów w celu zapewnienia środków odwołujących się do wielu przestrzeni nazw z tego samego źródła znaczników itd. Podstawową koncepcją dodaną do definicji XAML przestrzeni nazw XML jest to, że przestrzeń nazw XAML oznacza zarówno zakres unikatowości użycia znaczników, jak i wpływa na to, jak jednostki znaczników są potencjalnie wspierane przez określone przestrzenie nazw CLR i przywoływanych zestawów. Ta ostatnia kwestia ma również wpływ na koncepcję kontekstu schematu XAML. Jednak na potrzeby sposobu pracy WPF z przestrzeniami nazw XAML można ogólnie traktować przestrzenie nazw XAML pod względem domyślnej przestrzeni nazw XAML, przestrzeni nazw języka XAML i wszelkich kolejnych przestrzeni nazw XAML mapowanych przez znaczniki XAML bezpośrednio do określonych przestrzeni nazw CLR i przywoływanych zestawów.

Deklaracje przestrzeni nazw WPF i XAML

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

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

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

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

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

Konwencja x: prefiksu mapowania obsługi funkcji wewnętrznych języka XAML następuje po szablonach projektów, przykładowym kodzie i dokumentacji funkcji językowych w tym zestawie SDK. Przestrzeń nazw XAML definiuje wiele powszechnie używanych funkcji, które są niezbędne nawet w przypadku podstawowych aplikacji WPF. Aby na przykład dołączyć dowolny kod do pliku XAML za pomocą klasy częściowej, należy nazwać tę klasę jako x:Class atrybut w elemenie głównym odpowiedniego pliku XAML. Ewentualnie każdy element zdefiniowany na stronie XAML, do którego chcesz uzyskać dostęp jako zasób z kluczem, powinien mieć x:Key atrybut ustawiony na danym elemecie. Aby uzyskać więcej informacji na temat tych i innych aspektów języka XAML, zobacz XAML w składni WPF lub XAML w szczegółach.

Mapowanie na niestandardowe klasy i zestawy

Przestrzenie nazw XML można mapować na zestawy przy użyciu serii tokenów w xmlns ramach deklaracji prefiksu, podobnie jak standardowe przestrzenie nazw WPF i XAML XAML 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 zawierającym typy publiczne do uwidocznienia jako elementy.

assembly= Zestaw zawierający niektóre lub wszystkie odwołania do przestrzeni nazw CLR. Ta wartość jest zwykle tylko nazwą zestawu, a nie ścieżką i nie zawiera rozszerzenia (takiego jak .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 mapować. W celu uwzględnienia podpisywania wersji i podpisywania assembly silnej nazwy wartość może być ciągiem zdefiniowanym przez AssemblyName, a nie 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 używany między tymi dwoma tokenami jest średnikiem. Ponadto nie umieszczaj żadnych białych znaków w dowolnym miejscu w deklaracji.

Podstawowy przykład 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 w bibliotece, która dla ustawień projektu (nie pokazano) ma nazwę SDKSampleLibrary.

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

Teraz, gdy masz bibliotekę zawierającą klasę i odwołanie do niej 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 połączyć to wszystko, poniżej przedstawiono kod XAML, który zawiera mapowanie niestandardowe wraz z typowymi domyślnymi i x: mapowaniami w tagu głównym, a następnie używa prefiksu odwołania do wystąpienia ExampleClass 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 clr-namespace odwołanie jest definiowane w tym samym zestawie co kod aplikacji odwołujące się do klas niestandardowych. Alternatywną składnią dla tego przypadku jest określenie assembly=wartości , bez tokenu ciągu po znaku równości.

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

Mapowanie przestrzeni nazw CLR na przestrzenie nazw XML w zestawie

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

Parametr XmlnsDefinitionAttribute przyjmuje dwa parametry: nazwę przestrzeni nazw XML/XAML i nazwę przestrzeni nazw CLR. Istnieje więcej niż jeden, XmlnsDefinitionAttribute aby zamapować wiele przestrzeni nazw CLR na tę samą przestrzeń nazw XML. Po zamapowanym elementy członkowskie tych przestrzeni nazw mogą być również przywoływane bez pełnej kwalifikacji, podając odpowiednią using instrukcję na stronie kodowej klasy częściowej. Aby uzyskać więcej informacji, zobacz: .

Projektant przestrzeni nazw i innych prefiksów z szablonów XAML

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

WPF Projektant dla programu Visual Studio używa przestrzeni nazw projektanta, która jest zwykle mapowana na prefiks d:. Nowsze szablony projektów dla platformy WPF mogą wstępnie mapować tę przestrzeń nazw XAML w celu obsługi wymiany kodu XAML między Projektant WPF dla programu Visual Studio i innych środowisk projektowych. Ten projekt przestrzeni nazw XAML służy do utrwalania stanu projektu podczas zaokrąglania 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.

Inny prefiks, który może zostać zamapowany, to mc:. mc: jest przeznaczony dla zgodności znaczników i wykorzystuje wzorzec zgodności znaczników, który nie musi być specyficzny dla języka XAML. W pewnym stopniu funkcje zgodności znaczników mogą służyć do wymiany kodu XAML między strukturami lub w innych granicach implementacji tworzenia kopii zapasowych, pracy między kontekstami schematu XAML, zapewnienia zgodności dla ograniczonych trybów w projektantach itd. Aby uzyskać więcej informacji na temat pojęć dotyczących zgodności znaczników i ich powiązania z platformą WPF, zobacz Markup Compatibility (mc:) Language Features (Funkcje języka mc:).

Ładowanie WPF i zestawu

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

  1. Iteruj AppDomainprzez element , wyszukując już załadowany zestaw zgodny ze wszystkimi aspektami nazwy, począwszy od ostatnio załadowanego zestawu.

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

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

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

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

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

Skompilowany kod XAML dla platformy WPF (wygenerowany za pośrednictwem biblioteki XamlBuildTask) nie używa już załadowanych zestawów ( 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 (wygenerowany za pomocą elementu PresentationBuildTask) używa wszystkich kroków, chociaż baML nie powinien zawierać również niekwalifikowanych nazw zestawów.

Zobacz też