NamespaceCzęść NR.2Najbardziej tajemniczą różnica pomiędzy kodem XAML  a kodem C# jest widoczna w przestrzeniach nazw.

Przykładowo w poprzednim wpisie w deklaracji przycisku pojawił się następująca właściwość xmlns.

 

<Button xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
        Content="Hello" />

Ten tajemniczy napis “http://schemas.microsoft.com/winfx/2006/xaml/presentation” mapuje .NET przestrzeń nazw System.Windows.Controls. A w niej znajduje się definicja kontrolki “Button”.

Bez z tej przestrzeni nazw kod XAML nie rozpoznaje wyrażenia “Button”.

image

Jak się okazuje to mapowanie do “System.Windows.Controls” w WPF jest zakodowane bezpośrednio w jego w bibliotekach. Oczywiście pod adresem “http://schemas” nie ma żadnej strony internetowej. Dla pliku XML tak się deklaruje przestrzenie nazw. A skoro XAML bazuje na XML nic więc dziwnego ,że ten mechanizm jest identyczny.

Lista zmapowanych .NET przestrzeni nazw

Alternate Text WPF mapuje następujące .NET-owe przestrzenie nazw na jedną XML-ową przestrzeń nazw “(http://schemas.microsoft.com/winfx/2006/xaml/presentation)”.

. System.Windows
. System.Windows.Automation
. System.Windows.Controls
. System.Windows.Controls.Primitives
. System.Windows.Data
. System.Windows.Documents
. System.Windows.Forms.Integration
. System.Windows.Ink
. System.Windows.Input
. System.Windows.Media
. System.Windows.Media.Animation
. System.Windows.Media.Effects
. System.Windows.Media.Imaging
. System.Windows.Media.Media3D
. System.Windows.Media.TextFormatting
. System.Windows.Navigation
. System.Windows.Shapes
. System.Windows.Shell

Jak widać mamy tutaj relację jedną do wielu. Ponieważ istnieje jedna przestrzeń nazw XML twórcy WPF musieli się postarać aby nie stworzyć dwóch takich samych klas o tej samej nazwie pomimo tego iż w .NET-owych bibliotekach mają one różne przestrzenie.

Główny człon elementu pliku XAML musi określić przynajmniej jedną XML przestrzeń nazw. Ta przestrzeń nazw może być później używana przez wszystkie elementy zawierające się w nim oraz przez sam element główny.

<Window x:Class="WpfApplication4.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <Grid>
        <Button Content="Hello" />
    </Grid>
</Window>

Jeśli utworzysz nowy projekt w WPF zauważysz ,że wszystkie przestrzenie nazw są zadeklarowane w elemencie głównym “Window”. Przestrzenie nazw nie muszą być potem powtarzane więc bez problemu mogą dodać przycisk.

Oprócz deklaracji przestrzeni nazw mamy także inne wyrażenie. Wygląda ono podobnie do zwykłej deklaracje ,ale z jakiegoś powodu występuje tam “x”.

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

W XAML można deklarować wiele przestrzeń nazw ,ale każda następna musi mieć jakiś prefix. Dla drugie domyślnej przestrzeni jest zarezerwowany prefiks “:x”. (czyli zamiast wyrażenia xmlns mamy wyrażenie xmlns:x)

http://schemas.microsoft.com/winfx/2006/xaml mapuje się nie tylko do .NET przestrzeni nazwy System.Windows.Markup. Mapuje ona także specjalne dyrektywy dla języka XAML jako kompilatora oraz parsera.

Te dyrektywy są zazwyczaj zwykłymi atrybutami elementu XML więc wyglądają one jak właściwości tych elementów ,ale tak naprawdę tak nie jest. Pełnią one bardzo dużo różnych funkcji i ciężko jest umieścić do jednego worka.

Lista tych dyrektyw jest całkiem spora.

Na początek może spojrzeć na poniższe przykłady ,ale omówimy je szerzej później.

Słowo kluczowePrawidłowa jakoZnaczenie
x:NameAtrybut każdego elementu niegłównego. Musi on być użyty z x:Class.Określa on nazwę elementu dla wygenerowanego dla niego pola. Dzięki temu możemy odwołać się do niego w kodzie w proceduralnym.
x:KeyAtrybut użyty dla elementów dziedziczących po Interfejsie IDictionaryOkreśla on klucz danego elementu, który został dodany do słownika.
x:ClassAtrybut elementu głównego.Definiuje on klasę

 

Druga przestrzeń nazw ma więc prefiks “x”. Sam prefiks nie zmienia funkcjonalności przestrzeni zmienia jej tylko odwołanie. Oto klasyczny już przykład z przyciskiem, dla którego najważniejsza XML przestrzeń nazw dostała prefiks “Cezary”.

<Cezary:Button xmlns:Cezary="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
        Content="Hello" />

Elementy z przestrzeni nazw “(http://schemas.microsoft.com/winfx/2006/xaml/presentation)” są najczęściej używane . Logiczne nieprawdaż ,że akurat ta przestrzeń nie ma żadnego prefiksa oraz w sobie zawiera wiele referencji do różnych .NET-owych przestrzeni nazw. Dodatkowe prefiksy zniszczyłby czytelność kodu XAML.

Jeśli w kodzie mamy prefiksy inne niż “x” to wiemy ,że nasz kod XAML korzysta z jakiegoś elementu niestandardowego i łatwo nam go znaleźć go właśnie po prefiksie.

Konwencja prefiksu jest podobna do tej z przestrzeni nazw .NET.

XAML-owe przestrzenie nazw oraz wersje WPF i Silverlight,WinRT

PytanieMogłoby się wydawać ,że istnieje tylko jedna uniwersalna przestrzeń nazw do określenia najważniejszy właściwości WPF-a ,ale tak nie jest.

W WPF 3.0 pojawiła się przestrzeń nazwy “http://schemas.microsoft.com/winfx/2006/xaml/” . Pomimo nazwy numerycznej WPF 3.0 był pierwszą wersją WPF-a.

W WPF 3.5 jednak została przedstawiona alternatywna przestrzeń nazw “http://schemas.microsoft.com/netfx/2007/xaml/presentation”, która mapuje te same typy. Dlaczego nazwa została zmieniona z winfx na netfx? Nazwa winfx określała sporą grupę technologii .NET (WPF,WCF,WF), które właśnie zaczęły egzystować w .NET 3.0. Termin został porzucony więc z stąd zmiana na netfx.

WPF 4.0 przedstawił kolejną alternatywną przestrzeń nazw: “http://schemas.microsoft.com/netfx/2009/xaml/presentation”.

Pomimo tych wszystkich opcji najlepiej trzymać się oryginalnej przestrzeni nazw “http://schemas.microsoft.com/winfx/2006/xaml/” .

Działa ona w każdej wersji WPF. Oczywiście mówi tutaj o samej przestrzeni nazw. Jeśli korzystasz z funkcjonalności, która pojawiła się w WPF 4.0 naturalnie nie użyjesz jej w WPF 3.5 i niżej.

Silverlight i WinRT także korzystają z tej domyślnej przestrzeni nazw. Każda z technologii ma jednak swoje alternatywne przestrzenie nazwy, które nie są wspierane przez pozostałe technologie.

Silverlight: http://schemas.microsoft.com/client/2007

Przestrzenie nazw XML są dosyć zakłopotane. Nie są one schematami XML. Nie reprezentują one zamkniętego zbioru typów.

Każda wersja technologii referuje się do swoich poprzednich przestrzeń nazw XML-owych. Oczywiście biblioteki ulegają zmianie. Chcę jednak zwrócić uwagę na to ,że plik XAML z przestrzenią nazw “http://schemas.microsoft.com/netfx/2009/xaml/presentation“ będzie odczytany tylko w wersji WPF 4.0 lub następnej.

W następnej części opowiem o właściwościach elementów w XAML.