Udostępnij za pomocą

Przestrzenie nazw XAML i mapowanie przestrzeni nazw

W tym temacie wyjaśniono mapowania przestrzeni nazw XML/XAML (xmlns) występujące w elemencie głównym większości plików XAML. W tym artykule opisano również sposób tworzenia podobnych mapowań dla typów niestandardowych i zestawów.

Jak przestrzenie nazw XAML odnoszą się do bibliotek definicji kodu i typów

Zarówno w ramach ogólnego przeznaczenia, jak i dla aplikacji do programowania aplikacji środowiska uruchomieniowego systemu Windows, język XAML służy do deklarowania obiektów, właściwości tych obiektów i relacji właściwości obiektów wyrażonych jako hierarchie. Obiekty zadeklarowane w języku XAML są wspierane przez biblioteki typów lub inne reprezentacje zdefiniowane przez inne techniki programowania i języki. Te biblioteki mogą być następujące:

  • Wbudowany zestaw obiektów dla środowiska uruchomieniowego systemu Windows. Jest to stały zestaw obiektów, a uzyskiwanie dostępu do tych obiektów z języka XAML korzysta z wewnętrznego mapowania typów i logiki aktywacji.
  • Biblioteki rozproszone udostępniane przez firmę Microsoft lub przez inne firmy.
  • Biblioteki, które reprezentują definicję kontrolki innej firmy, są zintegrowane z aplikacją i które są redystrybuowane w twoim pakiecie.
  • Twoja własna biblioteka, która jest częścią projektu i która zawiera niektóre lub wszystkie definicje kodu użytkownika.

Informacje o typie pomocniczym są skojarzone z określonymi definicjami przestrzeni nazw XAML. Struktury XAML, takie jak środowisko uruchomieniowe systemu Windows, mogą agregować wiele zestawów i wiele przestrzeni nazw kodu do mapowania na jedną przestrzeń nazw XAML. Umożliwia to pojęcie słownictwa XAML obejmującego większą strukturę programowania lub technologię. Słownictwo XAML może być dość obszerne — na przykład większość kodu XAML udokumentowanego dla aplikacji środowiska uruchomieniowego systemu Windows w tej dokumentacji stanowi pojedyncze słownictwo XAML. Słownictwo XAML jest również rozszerzalne: Można je rozszerzyć, dodając typy do wspierającego kodu, upewniając się, że typy są umieszczone w przestrzeniach nazw, które już służą jako zamapowane źródła przestrzeni nazw dla słownictwa XAML.

Procesor XAML może wyszukać typy i elementy członkowskie z zestawów zapasowych skojarzonych z tą przestrzenią nazw XAML podczas tworzenia reprezentacji obiektu w czasie wykonywania. Dlatego język XAML jest przydatny jako sposób sformalizowania i wymiany definicji zachowania konstrukcji obiektów oraz dlaczego język XAML jest używany jako technika definicji interfejsu użytkownika dla aplikacji środowiska uruchomieniowego systemu Windows.

Przestrzenie nazw XAML w typowym użyciu języka znaczników XAML

Plik XAML prawie zawsze deklaruje domyślną przestrzeń nazw XAML w swoim elemercie głównym. Domyślna przestrzeń nazw XAML definiuje, które elementy można zadeklarować bez kwalifikowania ich przez prefiks. Jeśli na przykład zadeklarujesz element , analizator XAML będzie oczekiwać, że element <Balloon />Balloon istnieje i jest prawidłowy w domyślnej przestrzeni nazw XAML. Natomiast jeśli balon nie znajduje się w zdefiniowanej domyślnej przestrzeni nazw XAML, należy zamiast tego zakwalifikować tę nazwę elementu z prefiksem, na przykład <party:Balloon />. Prefiks wskazuje, że element istnieje w innej przestrzeni nazw XAML niż domyślna przestrzeń nazw, i przed użyciem tego elementu należy zamapować przestrzeń nazw XAML na prefiks. Przestrzenie nazw XAML mają zastosowanie do określonego elementu, na którym są zadeklarowane, a także do każdego elementu zawartego przez ten element w strukturze XAML. Z tego powodu przestrzenie nazw XAML są prawie zawsze deklarowane na elementach głównych pliku XAML, aby skorzystać z tego dziedziczenia.

Domyślne i językowe XAML deklaracje przestrzeni nazw XAML

