Przestrzenie nazw XAML i mapowanie przestrzeni nazw dla języka WPF XAML
W tym temacie opisano obecność i przeznaczenie dwóch odwzorowań przestrzeni nazw XAML, które często znajdują się w znaczniku korzenia 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 obejmuje zarówno unikalność w użyciu znaczników, jak i wpływa na sposób, w jaki jednostki znaczników są potencjalnie wspierane przez określone przestrzenie nazw CLR i referencjonowane zestawy. Ta ostatnia kwestia ma również wpływ na koncepcję kontekstu schematu XAML. Jednak dla celów zrozumienia, jak WPF pracuje z przestrzeniami nazw XAML, można ogólnie postrzegać je w kontekście domyślnej przestrzeni nazw XAML, przestrzeni nazw języka XAML oraz dodatkowych przestrzeni nazw XAML, które są mapowane 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 prefiks x:.
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Relacja między tymi deklaracjami polega na tym, że mapowanie prefiksów x: 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 prefiksu x: dla mapowania elementów wewnętrznych języka XAML jest przestrzegana przez szablony projektów, przykładowy kod i dokumentację 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 atrybut x:Class w elemecie 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ć atrybut x:Key ustawiony dla danego elementu. Aby uzyskać więcej informacji na temat tych i innych aspektów języka XAML, zobacz XAML w WPF lub XAML szczegóły składni.
Mapowanie na niestandardowe klasy i zestawy
Proposed Translation: Przestrzenie nazw XML można mapować na zestawy przy użyciu serii tokenów w ramach deklaracji prefiksu xmlns, podobnie jak standardowe przestrzenie nazw WPF i 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, który zawiera publiczne typy do eksponowania 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ć. Aby włączyć wersjonowanie i podpisywanie silną nazwą, wartość assembly może być ciągiem zdefiniowanym przez AssemblyName, a nie prostą nazwą ciągu.
Należy pamiętać, że znak oddzielający token clr-namespace od jego wartości jest dwukropkiem (:) natomiast znak oddzielający token assembly od jego wartości jest znakiem równości (=). Znakiem do użycia między tymi dwoma tokenami jest średnik. 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 zgodnie z ustawieniami projektu (nie pokazano) nosi nazwę SDKSampleLibrary.
Aby odwołać się do tej klasy niestandardowej, należy ją również uwzględnić jako odwołanie do bieżącego projektu, który zwykle wykonuje się przy użyciu interfejsu użytkownika Eksploratora 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 prefiksowanego odwołania do tworzenia 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 do aktualnych asemblacji
assembly można pominąć, jeśli clr-namespace, do którego się odwołuje, jest definiowany w tym samym zestawie co kod aplikacji, który odwołuje się do klas niestandardowych. Alternatywną składnią dla tego przypadku jest określenie assembly=, bez ciągu znaków 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 przestrzeń 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, do przestrzeni nazw http://schemas.microsoft.com/winfx/2006/xaml/presentation.
XmlnsDefinitionAttribute przyjmuje dwa parametry: nazwę przestrzeni nazw XML/XAML i nazwę przestrzeni nazw CLR. Może istnieć więcej niż jeden XmlnsDefinitionAttribute, aby zmapować wiele przestrzeni nazw CLR na tę samą przestrzeń nazw XML. Po dokonaniu mapowania, elementy członkowskie tych przestrzeni nazw mogą być również przywoływane bez pełnej kwalifikacji, podając odpowiednią instrukcję using na stronie kodu-behind 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 deweloperskimi i/lub narzędziami projektowymi dla języka WPF XAML, możesz zauważyć, że istnieją inne zdefiniowane przestrzenie nazw/prefiksy XAML w kodzie XAML.
Projektant WPF 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 projektantem WPF dla programu Visual Studio i innymi środowiskami projektowymi. Ten znacznik przestrzeni nazw XAML dla projektowania służy do zachowania stanu projektowania podczas przetwarzania zwrotnego interfejsu użytkownika opartego na 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 zostać zmapowany, jest mc:.
mc: jest zgodna ze znacznikami 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 XAML między frameworkami lub w innych kontekstach implementacji, współdziałania między kontekstami schematów XAML, zapewnienia zgodności dla ograniczonych trybów w narzędziach projektowych, itd. Aby uzyskać więcej informacji na temat pojęć zgodności znaczników i jak są one związane z platformą WPF, zobacz Funkcje językowe zgodności znaczników (mc:).
WPF i ładowanie zestawów
Kontekst schematu XAML dla platformy WPF integruje się z modelem aplikacji WPF, który z kolei używa zdefiniowanej przez clR koncepcji AppDomain. Sekwencja przedstawiona poniżej opisuje, w jaki sposób kontekst schematu XAML interpretuje proces ładowania zestawów lub znajdowania typów w czasie wykonywania lub projektowania, opierając się na zastosowaniu AppDomain w WPF oraz innych czynnikach.
Iteruj przez AppDomain, szukając już załadowanego zestawu, który pasuje do wszystkich aspektów nazwy, zaczynając od ostatnio załadowanego zestawu.
Jeśli nazwa jest kwalifikowana, wywołaj Assembly.Load(String) w kwalifikowanej nazwie.
Jeśli krótka nazwa i token klucza publicznego nazwy kwalifikowanej pasują do zestawu, z którego ten znacznik został załadowany, zwróć ten zestaw.
Użyj krótkiej nazwy i tokenu klucza publicznego, aby wywołać Assembly.Load(String).
Jeśli nazwa jest niewykwalifikowana, wywołaj Assembly.LoadWithPartialName.
Luźny kod XAML nie używa kroku 3; nie ma załadowanego zestawu.
Skompilowany kod XAML dla WPF (wygenerowany 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 BAML (wygenerowany za pomocą elementu PresentationBuildTask) używa wszystkich kroków, chociaż BAML nie powinien również zawierać niekwalifikowanych nazw zestawów.
Zobacz też
.NET Desktop feedback