точка в тегах XML - PullRequest
       4

точка в тегах XML

6 голосов
/ 11 октября 2009

Сейчас, изучая XAML, я продолжаю видеть теги XAML в формате Object.Attribute. Например:

 <Deployment.OutOfBrowserSettings>
     OutOfBrowserSettings ShortName="Hello World" >

Не помню, чтобы раньше видели такие атрибуты XML, всегда бы видели простые слова или, возможно, префикс столбца пространства имен, такой как x: application. Таким образом, для выражения отношения объект / атрибут, как описано выше, я ожидал бы такую ​​запись, как:

<Deployment>
   <OutOfBrowserSettings ShortName="Hello World" >

Итак, мой вопрос таков: каково значение «.» нотация внутри тегов XML. Какова семантика? Это специфично для XAML?

Ответы [ 4 ]

11 голосов
/ 11 октября 2009

Чтобы немного рассказать о том, что Алекс сказал:

Для XML нет значения точки в имени элемента. a, a., a.b и a.b.c являются допустимыми (и уникальными) именами элементов.

Для XAML , существует значительное значение для периода в имени элемента. По иронии судьбы рекомендация Алекса, предупреждающая вас об отказе от использования символов точки в вашем XML, в точности , почему XAML использует точки: так что XamlReader может определить, когда он видит first.name, что name является свойством объекта first. Следовательно:

<ListBox>
  <ListBox.BorderThickness>2</ListBox.BorderThickness>
  <ListBox.BorderBrush>Yellow</ListBox.BorderBrush>
  <TextBox>foo</TextBox>
  <TextBox>bar</TextBox>
  <TextBox>baz</TextBox>
</ListBox>

Почему ты не можешь просто сделать это?

<ListBox>
   <BorderThickness>2</BorderThickness>
   ...

Есть две причины. Первый - это простой дизайн XML: элементы XML могут содержать несколько элементов с одинаковыми именами. На самом деле плохая идея моделировать свойства как дочерние элементы, потому что тогда вам нужно обеспечить уникальность в вашей схеме или иметь правило, что делать со свойством объекта, когда есть несколько дочерних элементов с одинаковым именем:

<ListBox>
   <BorderThickness>2</BorderThickness>
   <BorderThickness>3</BorderThickness>
   <BorderThickness>4</BorderThickness>
   ...

Вот почему XAML моделирует свойства как атрибуты , для которых XML должен быть уникальным:

<ListBox BorderThickness='2' BorderBrush='Yellow'...

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

Другая причина состоит в том, что так много объектов WPF являются контейнерами других объектов. Если бы XAML позволял элементам представлять свойства, вы бы облажались, если бы вам нужно было представить объект, у которого было свойство с тем же именем, что и у класса объекта, который он мог содержать. Например, вы можете создать ItemsControl со свойством Label, но что произойдет, если вы захотите сохранить Label объекты в его свойстве Items? Эта неопределенность не может возникнуть в XAML:

<MyItemsControl>
   <MyItemsControl.Label>this is a property of MyItemsControl</MyItemsControl.Label>
   <Label>this is an item that MyItemsControl contains</Label>
</MyItemsControl>
2 голосов
/ 12 октября 2009

Обнаружил это сегодня в WPF в действии с Visual Studio 2008 Фельдмана и Даймона

4.2.3. Использование прикрепленных свойств

Возможно, вы заметили интересную вещь о значениях свойств в листинге 4.2. Такие свойства, как Width и Padding, выглядят как обычные атрибуты XML. Но обозначения свойств Left и Top немного отличаются:

<Button Canvas.Left="40" Canvas.Top="40" >

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

В «классическом» XML (то есть XML, который может быть проверен схемой), вам обычно приходится вводить элемент вокруг каждого дочернего элемента, чтобы указать свойства, специфичные для родительского элемента - что-то вроде листинга 4.3.

Листинг 4.3. Способ установки свойств для детей (но не поддерживается WPF)

<Canvas>
    <CanvasItem Left = "40" Top="40">
        <Button>Button1</Button>
    </CanvasItem>
</Canvas>

Этот подход будет работать, но он довольно многословен, особенно если у вас много вложенных элементов. Это также подразумевает иерархию, которой на самом деле не существует. Вместо того, чтобы требовать более подробного XML и заставить Canvas следовать структуре, которая, вероятно, ему не нужна, XAML вводит нотацию, которая позволяет определять свойства, принадлежащие родительскому элементу, на дочернем элементе с помощью точечной нотации:

<Canvas>
  <Button Canvas.Left="40" Canvas.Top="50">Button1</Button>
</Canvas>

Это должно читаться как «Когда вы добавляете кнопку на холст, скажите холсту, что кнопка должна быть расположена слева 40 и сверху 40». Эти свойства называются вложенными свойствами, потому что они прикреплены к дочернему элементу, к которому они относятся, даже если они принадлежат содержащему элемент управления (в данном случае Canvas). Вы увидите это обозначение в XAML для всех видов свойств. Вам просто нужно помнить, что свойства с точками посередине действительно задают значения, которые используются содержащим их элементом управления. Приятно то, что при редактировании свойств элемента управления в редакторе свойств вложенные свойства отображаются как часть набора свойств элемента управления

2 голосов
/ 11 октября 2009

Насколько я знаю, в XML нет никакого особого значения для * .. Другими словами, <a.b> отличается от тега <a>. Отношения в XAML - это семантика, понятная только синтаксическому анализатору XAML.

В отдельном примечании фрагмент вашего вопроса не XAML; это часть манифеста развертывания для приложения Silverlight. Однако, опять же, семантика '.' понимается анализатором манифеста, а не анализатором XML.

0 голосов
/ 11 октября 2009

Правила именования XML четко объяснены, например, здесь

XML элементы должны следовать этим именам правила:

  • Имена могут содержать буквы, цифры и другие символы
  • Имена не могут начинаться с цифры или знака пунктуации
  • Имена не могут начинаться с букв xml (или XML, или Xml и т. Д.)
  • Имена не могут содержать пробелы

Можно использовать любое имя, без слов зарезервирован.

URL, который я дал, продолжает рекомендации "передового опыта", которые включают

Избегайте "." персонажи. Если вы назовете что-то "first.name", какое-то программное обеспечение может думать, что «имя» является свойством объект "первый".

Но это всего лишь рекомендация (нарушение ее может затруднить использование вашего XML с определенным программным обеспечением), точно так же, как это делается с использованием -. Из этих рекомендаций единственным действительно важным является избегать использования : в именах XML (поскольку действительно конфликтует с пространствами имен XML! -).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...