Синтаксис атрибутов

Нетрудно было заметить, что во многих случаях при использовании элемента для представления объекта (с помощью синтаксиса объектных элементов) также применяются и атрибуты для указания свойств и событий. Например, в приведенном ранее элементе <Button> использовались такие атрибуты:

<Button Height= 23 HorizontalAlignment= Left Margin= 85,О,86,16 Name= toggleButton VerticalAlignment= Bottom Width= 75 Content= Toggle Click= toggleButton Click />

Здесь все атрибуты, кроме атрибута Click, который назначает объекту toggleButton обработчик маршрутизируемых событий для обработки его событий Click, и атрибута Name, задают значение для соответствующего свойства объекта toggleButton и являются примером синтаксиса атрибутов.

Атрибут Name здесь представляет собой особый случай и задает для элемента управления идентификатор, чтобы на него можно было ссылаться из отделенного и другого XAML-кода.

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

<Button Height= 23 HorizontalAlignment= Left Margin= 85,О,86,16 Name= toggleButton VerticalAlignment= Bottom Width= 75 Content= Toggle ButtonBase. Cliclc= toggleButton Cliclc />

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

Синтаксис элементов свойств

Во многих случаях для инициализации значения свойства требуется использовать нечто большее, чем простую строку. В примере приложения так было со свойствами Fill, которые устанавливались в различные объекты кисти:

<Ellipse .. .>

<Ellipse.Fill> <RadialGradientBrush> <GradientStop Color= #FFOOOOOO Offset= l /> <GradientStop Color= #FFFFFFFF Offset= 0.306 /> </RadialGradientBrush> </Ellipse.Fill> </Ellipse>

Здесь значение для свойства устанавливается с помощью дочернего элемента, имя которого соответствует следующему соглашению:

[Имя родительского элемента] . [Имя свойства]

Этот синтаксис и называется синтаксисом элементов свойств.

Синтаксис содержимого

Многие элементы управления часто представляют то или иное содержимое, которое затем отображается на экране в соответствии с их шаблоном. Например, содержимое, предоставляемое для элемента управления Button, отображается на поверхности

кнопки. Это может быть как обычный текст, как это и было в примере, так и какой-то графический объект.

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

<Button . ..>Go</Button>

Этот код предназначен для элемента управления Button и указывает, что тот при визуализации должен отображать на своей поверхности текст Go. В приведенном в качестве примера приложении для этого применялся более простой, хотя и менее гибкий, способ, а именно - атрибут Content. Полную версию синтаксиса содержимого, вроде той, что показана здесь, необходимо использовать только для представления более сложного содержимого, например, для представления графических объектов, о которых упоминалось во вводной части этого раздела.

Применение сложного содержимого для элемента управления может приводить к образованию сложных вложенных иерархий XAML-кода. Из-за этого XAML позволяет осуществлять стилизацию элементов управления с помощью других, более усовершенствованных средств. Больше о представлении содержимого и стилизации элементов управления будет рассказываться позже в этой главе, в разделе Стилизация элементов управления .

Смешивание синтаксиса элементов свойств и синтаксиса содержимого

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

□ Элементы, используемые для синтаксиса элементов свойств, вовсе необязательно должны следовать строго друг за другом, т.е. допускается, чтобы за элементом, в котором используется синтаксис свойств, шел элемент, в котором применяется синтаксис содержимого, а за ним - снова элемент, в котором используется синтаксис свойств.

□ Элементы (и, если возможно, текстовое содержимое), используемые для синтаксиса содержимого, должны строго следовать друг за другом, т.е. не допускается, чтобы за текстом или элементом, в котором применяется синтаксис содержимого, следовал элемент, в котором используется синтаксис свойств, а за ним - снова элемент, в котором используется синтаксис содержимого или текст.

Следовательно, этот код является допустимым:

<Button . . .> <Button.BitmapEffect>

<OuterGlowBitmapEffeet GlowColor= Blue GlowSize= 10 /> </Button.BitmapEffeet> Go

<Button.RenderTransform>

<RotateTransform Angle= 20 /> </Button.RenderTransform> </Button>

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

<Button ...> Don t

<Button.BitmapEffeet>

<OuterGlowBitmapEffeet GlowColor= Red GlowSize= 10 />

</Button.BitmapEffeet>

</Button>

Расширения разметки

Пример показал, как расширения разметки могут также использоваться для значений свойств - например, значения {x:null}. Везде, где встречаются фигурные скобки ({}), применяются расширения разметки (markup extension). Они могут применяться как в коде с синтаксисом атрибутов, так и в коде с синтаксисом элементов свойств.

Все расширения разметки в этой главе относятся конкретно к WPF. Расширения WPF применяются для ссылки на ресурсы и для привязки данных.

Настольные приложения и Web-приложения

Приведенный ранее в главе пример продемонстрировал, что WPF-приложение может работать и как автономное настольное приложение, и как Web-приложение. В этом примере мы использовали шаблоны проектов WPF Application и WPF Browser Application в качестве отправной точки, а для завершения приложения просто добавили в них соответствующий код XAML и С#. Компиляция шаблона проекта WPF Application привела к получению файла . ехе, а проекта WPF Browser Application - к получению файла . хЬар.

ХВАР- это акроним от XAML Browser Application (Браузерное приложение на языке XAML), и из-за него Web-приложения, создаваемые с помощью WPF, часто называют ХВАР-приложе-ниями.

Большая часть отличий между приложениями этих типов состоит в разнице между файлами проектов (.csproj ). У приложений WPF Browser здесь имеется несколько дополнительных определяемых параметров, в том числе параметров для подписывания, как приложения, так и его манифеста (из упоминавшихся ранее соображений безопасности), и параметров для включения отладки в браузере. Еще есть, как отмечалось ранее, тестовый сертификат, который можно применять для подписывания. В производственной среде этот сертификат должен быть заменен сертификатом своего центра сертификации.

Преобразование настольного приложения WPF в Web-приложение WPF может оказаться делом кропотливым, поскольку требует изменения немалого количества параметров, а также (как показывалось в примере) внесения определенных изменений в XAML-код. В число этих изменений входит замена элементов <Window> элементами <Раде> и удаление функциональных возможностей, вроде растровых эффектов. Обычно наилучшим подходом является создание отдельных проектов, как это и было сделано в предыдущем примере. Однако существуют и альтернативные варианты. Пожалуй, наилучшее решение пока что было реализовано Карэн Корби (Karen Corby) и доступно в ее сетевом дневнике по адресу http: scorbs.com/2006/06/04/ vs-template-f lexible-application/. Карэн создала гибкий шаблон приложения, который можно использовать вместо стандартных шаблонов WPF Application и WPF Browser Application. Этот шаблон позволяет переключаться между настольной и Web-версией приложения с помощью специального раскрывающегося списка конфигураций в IDE-среде. На него действительно стоит взглянуть тем, кто планирует часто переключаться между типами приложений, хотя на практике разработчики все же предпочитают выбирать только какую-то одну среду и работать в ней.