Пространства имен XAML и их сопоставление

  • Статья

В данном разделе объясняется сопоставление пространств имен XML/XAML (xmlns) в корневом элементе большинства файлов XAML. Здесь также описывается, как выполнять подобное сопоставление для настраиваемых типов и сборок.

Связь пространств имен XAML с библиотеками определений кода и типов

Как в рамках основного назначения, так и в применении к программированию приложений среды выполнения Windows язык XAML используется для объявления объектов, свойств этих объектов и отношений между объектами и свойствами, выраженных в виде иерархий. Объекты, которые вы объявляете в XAML, резервируются библиотеками типов или другими представлениями, которые определяются другими методиками и языками программирования. Эти библиотеки могут быть:

  • Встроенным набором объектов для среды выполнения Windows. Это фиксированный набор объектов, для доступа к которым из XAML применяется внутреннее сопоставление типов и логика активации.
  • Распространяемыми библиотеками, поставляемыми Microsoft либо сторонними поставщиками.
  • Библиотеками, представляющими определение элемента управления стороннего поставщика, который входит в ваше приложение и вторично распространяется вашим пакетом.
  • Вашей собственной библиотекой, которая является частью вашего проекта и содержит некоторые или все пользовательские определения кода.

Резервный тип связан с конкретными определениями пространства имен XAML. Платформы XAML, такие как среда выполнения Windows, могут объединять несколько сборок и несколько пространств имен кода, сопоставляемых с одним пространством имен XAML. Это задействует концепцию словаря XAML, который охватывает более широкую часть платформы или технологию программирования. Словарь XAML может быть достаточно обширным, например, большая часть языка XAML, задокументированная для приложений среды выполнения Windows, составляет один словарь XAML. Словарь XAML также можно расширять путем добавления типов в определения резервного кода. При этом необходимо включить типы в пространства имен кода, которые уже используются в качестве источников сопоставленного пространства имен для словаря XAML.

Процессор XAML может искать типы и члены в резервных сборках, связанных с этим пространством имен XAML, когда он создает представление объекта среды выполнения. Поэтому XAML удобен в качестве способа формализации и обмена определениями поведения объекта при создании, и поэтому XAML используется в качестве техники определения пользовательского интерфейса для приложений UWP.

Пространства имен XAML при стандартном использовании исправлений XAML

В корневом элементе XAML-файла почти всегда объявляется пространство имен XAML по умолчанию. Пространство имен XAML по умолчанию определяет, какие элементы можно объявить без указания уточняющего префикса. Например, если вы объявляете элемент <Balloon />, средство синтаксического анализа XAML предполагает, что элемент Balloon существует и является действительным в пространстве имен XAML, используемом по умолчанию. Если же Balloon не входит в определенное пространство имен XAML по умолчанию, необходимо указывать имя этого элемента с префиксом, например <party:Balloon />. Префикс указывает на то, что элемент существует в пространстве имен XAML, отличном от пространства имен по умолчанию, и вам нужно сопоставить пространство имен XAML с префиксом party перед тем, как использовать данный элемент. Пространства имен XAML относятся к определенному элементу, на котором они были объявлены, а также к любому элементу, который содержится в этом элементе в структуре XAML. По этой причине пространства имен XAML практически всегда объявляются на корневых элементах XAML-файла, чтобы воспользоваться преимуществами этого наследования.

Объявления пространства имен XAML по умолчанию и на языке XAML

В корневом элементе большинства XAML-файлов находятся два объявления xmlns. Первое объявление сопоставляет пространство имен XAML как пространство имен по умолчанию: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Этот же идентификатор пространства имен XAML использовался в нескольких предшествующих технологиях Microsoft, которые также используют XAML в качестве формата разметки определений пользовательского интерфейса. Тот же самый идентификатор используется преднамеренно. Это удобно при переносе ранее определенного пользовательского интерфейса в приложение среды выполнения Windows на C++, C# или Visual Basic.

Второе объявление сопоставляет отдельное пространство имен XAML для элементов языка, определяемых XAML, сопоставляя его (обычно) с префиксом x:: xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Это значение xmlns и префикс x:, с которым оно сопоставляется, также идентичны определениям, использованным в нескольких предшествующих технологиях Microsoft, использующих XAML.

Взаимосвязь между двумя этими объявлениями заключается в том, что XAML является языковым определением, а среда выполнения Windows является реализацией, использующей XAML в качестве языка, определяя конкретный словарь, в котором ее типы указываются на языке XAML.

