Глава 1. Модель приложения Longhorn
Глава 1. Модель приложения Longhorn
Брент Настойт
Мудрый овся консультации
Октябрь 2003 г.
Содержание
Функции модели приложения Longhorn
Класс приложения
Класс NavigationApplication
Расширяемый язык разметки приложения (XAML)
Сводка
Почему нам нужна новая модель приложения? Одна из основных причин заключается в том, чтобы преодолеть разрыв между разработкой приложения для Microsoft® Windows® и разработкой приложения для Интернета.
Сегодня при написании приложения Windows вы можете воспользоваться преимуществами функций Windows. Ваше приложение может предоставить широкий пользовательский интерфейс. Приложение можно установить на клиентском компьютере, что позволяет приложению работать в автономном режиме без сетевого подключения. Приложения Windows могут воспользоваться аппаратными возможностями клиентского компьютера.
Однако традиционные приложения Windows также имеют ряд недостатков. Обычно необходимо установить приложение Windows. Это делает приложение и все обновления сложными для развертывания. Приложения Windows не выполняются в браузере. Таким образом, знакомые парадигмы веб-интерфейса, такие как приложения, ориентированные на страницы, навигация непосредственно с одной страницы на другую, журнал страниц и многое другое недоступно для приложения, если вы не создаете их с нуля. Приложения Windows также не поддерживают текст очень хорошо, особенно при попытке смешивать текст и графику на той же странице. Создание приложения Windows, которое автоматически перемещает текст вокруг графики и реагирует на изменения, инициированные пользователем, в размере окна и предпочтениях пользователей для шрифтов и удобочитаемости является огромным объемом работы.
Веб-приложения также имеют свои собственные сильные стороны. При переходе на веб-страницу браузер скачивает только эту страницу и компоненты, необходимые для страницы. При переходе на новую страницу браузер скачивает требования новой страницы. Другими словами, браузер постепенно загружает приложение по мере необходимости.
Развертывание веб-приложения является тривиальным. Какое развертывание? Вы помещаете необходимые компоненты приложения на сервер, а браузер загружает их по мере необходимости. Развертывание не существует в каждом из вариантов.
Создание пользовательского интерфейса для веб-приложения также довольно просто. Вы объявляете свои намерения с помощью разметки. Например, предположим, что я хочу таблицу в определенной позиции. Я хочу, чтобы изображение следовало за таблицей. Я хочу, чтобы текст протекал по изображению. Сочетание текста, графики и мультимедиа (звук и видео) в веб-приложении является простым.
Конечно, веб-приложения также имеют свои плохие моменты. Не удается установить веб-приложение на классической системе; таким образом, приложение не может работать в автономном режиме. Необходимо всегда иметь подключение к серверу. Для некоторых операций приложений требуется циклический обход на сервер, что снижает производительность. Выбор веб-приложения элементов управления довольно примитивен по сравнению с доступными элементами управления Windows. Поэтому веб-приложение обычно имеет низкую интерактивность. Кроме того, трудно разработать привлекательный пользовательский интерфейс для веб-приложения, так как необходимо выразить любой нетривиальный макет с помощью таблиц.
В настоящее время разработчикам, разрабатывающим новые приложения, необходимо принять первоначальное, огромное, необратимое решение: должно ли приложение быть веб-приложением или классическим приложением Microsoft Win32®? Полностью отдельные модели программирования (и навыки!) требуются в зависимости от выбранной модели приложения.
Longhorn позволяет разрабатывать приложения, используя лучшие из обоих миров. Модель приложения Longhorn принимает лучшие функции веб-приложений и лучшие функции приложений Windows и объединяет их в единой унифицированной модели программирования на основе управляемого кода.
Вторая основная причина разработки новой модели приложения заключается в том, чтобы обеспечить единую модель программирования, которая может создавать широкий спектр "приложений" в настоящее время. Посмотрите на один из ваших любимых веб-сайтов, таких как CNN или MSNBC. Является ли веб-сайт традиционным приложением? Это документ? Это мультимедийная презентация? Во многих случаях ответ да для всех трех вопросов.
Если веб-сайт включает такие элементы пользовательского интерфейса, как поля списка, элементы управления редактирования и переключатели, это выглядит как приложение, представляющее пользовательский интерфейс. Однако при отображении изображений и текста вокруг изображений веб-сайт похож на документ. Когда он представляет содержимое Flash, графику, аудио, видео и анимацию, веб-сайт, кажется, является мультимедийной презентацией.
Конечно, такие богатые веб-сайты трудно разрабатывать. Необходимо установить вместе описание разметки HTML, используя элементы управления Microsoft ActiveX® для расширенного пользовательского интерфейса, встроенные анимации Flash и, возможно, использование переносимого формата документа (PDF) для поддержки документов. Все эти технологии используют другую архитектуру, предоставляют различные характеристики производительности и требуют различных моделей программирования и инструментов.
Обычно это означает, что для разработки каждой части приложения необходимо нанять нескольких разработчиков с различными наборами навыков. Затем разработчики должны объединить разные модели в одно рабочее приложение. Разработка приложения достаточно сложна. Отладка часто является кошмаром.
Longhorn предоставляет единую архитектуру, которая поддерживает эти три уровня: документы, приложения и носители. Создать пользовательский интерфейс декларативно с помощью разметки? Иди к нему. Вам нужно использовать расширенные элементы управления Windows? Тогда сделайте это! Хотите ли создавать обработчики событий в строго типизированном управляемом языке? Это также можно сделать. Вы хотите смешивать текст, графику и видео в документе с интеллектуальным макетом и презентацией в соответствии с предпочтениями пользователя и оптимизированы для лучшего просмотра и чтения в клиентской системе? Угадай, что? Ты тоже получаешь это.
Модель приложения Longhorn позволяет написать приложение с помощью одной модели программирования, которая поддерживает функциональность пользовательского интерфейса в стиле приложения, представление текста и графики, а также интеграцию различных носителей. Кроме того, вы можете создать пользовательский интерфейс с помощью разметки, например веб-приложения. Вы также получаете простоту развертывания (или отсутствия развертывания) веб-приложения. Однако у вас по-прежнему есть производительность и возможность установки приложения для автономного использования, например приложения Windows. Приложение может работать как автономное приложение или размещено в веб-браузере, просто перекомпиляя одну базу исходного кода. В любом случае приложение может быть основано на формах, например многих традиционных приложений Windows или на основе страниц, таких как веб-приложения.
Функции модели приложения Longhorn
Модель приложения Longhorn определяет, что такое приложение:
- Его точки входа
- Его поток управления — переход с одной страницы на другую
- Общее состояние и ресурсы
- События на уровне приложений
- Изоляция от других приложений
Модель приложения Longhorn определяет, как развертывать и поддерживать приложение:
- Развертывание в виде одного или нескольких файлов
- Обновление, откат и администрирование
Модель приложения Longhorn определяет взаимодействие пользователя с приложением:
- Установка без влияния
- Автономный (стиль Windows) или интегрированный в браузере
- Работает в сети или в автономном режиме
- Модель навигации
Веб-приложения Longhorn
Модель приложения Longhorn позволяет создавать полнофункциональные приложения аналогично тому, как вы пишете современные веб-приложения. Это обеспечивает простой путь миграции для веб-разработчиков, так как код, который они пишут, аналогичен коду для динамических веб-страниц HTML (DHTML). Они могут (сдрогать) размещать разметку и скрипт в одном файле. Они могут развертывать файлы приложения на веб-сервере. Страницы приложения выполняются в веб-браузере.
Однако объектная модель для веб-приложения Longhorn гораздо проще и гораздо более мощна, чем DHTML. Код приложения может использовать полный уровень презентации Longhorn. Поэтому веб-приложение Longhorn может использовать расширенные клиентские элементы управления, поддерживать мультимедиа и графику на странице, обрабатывать события локально— в основном все, что может сделать обычное клиентское приложение. На самом деле веб-приложение Longhorn не отличается от классического приложения Longhorn, отличного от того, что файлы живут на сервере; обычно браузер, но не обязательно, размещает пользовательский интерфейс; и приложение выполняется с ограниченными разрешениями, так как пользователь не установил его в клиентской системе.
Классические приложения Longhorn
Модель приложения Longhorn также определяет способ записи классических приложений. "Longhorn"классическое приложение — это приложение, установленное пользователем локально. Такие приложения могут запускаться в сети или в автономном режиме. Такие приложения могут регистрироваться в оболочке, размещать значки на рабочем столе, добавлять ярлыки в меню "Пуск" и многое другое.
Классическое приложение также может работать в окне браузера или в автономном окне. На самом деле классическое приложение может поддерживать многие функции, традиционно связанные с веб-приложением, в том числе следующие:
- Явным образом определяются внешние точки входа, то есть могут начинаться на любой странице.
- Общий доступ к состоянию между страницами
- Обработка различных событий, включая события навигации по страницам
- Управление потоком приложений
- Добавление и удаление записей из журнала страницы или журнала навигации по путешествиям
- Запуск окон приложений
Создание приложения Longhorn
Чтобы создать приложение Longhorn, необходимо определить объектную модель для приложения. Модель можно определить программным способом, написав код или декларативно, написав разметку на языке, называемом языком расширяемой разметки приложений (XAML). Код и (или) разметка компилируются в одну или несколько сборок .NET, файл манифеста приложения и файл манифеста развертывания.
При необходимости можно упаковить приложение в новый формат файла, который называется контейнером. Файлы приложения в контейнере могут быть сжаты, зашифрованы и цифрово подписаны.
Я подробно обсуждаю создание приложения Longhorn в главе 2, но на данный момент основной идеей является то, что создание приложения Longhorn предоставляет код приложения, манифест приложения, описывающий все компоненты, которые использует приложение, и манифест развертывания, который сообщает системе, как установить и поддерживать приложение.
Развертывание приложения Longhorn
Модель приложения Longhorn обеспечивает простое и экономичное развертывание приложения. В самом простом случае вы просто копируете файлы приложения на сервер. Аналогичным образом установка приложения проста и не влияет.
Один из вариантов заключается в том, чтобы не устанавливать приложение вообще. Пользователь может перейти к манифесту приложения на сервере и запустить его. Longhorn постепенно загружает приложение и выполняет его. Вы не получаете никаких требований подтверждения, не требуется перезагрузка и нет ада библиотеки DLL. На самом деле вам даже не нужны права администратора для установки или запуска приложения.
Кроме того, пользователь может перейти к манифесту развертывания приложения на сервере и запустить его. Longhorn постепенно загружает приложение, устанавливает его и выполняет. По умолчанию все приложения Longhorn выполняются в ограниченной среде разрешений, называемой средой безопасного выполнения (SEE).
Приложения, работающие в SEE, получают ограниченный набор разрешений, который примерно эквивалентен разрешениям, предоставленным сегодняшним приложениям, связанным с зоной Интернета. Приложение, требующее дополнительных разрешений, чем "Longhorn", предоставляется по умолчанию, должно запрашивать эти дополнительные разрешения в манифесте приложения.
При первом запуске такого приложения диспетчер доверия Longhorn оценивает запрос разрешений с повышенными привилегиями, уведомляет пользователя о предлагаемом уровне риска, связанном с предоставлением запроса на разрешение приложения, и предоставляет предлагаемый ответ на этот уровень риска. Когда пользователь разрешает диспетчеру доверия предоставлять приложению свои запрошенные разрешения, диспетчер доверия записывает эти сведения. Последующие выполнения установленного приложения продолжаются без предупреждения системы безопасности.
Сегодня при локальной установке приложения он получает набор разрешений FullTrust, так как загружается из зоны LocalComputer. Безопасность доступа кода (CAS) работает по-разному для приложений Longhorn. Локальное (или установленное) приложение выполняется под политикой безопасности сайта, с которого пользователь скачал его, а не автоматически получает FullTrust, так как он установлен локально.
При загрузке приложения, его компонентов и его ресурсов "Longhorn" предоставляет доказательства системе безопасности среды CLR, например
- Интернет-зона и сайт происхождения (из универсального идентификатора ресурса [URI])
- Имя издателя и модуля (из манифеста развертывания)
Затем CAS предоставляет принудительное применение политик безопасности по привилегиям доступа на основе доказательств приложения.
Манифест развертывания для приложения может указать интервал обновления, который должен использовать Longhorn при проверке новой версии приложения. Когда "Longhorn" обнаруживает, что доступна новая версия, она скачивает и устанавливает новую версию в фоновом режиме. При следующем запуске приложения пользователь получает новую версию.
При установке приложения Longhorn сохраняет предыдущую версию, если она есть. Если вам нужно, вы можете безболезненно откатить до предыдущей версии или даже полностью удалить приложение с помощью добавления и удаления программ. ИТ-отделы могут отправить установку приложения в клиентную систему для бесплатного развертывания.
Вы указываете, как развернуть приложение при компиляции проекта, и вы можете изменить сценарий развертывания путем повторной компиляции, как правило, с небольшим или без изменений в исходном коде.
Программа разработчика изначально взаимодействует с большой частью поддержки приложения Longhorn через экземпляр класса MSAvalon.Windows.Application, поэтому рассмотрим этот класс.
Класс приложения
Программа Longhorn всегда содержит один экземпляр объекта приложения. Этот объект является производным напрямую или косвенно от класса MSAvalon.Windows.Application и выполняет следующие функции:
- Предоставляет точку входа, инкапсуляцию и область для приложения
- Позволяет приложению совместно использовать код и состояние на страницах, составляющих приложение.
- Предоставляет события уровня приложения
- Поддерживает коллекцию окон приложения
- Предоставляет модель безопасности
- Определяет все ресурсы, используемые приложением
Класс MSAvalon.Windows.Application предоставляет базовую поддержку приложений для приложения. Обычно оно используется, если приложению требуется низкая нагрузка и не используется функции навигации по страницам. Однако большинство приложений платформы Longhorn используют тесно связанные класс MSAvalon.Windows.NavigationApplication, который наследует от MSAvalon.Windows.Application и добавляет поддержку навигации. Подробно рассмотрим класс navigationApplication
Список исходных файлов SimpleApplication1.cs, показанный здесь, демонстрирует использование объекта приложения
SimpleApplication1.cs
using System;
using MSAvalon.Windows;
using MSAvalon.Windows.Controls;
using MSAvalon.Windows.Media;
namespace IntroLonghorn {
public class MyApp : MSAvalon.Windows.Application {
MSAvalon.Windows.Controls.SimpleText txtElement;
MSAvalon.Windows.Window mainWindow;
protected override void OnStartingUp (StartingUpCancelEventArgs e) {
base.OnStartingUp (e);
CreateAndShowMainWindow ();
}
private void CreateAndShowMainWindow () {
// Create the application's main window
mainWindow = new MSAvalon.Windows.Window ();
// Add a dark red, 14 point, "Hello World!" text element
txtElement = new MSAvalon.Windows.Controls.SimpleText ();
txtElement.Text = "Hello World!";
txtElement.Foreground = new
MSAvalon.Windows.Media.SolidColorBrush (Colors.DarkRed);
txtElement.FontSize = new FontSize (14,
FontSizeType.Point);
mainWindow.Children.Add (txtElement);
mainWindow.Show ();
}
}
internal sealed class EntryClass {
[System.STAThread]
private static void Main () {
MyApp app = new MyApp ();
app.Run ();
}
}
}
Я использовал следующую командную строку для компиляции исходного кода SimpleApplication1.cs в исполняемое приложение. Возможно, потребуется настроить пути к ссылочным сборкам.
csc /r:C:\WINDOWS\Microsoft.NET\Windows\v6.0.4030\PresentationCore.dll
/r:C:\WINDOWS\Microsoft.NET\Windows\v6.0.4030\PresentationFramework.dll
/r:C:\WINDOWS\Microsoft.NET\Windows\v6.0.4030\WindowsBase.dll
SimpleApplication1.cs
Класс Application содержит ряд других полезных свойств, методов и событий. Например, класс приложения может переопределить виртуальный метод OnShuttingDown, чтобы обеспечить пользовательское поведение завершения работы. Класс приложения также предоставляет запуска и события ShuttingDown, чтобы другие классы могли регистрировать уведомления о запуске и завершении работы. Метод завершения работы
Может потребоваться ссылаться на объект приложения из нескольких мест в исходном коде. Поэтому класс Application предоставляет статические свойства Current, возвращающее ссылку на объект приложения. Следующий фрагмент кода использует свойство Current для поиска объекта приложения и регистрации для уведомления о событии завершения работы:
MyApp app = (MyApp) MSAvalon.Windows.Application.Current;
app.ShuttingDown += new
Application.ShuttingDownEventHandler (ShutDownHandler);
§
private static void
ShutDownHandler (object sender, MSAvalon.Windows.ShuttingDownEventArgs e) {
§
}
Класс NavigationApplication
Если требуется поддержка навигации для приложения, обычно используется класс MSAvalon.Windows.Navigation.NavigationApplication, который расширяет класс MSAvalon.Windows.Application. Хотя вы можете создать приложение на основе навигации без использования класса navigationApplication
- Упрощает написание приложений на основе навигации; обычно не требуется для подкласса класса
- Определяет, когда подключение доступно
- Предоставляет события навигации, такие как навигация, NavigationProcess, Navigated, NavigationError, LoadCompletedи остановленные, которые возникают при возникновении соответствующего события в любом из окон приложения.
- Состояние общих папок на страницах
- Предоставляет контейнер для значений свойств, общих для страниц
- Реализует политику, которая открывает начальное окно по умолчанию
Во внешней среде пользователь приложения навигации может переходить только к хорошо определенным точкам входа приложения. Тем не менее, разработчик управляет навигацией путем перехвата событий. Вы можете определить, когда окно или кадр пытается перейти на новую страницу и когда навигация завершена. Вы можете отменить или перенаправить любую навигацию. Вы можете узнать удостоверение целевой страницы. Вы можете обрабатывать ошибки навигации.
Знакомая модель навигации упрощает использование приложения. Приложение навигации обеспечивает поведение, аналогичное Интернету. Приложение может использовать гиперссылки, предоставлять кнопки пересылки и назад, отображать список избранного и поддерживать журнал страниц. Класс "Longhorn" NavigationApplication и связанные классы обеспечивают всю поддержку таких функций.
Приложение навигации работает независимо от сети или в автономном режиме, и оно работает так же, как в браузере, где размещается приложение или приложение работает как автономное. Кроме того, у вас есть полный контроль над этим поведением weblike. Вы можете настроить взаимодействие с пользователем по мере необходимости. Вы можете вставить, удалить и изменить записи Travelog, чтобы управлять тем, где выполняются операции пересылки и обратно. Вы можете определить, какие страницы (точки входа) регистрируются в журнале.
Приложение навигации обычно создает один или несколько экземпляров класса MSAvalon.Windows.Navigation.NavigationWindow. В описании SimpleApplication2.cs, показанном здесь, демонстрируется использование этих классов. Этот список совпадает с SimpleApplication1.cs, за исключением того, что он использует
SimpleApplication2.cs
using System;
using MSAvalon.Windows;
using MSAvalon.Windows.Controls;
using MSAvalon.Windows.Media;
using MSAvalon.Windows.Navigation;
namespace IntroLonghorn {
public class MyApp : MSAvalon.Windows.Navigation.NavigationApplication {
protected override void OnStartingUp (StartingUpCancelEventArgs e) {
base.OnStartingUp (e);
CreateAndShowMainWindow ();
}
private void CreateAndShowMainWindow () {
// Create the application's main window
mainWindow = new MSAvalon.Windows.Navigation.NavigationWindow ();
// Fill window with appropriate controls
§
// Show the window
mainWindow.Show ();
}
}
internal sealed class EntryClass {
[System.STAThread]
private static void Main () {
MyApp app = new MyApp ();
app.Run ();
}
}
}
Код, который вы видели до сих пор, является просто еще одним вариантом традиционных моделей программирования. Единственным новым аспектом является фактические классы, которые я использовал. Однако большую часть времени вы на самом деле не напишете большую часть этого кода. Давайте рассмотрим небольшой обход и узнаем о новом языке программирования, который позволяет писать этот же код гораздо более компактным и ( по крайней мере, более понятным образом).
Расширяемый язык разметки приложения (XAML)
Во многих приложениях большая часть написанного кода относится к созданию и обновлению пользовательского интерфейса приложения. На самом деле, в предыдущих примерах не было кода, отличного от кода, необходимого для создания пользовательского интерфейса. За последние несколько лет многие разработчики научились писать, и даже предпочитать определять пользовательский интерфейс приложения с помощью одного из нескольких доступных языков разметки. Платформа Longhorn определяет новый язык разметки с именем Расширяемый язык разметки приложений (XAML; произнесенный "Zamel", который рифмывается с "верблюдю").
Использование языка разметки для определения пользовательского интерфейса имеет ряд преимуществ по сравнению с использованием процедурного языка программирования. К этим преимуществам относятся следующие преимущества.
- Более очевидные иерархии элементов управления
- Более очевидное наследование свойств
- Упрощенная обработка и интерпретация языка разметки с помощью инструментов
- Потенциальное разделение пользовательского интерфейса и процедурного кода
Мне нравится XAML, и я предпочитаю использовать его для определения моего пользовательского интерфейса, а не использования кода процедурного типа, который я показал вам до сих пор в этой главе. Тем не менее, не думаю, что вы сможете делать все, что вам нужно, используя ничего, кроме XAML.
Рассмотрим эту инструкцию из документации: "Документы часто могут быть написаны полностью в XAML и отображаться в браузере". Я спешно указываю, что в этом предложении используется слово документов, а не приложений, и он квалифицирует инструкцию с термином часто. При написании документа, отображающего статическое содержимое, его можно создать в чистом XAML. Вы даже можете написать документ, использующий привязку данных для отображения и обновления содержимого из источника данных, используя только XAML. Анимации и эффекты мыши можно определить с помощью ничего, кроме XAML. Вы можете многое сделать, используя ничего, кроме XAML. (На самом деле, я стараюсь сделать как можно больше в XAML и как можно меньше в коде. Мои приложения, кажется, менее ошибок и работают быстрее, чем меньше кода я пишу!) Тем не менее для написания рабочего приложения обычно необходимо реагировать на события, предоставлять пользовательскую логику принятия решений или включать множество других операций, отличных от пользовательского интерфейса, поэтому вам потребуется смешивать XAML и код. К счастью, это очень легко сделать.
Более подробно описаны файлы XAML в главе 3; Теперь давайте рассмотрим праймер для XAML:
- Имя элемента XAML — это имя класса .NET Framework. При определении элемента XAML вы фактически создаете экземпляр класса .NET Framework с тем же именем, что и элемент XAML.
- Имя атрибута XAML сопоставляется со свойством или полем с тем же именем, как правило, в экземпляре класса.
В программе SimpleApplication1.cs создайте окно и добавьте в него некоторые элементы управления с помощью следующего кода:
// Create the application's main window
mainWindow = new MSAvalon.Windows.Window ();
// Add a dark red, 14 point, "Hello World!" text element
txtElement = new MSAvalon.Windows.Controls.SimpleText ();
txtElement.Text = "Hello World!";
txtElement.Foreground = new
MSAvalon.Windows.Media.SolidColorBrush (Colors.DarkRed);
txtElement.FontSize = new FontSize (14, FontSizeType.Point);
mainWindow.Children.Add (txtElement);
mainWindow.Show ();
Следующий документ XAML создает такой же пользовательский интерфейс.
HelloWorld.xaml
<Window xmlns="https://schemas.microsoft.com/2003/xaml" Visible="true">
<SimpleText Foreground="DarkRed" FontSize="14">Hello World!</SimpleText>
</Window>
Корневой элемент Window создает экземпляр класса с именем MSAvalon.Windows.Window. Как-то система сборки должна знать, что элемент XAML с именем Window ссылается на экземпляр класса с именем MSAvalon.Windows.Window. Значение атрибута xmlns предоставляет это сопоставление.
Средства синтаксического анализа XML интерпретируют неквалифицированные имена элементов относительно пространства имен, указанного в последнем атрибуте пространства имен по умолчанию, xmlns. При указании значения xmlns "https://schemas.microsoft.com/2003/xaml", система сборки интерпретирует некавалифицированное имя элемента в определяемом элементе или один из его подчиненных элементов в качестве имени класса в предопределенном наборе пространств имен.
Позвольте мне переосмысить это в более конкретных терминах, используя C# в качестве примера. Объявление xmlns
using MSAvalon.Windows;
using MSAvalon.Windows.Controls;
using MSAvalon.Windows.Controls.Primitives;
using MSAvalon.Windows.Data;
using MSAvalon.Windows.Documents;
using MSAvalon.Windows.Shapes;
using MSAvalon.Windows.Media;
using MSAvalon.Windows.Media.Animation;
using MSAvalon.Windows.Navigation;
Стандартное объявление пространства имен по умолчанию также приводит к тому, что система сборки ссылается на сборки PresentationFramework и сборки PresentationCore, содержащие классы в ранее перечисленных пространствах имен.
Присвойте
Я вложен элемент SimpleText
Сохраните предыдущий код XAML в файле HelloWorld.xaml и запустите файл. Браузер интерпретирует код XAML в файле и отображает пользовательский интерфейс, как показано на рис. 1-1.
Рис. 1-1. Браузер, отображающий версию XAML Hello World (щелкните рисунок, чтобы увидеть больше изображения)
Возможно, вы хотите использовать класс .NET, который не определен в одном из пространств имен по умолчанию, перечисленных ранее. Типичный пример — использование класса из создаваемой сборки. Система сборки должна иметь возможность сопоставить имя элемента, указанное в исходном файле XAML, с соответствующим классом .NET в правильной сборке. XAML определяет инструкцию обработки XML (PI) с именем ? Сопоставление, используемых для создания этой связи.
? Сопоставление PI позволяет определить префикс пространства имен XML, который сопоставляется с пространством имен и сборкой СРЕДЫ CLR. При квалификации имени элемента XAML с префиксом этого пространства имен вы сообщаете системе сборки, в действительности, чтобы принять имя элемента, добавьте префикс CLR в имя и создайте экземпляр класса с результирующей именем. Компилятор будет ссылаться на указанную сборку, чтобы найти определение класса.
В следующем примере создается экземпляр класса WiseOwl.Statistics.PoissonDeviate, определение которого находится в сборке WiseOwl.Statistics. Library:
<?Mapping XmlNamespace="stat" ClrNamespace="WiseOwl.Statistics"
Assembly="WiseOwl.Statistics.Library" ?>
<Window xmlns="https://schemas.microsoft.com/2003/xaml" Visible="true">
<SimpleText Foreground="DarkRed" FontSize="14">Hello World!</SimpleText>
<stat:PoissonDeviate Mean="5.0" />
</Window>
Я не могу подчеркнуть, что XAML — это просто другой способ создания кода, использующего классы пользовательского интерфейса .NET Framework. На самом деле вы можете использовать средство, отображающее спецификацию пользовательского интерфейса XAML графически с помощью визуального конструктора. Другой инструмент может сделать обратный и позволит вам графически разработать пользовательский интерфейс и сохранить его в виде XAML-файла. Еще один инструмент может сохранить дизайн пользовательского интерфейса в виде процедурного кода, который аналогичен работе конструктора WinForms. Все эти подходы — это просто разные методы указания одной и той же информации.
Ранее в этой главе я упомянул, что браузер может отобразить XAML-файл в своем окне. Браузер может сделать это только в том случае, если XAML-файл не содержит ничего, кроме разметки, как просто показан простой пример. По мере того как пользовательский интерфейс становится более сложным, обычно необходимо использовать обработчики событий и другой исходный код, отличный от разметки, помимо XAML, описывающего пользовательский интерфейс. В любой момент, когда у вас есть база смешанного исходного кода , то есть разметка и немаркпирование исходного кода, необходимо скомпилировать разметку и исходный код с помощью служебной программы MSBuild. После компиляции вы можете запустить приложение как автономный компонент или отобразить полученный пользовательский интерфейс в браузере.
Сводка
Хорошо! Теперь вы понимаете основы новой модели приложения. Вы узнали, как использовать разметку для создания пользовательского интерфейса декларативно, хотя и очень простой пользовательский интерфейс. Вы можете написать эквивалент веб-страниц с помощью XAML-файлов и развернуть эти файлы на сервере для просмотра пользователем. Однако сценарии, которые более интересны, обычно требуют компиляции приложения перед развертыванием приложения. Итак, давайте перейдем прямо в систему и узнайте, как создать и развернуть приложение Longhorn.
продолжить работу с главой 2. Создание приложения Longhorn.
© Корпорация Майкрософт 2003 г. Все права защищены.
IntelliSense, Microsoft, MSDN, MS-DOS, Visual Basic .NET и Visual Studio .NET являются зарегистрированными товарными знаками или товарными знаками корпорации Майкрософт в США и/или других странах. Другие названия продуктов и компаний, упомянутые здесь, могут быть товарными знаками соответствующих владельцев.