WPF, Основи XAML
Стандарт XAML досить очевидний, якщо зрозуміти кілька його основних правил:
Кожен елемент у документі XAML відображається на екземпляр класу .NET. Ім'я елемента точно відповідає імені класу. Наприклад, елемент повідомляє WPF, що має бути створений об'єкт Button.
Як і будь-який XML-документ, код XAML допускає вкладення одного елемента всередину іншого. Як буде показано, XAML надає кожному класу гнучкість у прийнятті рішення щодо того, як упоратися з такою ситуацією. Однак вкладення зазвичай є способом виразити включення (containment). Іншими словами, якщо ви бачите елемент Button всередині елемента Grid, то інтерфейс користувача, можливо, включає Grid, що містить у собі Button.
Властивості кожного класу можна встановити через атрибути. Тим не менш, в деяких ситуаціях атрибути не досить потужні, щоб упоратися з цією роботою. У цих випадках знадобляться вкладені дескриптори із спеціальним синтаксисом.
Визначення MainWindow у XAML
Хоча інструменти можуть генерувати прийнятний код XAML, все ж таки важливо розуміти основи синтаксису XAML і те, як розмітка в кінцевому підсумку трансформується в коректне складання .NET. Погляньте на наступний найпростіший документ XAML, що представляє нове порожнє вікно (як воно створено Visual Studio):
У контексті дескриптора, що відкриває, задані значення для атрибутів Title, Height і Width, які безпосередньо відображаються на однойменні властивості, що підтримуються типом System.Windows.Window зі збірки PresentationFramework.dll.
Простір імен XAML
Зрозуміло, що мало просто вказати ім'я класу. Аналізатору XAML також потрібно знати простір імен .NET, де знаходиться цей клас. Наприклад, клас Window можеіснувати в кількох просторах імен - він може посилатися на клас System.Windows.Window, на клас у компоненті від незалежного розробника або на клас, визначений у вашому додатку. Щоб визначити, який саме клас насправді потрібен, аналізатор XAML перевіряє простір імен XML, до якого належить елемент.
Ось як це працює. У прикладі документа, показаному раніше, визначено два простори імен:
Простір імен оголошуються за допомогою атрибутів. Ці атрибути можуть бути розміщені всередині початкового дескриптора будь-якого елемента. Однак згідно з прийнятими угодами всі простори імен, які потрібно використовувати в документі, мають бути оголошені в першому дескрипторі, як це зроблено в даному прикладі. Як тільки простір імен оголошено, він може використовуватись у будь-якому місці документа.
Основний простір імен WPF. Воно охоплює всі класи WPF, включаючи елементи управління, які застосовуються для побудови інтерфейсів користувача (System.Windows, System.Windows.Controls, System.Windows.Data, System.Windows.Ink, System.Windows.Media, System.Windows.Navigation ). У цьому прикладі цей простір імен оголошено без префікса простору імен, тому стає простором імен за замовчуванням для всього документа. Іншими словами, кожен елемент автоматично поміщається в цей простір імен, якщо не зазначено інше.
http://schemas.microsoft.com/winfx/2006/xaml
Простір імен XAML. Воно включає різні службові властивості XAML, які дозволяють впливати на те, як інтерпретується документ. Цей простір імен відображається на префікс х. Це означає, що його можна застосовувати, поміщаючи префікс простору імен перед ім'ям елемента (як ).
Як бачите,простір імен XML не відповідає певному простору імен .NET. Існує кілька причин, через які творці XML обрали таке проектне рішення. За існуючою згодою простору імен XML часто мають форму URI (як і в даному прикладі). Ці URI виглядають так, ніби вказують на деяке місце в Інтернеті, хоч насправді це не так. Формат URI використовується тому, що робить малоймовірним ситуацію, коли різні організації ненавмисно створять різні мови на базі XML з однаковим простором імен. Оскільки домен schemas.microsoft.com належить Microsoft, лише Microsoft використовує його в назві простору імен XML.
Інша причина відсутності відображення "один до одного" між просторами імен XML, що використовуються в XAML, та просторами імен .NET полягає в тому, що це могло б значно ускладнити документи XAML. Проблема в тому, що WPF містить понад десять просторів імен (усі починаються з System.Windows). Якби кожен простір імен .NET відображався на окремий простір імен XML, довелося б вказувати коректний простір імен для кожного елемента керування, що використовується, що швидко призвело б до плутанини. Натомість творці WPF воліли скомбінувати всі ці простори імен .NET в єдиний простір імен XML. Це працює, тому що всередині різних просторів імен .NET, що утворюють частину WPF, немає класів з однаковими іменами.
Інформація простору імен дозволяє аналізатору XAML знаходити правильний клас. Наприклад, коли він переглядає елементи Window та Grid, то бачить, що вони поміщені у простір імен WPF за промовчанням. Потім він шукає відповідні простори імен .NET - до тих пір, поки не знаходить System.Windows.Window і System.Windows.Controls.Grid.
Додаткові дескриптори XAML
Тепер, якщо необхідно створити новий екземпляр Window, який використовує ці елементи, можна встановити спеціальний простір імен XML, що відображається на бібліотеку MyControls.dll, з використанням лексемclr-namespace таassembly.
Нижче наведено приклад розмітки, що створює префікс дескриптора, який може застосовуватись для доступу до членів цієї бібліотеки:
Лексемі clr-namespace присвоюється назва простору імен .NET у складання, тоді як лексема assembly встановлюється у дружнє ім'я зовнішнього складання *.dll. Такий синтаксис можна використовувати для будь-якої зовнішньої бібліотеки .NET, яку необхідно маніпулювати всередині розмітки.