Язык XAML определяет конкретные языковые элементы, каждый из которых должен быть доступен через реализации процессора XAML, работающие на фоне пространства имен XAML. Соглашению о сопоставлении префикса x: для пространства имен XAML на XAML следуют шаблоны проекта, пример кода и документация для языковых компонентов. Пространство имен языка XAML определяет несколько часто используемых компонентов, которые необходимы даже для основных приложений среды выполнения Windows на C++, C# или Visual Basic. Например, чтобы присоединить любой файл кода программной части к файлу XAML через разделяемый класс, необходимо назвать этот класс так же, как атрибут x:Class в корневом элементе соответствующего файла XAML. Или же любой элемент, определенный на странице XAML как ключевой ресурс в Справочниках по ResourceDictionary и ресурсу XAML, должен иметь атрибут x:Key, установленный для данного элемента объекта.

Пространства имен кода, сопоставленные с пространством имен XAML по умолчанию

Folowing — это список пространств имен кода, которые в настоящее время сопоставлены с пространством имен 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

Другие пространства имен XAML

Помимо пространства имен по умолчанию и пространства имен языка XAML x: существуют и другие сопоставленные пространства имен XAML в первоначальном языке XAML, использованном по умолчанию для приложений в Microsoft Visual Studio.

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

Пространство имен XAML d: предназначено для поддержки конструктора — в частности, в рабочих областях конструирования XAML Microsoft Visual Studio. Пространство имен XAML d: включает атрибуты конструктора или времени разработки в элементах XAML. Эти атрибуты конструктора влияют только на аспекты разработки, связанные с поведением XAML. Атрибуты конструктора игнорируются, когда тот же XAML загружается средством синтаксического анализа XAML среды выполнения Windows при запуске приложения. В целом атрибуты конструктора можно применять в любом элементе XAML, но на практике применять атрибут конструктора самостоятельно целесообразно только в определенных случаях. В частности, многие из атрибутов конструктора предназначены для улучшения взаимодействия с контекстами данных и источниками данных, если вы работаете с XAML и кодом, которые используют привязку данных.

  • Атрибуты d:DesignHeight и d:DesignWidth Эти атрибуты иногда применяются к корню XAML-файла, который создает для вас Visual Studio или другая поверхность конструктора XAML. Например, эти атрибуты задаются в корне UserControl XAML, создаваемого при добавлении нового UserControl в проект приложения. Эти атрибуты упрощают разработку композиции содержимого XAML, и вы можете предвидеть ограничения разметки, которые могут существовать, если это содержимое XAML используется для экземпляра элемента управления или другой части более крупной страницы пользовательского интерфейса.

Примечание При переносе XAML из Microsoft Silverlight эти атрибуты могут содержаться в корневых элементах, представляющих всю страницу пользовательского интерфейса. Возможно, в этом случае атрибуты потребуется удалить. Другие функции конструкторов XAML, такие как имитатор, возможно, более полезны для разработки макетов страниц, которые обрабатывают состояния масштабирования и просмотра лучше, чем макет страницы фиксированного размера, использующий d:DesignHeight и d:DesignWidth.

  • Атрибут d:DataContext Этот атрибут можно задать в корне страницы или элементе управления для переопределения любого явного или унаследованного DataContext, в противном случае находящегося в объекте.
  • Атрибут d:DesignSource Указывает источник данных времени разработки для CollectionViewSource, переопределяя Source.
  • Расширения разметки d:DesignInstance и d:DesignData Эти расширения разметки используются для предоставления ресурсов данных времени разработки для d:DataContext или d:DesignSource. В этом разделе не приводится подробное описание использования ресурсов данных времени разработки. Подробнее см. в разделе Атрибуты времени разработки. Примеры использования см. в разделе Демонстрационные данные в рабочей области конструирования и для создания прототипов.

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

mc: обозначает и поддерживает режим совместимости исправлений для чтения XAML. Обычно префикс d: связан с атрибутом mc:Ignorable. Данный метод позволяет средствам синтаксического анализа XAML среды выполнения игнорировать атрибуты конструктора в d:.

local: и common:

Префикс local: часто задается автоматически в составе XAML-страниц для проекта приложения UWP, создаваемого по шаблону. Он ссылается на то же пространство имен, которое создается для размещения атрибута x:Class и кода для всех XAML-файлов, включая app.xaml. Если в этом пространстве имен вы определите все пользовательские классы, которые будут использоваться в XAML, то префикс local: позволит ссылаться на ваши настраиваемые типы в коде XAML. В проектах приложений UWP, создаваемых по шаблону, используется связанный префикс common:. Он ссылается на вложенное пространство имен Common, которое содержит служебные классы, например конвертеры и команды, и вы можете найти определения в папке Common в представлении Обозреватель решений.

vsm:

Не используйте. vsm: — это префикс, который иногда встречается в старых шаблонах XAML, импортированных из других технологий Microsoft. Пространство имен первоначально решало проблему средств устаревших пространств имен. Вы должны удалить определения пространства имен XAML для vsm: в любом коде XAML, который вы применяете для среды выполнения Windows, и вместо префикса для VisualState, VisualStateGroup и связанных объектов использовать пространство имен XAML по умолчанию. Подробнее о переносе кода XAML: Перенос кода XAML для Silverlight или WPF в приложение среды выполнения Windows.