W elemecie głównym większości plików XAML istnieją dwie deklaracje xmlns . Pierwsza deklaracja mapuje przestrzeń nazw XAML jako domyślną: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Jest to ten sam identyfikator przestrzeni nazw XAML używany w kilku poprzednich technologiach firmy Microsoft, które również używają języka XAML jako formatu znaczników definicji interfejsu użytkownika. Użycie tego samego identyfikatora jest celowe i jest przydatne podczas migrowania wcześniej zdefiniowanego interfejsu użytkownika do aplikacji środowiska uruchomieniowego systemu Windows przy użyciu języka C++, C# lub Visual Basic.

Druga deklaracja mapuje oddzielną przestrzeń nazw XAML dla elementów zdefiniowanych przez XAML, mapując ją (zwykle) na prefiks "x:": xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Ta wartość xmlns oraz prefiks "x:", na który jest mapowana, są również identyczne z definicjami stosowanymi w kilku wcześniejszych technologiach Microsoftu wykorzystujących XAML.

Relacja między tymi deklaracjami polega na tym, że XAML jest definicją języka, a środowisko uruchomieniowe systemu Windows jest jedną implementacją, która używa języka XAML jako języka i definiuje określone słownictwo, w którym odwołuje się do jego typów w języku XAML.

Język XAML określa pewne elementy języka, a każdy z nich powinien być dostępny za pośrednictwem implementacji procesora XAML działających w przestrzeni nazw XAML. Po konwencji mapowania "x:" dla przestrzeni nazw XAML języka XAML następuje szablony projektów, przykładowy kod i dokumentacja funkcji językowych. Przestrzeń nazw języka XAML definiuje kilka powszechnie używanych funkcji, które są niezbędne nawet w przypadku podstawowych aplikacji środowiska Uruchomieniowego systemu Windows. Aby na przykład dołączyć dowolny kod do pliku XAML za pośrednictwem klasy częściowej, musisz nazwać tę klasę jako atrybut x:Class w elemecie głównym odpowiedniego pliku XAML. Lub dowolny element zdefiniowany na stronie XAML jako zasób kluczowany w odwołaniach do zasobów ResourceDictionary i XAML musi mieć atrybut x:Key ustawiony na dany element obiektu.

Przestrzenie nazw kodu mapujące na domyślną przestrzeń nazw XAML

Poniżej znajduje się lista przestrzeni nazw kodu, które są aktualnie przypisane do domyślnej przestrzeni nazw XAML.

  • 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

Inne przestrzenie nazw XAML

Oprócz domyślnej przestrzeni nazw i przestrzeni nazw języka XAML "x:", możesz również zobaczyć inne zmapowane przestrzenie nazw XAML w początkowym domyślnym pliku XAML dla aplikacji generowanych przez Microsoft Visual Studio.

