Почему WPF использует вложенные свойства для таких вещей, как позиционирование в сетке?

Question

Зачем нам нужны «прикрепленные свойства»? Концепция этого немного меня беспокоит, так как вы можете задавать значения свойств, которые даже не существуют в конкретном DependencyObject (и они просто будут игнорироваться). Это почти кажется решением проблемы - почему бы просто не делать то, что, например, HTML имеет и имеет родительский элемент явно определять такие вещи, как позиционирование для детей?

То есть вместо:

<Grid>
  <Grid.ColumnDefinitions>
    <!-- etc. -->
  </Grid.ColumnDefinitions>
  <Grid.RowDefinitions>
    <!-- etc. -->
  </Grid.RowDefinitions>
  <SomeElement Grid.Column="0" Grid.Row="0" />
  <!-- etc. -->
</Grid>

Почему бы не что-то вроде этого (эквивалент <tr> и <td> в HTML):

<Grid>
  <Grid.Row>
    <Grid.Column>
      <SomeElement />
    </Grid.Column>
    <!-- etc. -->
  </Grid.Row>
</Grid>

Возможно, сетки - просто плохой пример, а присоединенные свойства имеют больше смысла в других контекстах? Или, может быть, я что-то упустил совсем?

Answer 1

Наиболее очевидная причина, по которой вам нужны прикрепленные свойства для размещения элементов в сетке, заключается в том, что вы можете использовать привязку:

<Grid.ItemContainerStyle>
   <Style TargetType="ContentPresenter">
      <Setter Property="Grid.Row" Value="{Binding Row}"/>
      <Setter Property="Grid.Column" Value="{Binding Column}"/>
   </Style>
</Grid.ItemContainerStyle>

Чтобы реализовать сопоставимую функциональность в HTML, вы должны написать код, который явно удаляет и повторно добавляет элемент при изменении номера строки и / или столбца.

Answer 2

Идея состоит в том, что элементам управления не нужно знать обо всех возможных контейнерах. Без прикрепленных свойств UIElement потребуется предоставить свойства, специфичные для каждого типа контейнера (Row, Column, Dock, Top, Left ...). Это сделало бы всю систему гораздо менее гибкой, поскольку новый тип контейнера не мог бы легко «добавлять» свойства к каждому элементу управления, который он содержит.

Answer 3

Не совсем ответ, но я бы сказал, что метод XAML легче читать и более интуитивно понятен, чем метод HTML при работе с большими сетками.Таблицы HTML могут быть проблемой в заднице.

Answer 4

Цитирование из Программирование WPF от Sells and Griffiths: (выделено мной)

Очевидным решением для базового класса, такого как FrameworkElement, было бы определение свойства Dock - все элементы пользовательского интерфейса WPF являются производными от FrameworkElement, так что это позволило бы чему-либо указать свою позицию стыковки. Однако DockPanel - это не единственный тип панелей, поэтому нам необходимо добавить свойства для других панелей. Это добавит много беспорядка . Хуже того, это также будет негибким - что, если вы захотите разработать пользовательскую панель, которая реализует какой-то новый механизм макета? Может потребоваться определить новые атрибуты для использования его дочерними элементами.

Прикрепленные свойства решают эту проблему. Они позволяют одному элементу определять свойства, которые можно «прикрепить» к другому элементу. DockPanel определяет свойство Dock, которое может применяться к любому дочернему элементу. В XAML синтаксис точечного атрибута (DockPanel.Dock) означает, что используется присоединенное свойство

Answer 5

Если TextBox имеет такие свойства, как Row и Column, это не будет иметь никакого смысла, если он не размещен непосредственно на любой панели.

Таким образом, они реализованы как прикрепленные свойства. Вы можете «прикрепить» их по мере необходимости. Если он находится на панели, такой как DockPanel, эти присоединенные свойства будут иметь смысл, иначе они не будут.

Надеюсь, я прояснил ситуацию.