Сопоставление настраиваемых типов с пространствами имен XAML и префиксами

Вы можете сопоставить пространство имен XAML таким образом, чтобы можно было использовать XAML для доступа к вашим настраиваемым типам. Другими словами, вы сопоставляете пространство имен кода в том виде, как оно существует в представлении кода, которое определяет настраиваемый тип, и присваиваете ему пространство имен XAML наряду с префиксом для использования. Настраиваемые типы для XAML можно определить либо на языке .NET Microsoft (C# или Microsoft Visual Basic), либо на C++. Сопоставление производится путем определения префикса xmlns. Например, xmlns:myTypes определяет новое пространство имен XAML, доступ к которому осуществляется через определение префиксов для всех применений с токеном myTypes:.

Определение xmlns включает значение и наименование префикса. Это значение является строкой внутри кавычек, которая идет после знака равенства. Обычное соглашение XML заключается в том, чтобы связать пространство имен XML с универсальным кодом ресурса (URI), так что соглашение существует для целей уникальности и идентификации. Вы также можете видеть это соглашение для пространства имен XAML по умолчанию и пространства имен XAML на языке XAML, а также для более редких пространств имен XAML, которые используют XAML среды выполнения Windows. Но для пространства имен XAML, которое сопоставляет настраиваемые типы, вместо указания универсального кода ресурса (URI) определение префикса начинается с токена using:. После using: вы присваиваете имя пространству имен кода.

Например, чтобы сопоставить префикс custom1, который позволяет ссылаться на пространство имен CustomClasses, и использовать классы из этого пространства имен или сборки в качестве объектных элементов в XAML, страница XAML должна содержать следующее сопоставление корневого элемента: xmlns:custom1="using:CustomClasses"

Разделяемые классы той же самой области страницы не должны сопоставляться. Например, вам не нужны префиксы для ссылок на любые обработчики событий, которые вы определили для обработки событий из определения пользовательского интерфейса XAML вашей страницы. Также многие из стартовых страниц XAML проектов, созданных в Visual Studio для приложений среды выполнения Windows на C++, C# или Visual Basic, уже сопоставляют префикс local:, который ссылается на пространство имен, определенное по умолчанию для проекта, с пространством имен, используемым определениями разделяемого класса.

Языковые правила среды CLR

Если вы пишете резервный код на .NET (C# или Microsoft Visual Basic), вы, возможно, применяете соглашения, которые используют точку (".") как часть названий пространств имен для создания концептуальной иерархии пространств имен кода. Если ваше определение пространства имен содержит точку, тогда точка должна быть частью значения, которое вы указываете после токена using:.

Если ваш файл кода программной части или файл определения кода написан на языке C++, существуют определенные соглашения, которые по-прежнему следуют языковым формам среды CLR, поэтому в синтаксисе XAML нет расхождений. Если вы объявляете вложенные пространства имен в C++, то в качестве разделителя между последовательными вложенными строками пространства имен нужно использовать ".", а не "::" при определении значения, следующего за токеном using:.

Не используйте вложенные типы (например, перечисление, вложенное в класс), когда код определяется для использования в XAML. Вложенные типы не поддерживают вычисление. Средство синтаксического анализа XAML не имеет возможности отличить точку, отделяющую имя вложенного типа, от точки, отделяющей часть имени пространства имен.

Настраиваемые типы и сборки

Имя сборки, которая определяет резервные типы в пространстве имен XAML, не указывается при сопоставлении. Логика, для которой доступны сборки, контролируется на уровне определения приложения и является частью основных принципов развертывания и защиты приложения. Объявляйте любую сборку, которую вы хотите включить в качестве источника определения кода для XAML, как зависимую сборку в параметрах проекта. Подробнее об этом см. в разделе Создание компонентов среды выполнения Windows на C# и Visual Basic.

Если вы ссылаетесь на настраиваемые типы из первичного определения приложения или определений страницы, эти типы доступны без дальнейшей конфигурации зависимой сборки, но вы по-прежнему должны сопоставить пространство имен кода, которое содержит эти типы. Обычным соглашением устанавливается сопоставление префикса local для пространства имен кода любой взятой страницы XAML, устанавливаемого по умолчанию. Это соглашение часто включается в стартовые шаблоны проектов XAML.

Присоединенные свойства

Когда вы упоминаете присоединенное свойство, часть его имени, относящаяся к типу владельца, должна находиться в пространстве имен XAML по умолчанию либо снабжаться префиксом. Атрибуты редко получают префиксы отдельно от своих элементов, однако в данном случае это иногда необходимо, особенно для пользовательских присоединенных свойств. Подробнее см. в разделе Пользовательские присоединенные свойства.