d: (http://schemas.microsoft.com/expression/blend/2008)

Przestrzeń nazw XAML "d:" jest przeznaczona do obsługi projektanta, a w szczególności obsługi projektanta na powierzchniach projektowych XAML programu Microsoft Visual Studio. Przestrzeń nazw XAML "d:" umożliwia atrybuty projektanta lub czasu projektowania dla elementów XAML. Te atrybuty projektanta mają wpływ tylko na aspekty projektowania sposobu działania kodu XAML. Atrybuty projektanta są ignorowane, gdy ten sam kod XAML jest ładowany przez analizator XAML środowiska uruchomieniowego systemu Windows po uruchomieniu aplikacji. Ogólnie rzecz biorąc, atrybuty projektanta są prawidłowe dla dowolnego elementu XAML, ale w praktyce istnieją tylko pewne scenariusze, w których zastosowanie atrybutu projektanta jest odpowiednie. W szczególności wiele atrybutów projektanta ma na celu zapewnienie lepszego środowiska interakcji z kontekstami danych i źródłami danych podczas opracowywania kodu XAML i kodu używającego powiązania danych.

  • d:DesignHeight i d:DesignWidth jako atrybuty: Te atrybuty są czasami stosowane do elementu głównego pliku XAML tworzonego przez program Visual Studio lub inne narzędzie projektanta XAML. Na przykład, te atrybuty są ustawiane w elemencie głównym UserControl utworzonego kodu XAML, jeśli dodasz nowy element UserControl do projektu aplikacji. Te właśnie atrybuty ułatwiają projektowanie kompozycji zawartości XAML, dzięki czemu można przewidzieć pewne ograniczenia układu, które mogą wystąpić w przypadku użycia zawartości XAML jako elementu kontrolnego lub innej części większej strony interfejsu użytkownika.

    Uwaga Jeśli migrujesz kod XAML z programu Microsoft Silverlight, możesz mieć te konkretne atrybuty na elementach głównych reprezentujących całą stronę interfejsu użytkownika. W tym przypadku możesz usunąć atrybuty. Inne funkcje projektantów XAML, takie jak symulator, są prawdopodobnie bardziej przydatne do projektowania układów stron, które obsługują skalowanie i wyświetlanie stanów dobrze niż jest układ strony o stałym rozmiarze przy użyciu d:DesignHeight i d:DesignWidth.

  • d:DataContext, atrybut: Ten atrybut można ustawić w elemencie nadrzędnym strony lub kontrolce, aby zastąpić dowolny jawny lub dziedziczony DataContext, który ten obiekt posiada.

  • d:DesignSource, atrybut: Określa w czasie projektowania źródło danych dla elementu CollectionViewSource, nadpisując źródło.

  • d:DesignInstance oraz d:DesignData: te rozszerzenia znaczników udostępniają zasoby danych czasu projektowania dla d:DataContext lub d:DesignSource. W tym miejscu nie będziemy w pełni dokumentować, jak używać zasobów danych czasu projektowania. Aby uzyskać więcej informacji, zobacz Design-Time Atrybuty. Aby zapoznać się z przykładami użycia, zobacz Przykładowe dane na powierzchni projektowej i do tworzenia prototypów.

mc: (http://schemas.openxmlformats.org/markup-compatibility/2006)

"mc:" wskazuje i obsługuje tryb zgodności znaczników do odczytywania kodu XAML. Zazwyczaj prefiks "d:" jest skojarzony z atrybutem mc:Ignorable. Ta technika umożliwia parserom XAML w czasie działania pomijanie atrybutów projektowych oznaczonych "d:".

lokalne: i typowe:

"local:" to prefiks, który jest często mapowany na stronach XAML dla szablonowego projektu aplikacji platformy UWP. Jest mapowany tak, aby odwoływał się do tej samej przestrzeni nazw, która została utworzona, aby zawierała atrybut x:Class i kod dla wszystkich plików XAML, w tym app.xaml. Tak długo, jak definiujesz dowolne klasy niestandardowe, których chcesz używać w języku XAML w tej samej przestrzeni nazw, możesz użyć lokalnego prefiksu: do odwoływania się do typów niestandardowych w języku XAML. Powiązany prefiks pochodzący z szablonowego projektu aplikacji platformy UWP jest typowy: Ten prefiks odnosi się do zagnieżdżonej przestrzeni nazw "Common", która zawiera klasy użytkowe, takie jak konwertery i polecenia. Definicje można znaleźć w folderze Common w Eksploratorze rozwiązań.

vsm:

Nie używaj. "vsm:" to prefiks, który czasami występuje w starszych szablonach XAML importowanych z innych technologii firmy Microsoft. Przestrzeń nazw pierwotnie zajmowała się problemem związanym z narzędziami do obsługi starszych przestrzeni nazw. Należy usunąć definicje przestrzeni nazw XAML dla elementu "vsm:" w dowolnym kodzie XAML używanym dla środowiska uruchomieniowego systemu Windows i zmienić wszelkie użycia prefiksów dla visualState, VisualStateGroup i powiązanych obiektów, aby zamiast tego używać domyślnej przestrzeni nazw XAML. Aby uzyskać więcej informacji na temat migracji XAML, zobacz Migrowanie środowiska Silverlight lub WPF XAML/code do aplikacji środowiska uruchomieniowego systemu Windows.

Mapowanie typów niestandardowych na przestrzenie nazw i prefiksy XAML

Możesz przypisać przestrzeń nazw XAML, aby móc używać języka XAML do uzyskiwania dostępu do własnych typów zdefiniowanych. Innymi słowy, mapujesz przestrzeń nazw kodu, ponieważ istnieje w reprezentacji kodu, która definiuje typ niestandardowy, i przypisujesz jej przestrzeń nazw XAML wraz z prefiksem do użycia. Typy niestandardowe dla języka XAML można zdefiniować w języku Microsoft .NET (C# lub Microsoft Visual Basic) albo w języku C++. Mapowanie jest wykonywane przez zdefiniowanie prefiksu xmlns . Na przykład xmlns:myTypes definiuje nową przestrzeń nazw XAML dostępną przez prefiksowanie wszystkich użycia za pomocą tokenu myTypes:.

Definicja xmlns zawiera wartość, a także nazewnictwo prefiksów. Wartość jest ciągiem znaków, który znajduje się wewnątrz cudzysłowów, po znaku równości. Typowa konwencja XML polega na skojarzeniu przestrzeni nazw XML z identyfikatorem URI (Uniform Resource Identifier), dzięki czemu istnieje konwencja unikatowości i identyfikacji. Zobaczysz również tę konwencję dla domyślnej przestrzeni nazw XAML i przestrzeni nazw XAML języka XAML, a także dla niektórych mniej używanych przestrzeni nazw XAML używanych przez środowisko uruchomieniowe systemu Windows XAML. Jednak w przypadku przestrzeni nazw XAML, która mapuje typy niestandardowe, zamiast określać identyfikator URI, należy rozpocząć definicję prefiksu z tokenem "using:". Po tokenie "using:" należy nazwać przestrzeń nazw kodu.

Aby na przykład zamapować prefiks "custom1", który umożliwia odwołanie do przestrzeni nazw "CustomClasses" i używać klas z tej przestrzeni nazw lub zestawu jako elementów obiektów w języku XAML, strona XAML powinna zawierać następujące mapowanie elementu głównego: xmlns:custom1="using:CustomClasses"

Częściowe klasy tego samego zakresu strony nie muszą być mapowane. Na przykład nie potrzebujesz prefiksów, aby odwoływać się do żadnych programów obsługi zdarzeń zdefiniowanych do obsługi zdarzeń z definicji interfejsu użytkownika XAML strony. Ponadto wiele początkowych stron XAML z wygenerowanych projektów programu Visual Studio dla aplikacji Środowiska uruchomieniowego systemu Windows mapuje już prefiks "local:", który odwołuje się do domyślnej przestrzeni nazw określonej przez projekt i przestrzeni nazw używanej przez definicje klas częściowych.

Reguły języka CLR

Jeśli piszesz kod zapasowy w języku .NET (C# lub Microsoft Visual Basic), możesz użyć konwencji, które używają kropki (".") jako części nazw przestrzeni nazw, aby utworzyć koncepcyjną hierarchię przestrzeni nazw kodu. Jeśli definicja przestrzeni nazw zawiera kropkę, kropka powinna być częścią wartości określonej po tokenie "using:".

Jeśli plik code-behind lub plik definicji kodu jest plikiem C++, istnieją pewne konwencje, które nadal są zgodne ze wspólnym środowiskiem uruchomieniowym (CLR), co zapewnia, że nie ma różnicy w składni XAML. Jeśli zadeklarowano zagnieżdżone przestrzenie nazw w języku C++, separator między kolejnymi ciągami zagnieżdżonej przestrzeni nazw powinien mieć wartość ".", a nie "::", gdy określisz wartość zgodną z tokenem "using:".

Nie używaj zagnieżdżonych typów (takich jak zagnieżdżanie wyliczenia w klasie) podczas definiowania kodu do użycia z językiem XAML. Nie można przeanalizować typów zagnieżdżonych. Nie ma możliwości, aby analizator XAML rozróżniał, że kropka należy do nazwy typu zagnieżdżonego, a nie do nazwy przestrzeni nazw.

Typy niestandardowe i zestawy

Nazwa zestawu, który definiuje typy wspierające dla przestrzeni nazw XAML, nie jest określona w mapowaniu. Logika, dla której dostępne są zestawy, jest kontrolowana na poziomie definicji aplikacji i jest częścią podstawowych zasad wdrażania aplikacji i zabezpieczeń. Zadeklaruj zestaw, który ma zostać dołączony jako źródło definicji kodu dla języka XAML jako zestaw zależny w ustawieniach projektu. Aby uzyskać więcej informacji, zobacz Tworzenie składników środowiska uruchomieniowego systemu Windows w językach C# i Visual Basic.

Jeśli odwołujesz się do typów niestandardowych z definicji aplikacji podstawowej lub definicji strony, te typy są dostępne bez dalszej konfiguracji zestawu zależnego, ale nadal musisz zamapować przestrzeń nazw kodu zawierającą te typy. Typową konwencją jest mapować prefiks "local" dla domyślnej przestrzeni nazw kodu każdej strony XAML. Ta konwencja jest często zawarta w początkowych szablonach projektów dla projektów z użyciem XAML.

Dołączone właściwości

Jeśli odwołujesz się do dołączonych właściwości, część typu właściciela dołączonej nazwy właściwości musi znajdować się w domyślnej przestrzeni nazw XAML lub być poprzedzona prefiksem. Rzadko zdarza się, że atrybuty występują z prefiksami oddzielnie od elementów, ale w tym przypadku jest to czasami wymagane, zwłaszcza dla niestandardowej dołączonej właściwości. Aby uzyskać więcej informacji, zobacz Niestandardowe dołączone właściwości.

  • Last updated on