Code Snippet

< input type ="hidden" name ="WorkflowDefinition" value = <% _STSWriteHTML(Request.Form["WorkflowDefinition"]); %>>

< input type ="hidden" name ="WorkflowName" value = <% _STSWriteHTML(Request.Form["WorkflowName"]); %>>

< input type ="hidden" name ="AddToStatusMenu" value = <% _STSWriteHTML(Request.Form["AddToStatusMenu"]); %>>

< input type ="hidden" name ="AllowManual" value = <% _STSWriteHTML(Request.Form["AllowManual"]); %>>

< input type ="hidden" name ="RoleSelect" value = <% _STSWriteHTML(Request.Form["RoleSelect"]); %>>

< input type ="hidden" name ="AutoStartCreate" value = <% _STSWriteHTML(Request.Form["AutoStartCreate"]); %>>

< input type ="hidden" name ="AutoStartChange" value = <% _STSWriteHTML(Request.Form["AutoStartChange"]); %>>

< input type ="hidden" name ="GuidAssoc" value = <% _STSWriteHTML(Request.Form["GuidAssoc"]); %>>

tags from AssociationForm.aspx page and tried to associate workflow again. After clicking "Next" I finally was redirected to my AssociationForm.aspx page but when I clicked "Submit" it didn"t go to "Submit" button"s handler, instead it started page load again, so all data which was sent to my page from AddWrkfl.aspx page were lost.

Can someone suggest what I did wrong?

Запустите Visual Studio 2012 и выберите пункт New Project (Создать проект) в меню File (Файл). Откроется диалоговое окно New Project (Новый проект), которое позволяет создавать новые проекты Visual Studio.

В левой панели этого диалогового окна вы увидите список доступных типов проектов. Перейдите к элементу Installed --- Templates --- Visual C# --- Web (Установленные --- Шаблоны --- Visual C# --- Веб) и в центральной панели отобразится набор проектов ASP.NET, как показано на рисунке ниже:

Удостоверьтесь, что выбрали Visual C#, а не Visual Basic. Попытка выполнить приведенные примеры на C# в проекте Visual Basic приведет к весьма странному поведению и множеству ошибок.

Выберите в центральной панели элемент ASP.NET Empty Web Application (Пустое веб-приложение ASP.NET) - имена некоторых проектов, несмотря на их отличия, выглядят похожими, поэтому внимательно выбирайте нужный тип проекта. Удостоверьтесь, что в раскрывающемся списке в верхней части экрана выбран вариант.Net Framework 4.5 и введите в поле Name (Имя) строку TestAspNet45 в качестве имени проекта. Щелкните на кнопке OK для создания нового проекта.

Среда Visual Studio устанавливает в поле Solution name (Имя решения) строку TestAspNet45 для соответствия имени проекта. Решение Visual Studio - это контейнер для одного или большего числа проектов.

Шаблон ASP.NET Empty Web Application - простейший из всех шаблонов проектов. Он создает проект, содержащий лишь файл Web.config, в котором находится конфигурационная информация для приложения ASP.NET. Среда Visual Studio отображает файлы в окне Solution Explorer (Проводник решения), показанном на рисунке ниже. Окно Solution Explorer является основным инструментом для навигации внутри проекта.

Добавление новой веб-формы

Как вы уже видели при создании проекта Visual Studio, существуют разнообразные типы приложений ASP.NET. Для выбранного типа приложения, контент генерируется из веб-формы (Web Form).

Чтобы добавить в проект новую веб-форму, щелкните правой кнопкой мыши на записи проекта TestAspNet45 в окне Solution Explorer и выберите в контекстном меню пункт Add --- Web Form (Добавить --- Веб-форма). В появившемся диалоговом окне введите Default в качестве имени нового элемента проекта:

Щелкните на кнопке OK для закрытия диалогового окна и создания нового элемента. Вы заметите в окне Solution Explorer, что среда Visual Studio добавила в проект файл Default.aspx и открыла его для редактирования. Первоначальное содержимое этого файла приведено в коде ниже:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="TestAspNet45.Default" %>

Файл веб-формы в сущности представляет собой расширенный HTML-файл. Наличие элемента, имеющего дескрипторы <% и %>, говорит о том, что это не обычный файл HTML. То же самое касается атрибутов runat в элементах head и form.

Как показано ниже, в файл Default.aspx было добавлено несколько стандартных HTML-элементов:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="TestAspNet45.Default" %>

В файл Default.aspx были добавлены элементы h1 и p, содержащие простой текст. Они не содержат ничего, связанного с ASP.NET - это стандартные HTML-элементы.

Тестирование примера приложения

Панель инструментов Visual Studio содержит раскрывающийся список с названиями браузеров, которые установлены на рабочей станции (чтобы увидеть этот список, щелкните на небольшой стрелке вниз, расположенной справа от названия браузера).

Пример списка показан на рисунке ниже, где можно видеть несколько браузеров, установленных в системе. Как минимум, в списке будут присутствовать элементы Internet Explorer и Page Inspector (инструмент, который помогает отлаживать HTML-код).

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

Удостоверьтесь, что в списке выбран нужный браузер и затем щелкните на соответствующей кнопке в панели инструментов или выберите пункт Start Debugging (Начать отладку) в меню Debug (Отладка) среды Visual Studio. Проект будет скомпилирован и откроется новое окно браузера, отображающее веб-форму, как показано на рисунке ниже. На данный момент контент веб-формы довольно скуден, но мы, по крайней мере, знаем, что все работает должным образом.

Для этого примера Google Chrome использует следующий URL:

http://localhost:40035/Default.aspx

Запустив приложение, вы увидите похожий, но не идентичный URL. Будет присутствовать часть http://, указывающая на применение протокола HTTP, и часть localhost, которая представляет собой специальное имя, ссылающееся на рабочую станцию. Часть URL, касающаяся порта, 40035 в данном случае, назначается произвольно, поэтому вы, скорее всего, увидите другой номер порта. Последняя часть URL, Default.aspx, указывает на необходимость использования содержимого из файла Default.aspx, которое и можно видеть в окне браузера.

Так к чему же относится этот URL? В состав Visual Studio 2012 входит инструмент IIS Express, который представляет собой усеченную версию сервера приложений Microsoft, предназначенную для запуска разрабатываемых приложений ASP.NET. Сервер IIS Express устанавливается автоматически; когда он запущен, в области уведомлений отображается значок. Щелкнув правой кнопкой мыши на этом значке, можно просмотреть список приложений ASP.NET, которые были запущены, и открыть окно браузера для их отображения:

Когда приложение запускается из Visual Studio, сервер IIS Express стартует и начинает прослушивать входящие запросы (на порте 40035 или любом другом). Как только сервер IIS Express запустился, Visual Studio создает новое окно Internet Explorer и применяет его для перехода на URL, который приводит к загрузке файла Default.aspx из IIS Express.

Чтобы просмотреть HTML-код, который сервер IIS Express и платформа ASP.NET Framework (интегрированная в IIS) отправляют браузеру, необходимо щелкнуть правой кнопкой мыши в окне браузера и выбрать в контекстном меню пункт View Source (Просмотр HTML-кода). Этот HTML-код показан ниже, легко заметить, что он отличается от содержимого файла Default.aspx:

Отправленный браузеру HTML-код является результатом обработки файла Default.aspx платформой ASP.NET Framework. Удалены дескрипторы <% и %> и добавлен скрытый элемент input, но поскольку данный файл Default.aspx не делает ничего особо интересного, его содержимое передается браузеру в основном без изменений.

Итак, вы создали очень простое веб-приложение ASP.NET. Сейчас следует запомнить следующие ключевые моменты:

Пользователь запрашивает URL, которые указывают на файлы веб-форм, добавленные к проекту.

Запросы получает сервер IIS Express, который находит запрашиваемые файлы.

Сервер IIS Express обрабатывает файл веб-формы с целью генерации страницы стандартного HTML-кода.

Код HTML возвращается браузеру, который отображает его для пользователя.

Это сущность любого приложения ASP.NET. Наша цель - воспользоваться тем способом, которым ASP.NET Framework обрабатывает файлы веб-форм, для создания более сложного HTML-кода и последовательностей взаимодействий с пользователем. В последующих разделах мы будем опираться на данный фундамент.

Создание простого приложения

В оставшейся части статьи мы исследуем некоторые из базовых средств ASP.NET, используемых для создания простого приложения ввода данных. В этом разделе мы нарастим темпы - цель заключается в том, чтобы продемонстрировать ASP.NET в действии поэтому мы опустим детальные пояснения того, как все это работает "за кулисами".

Предварительная настройка

Предположим, что ваша подруга решила организовать новогоднюю вечеринку. Она попросила вас создать веб-сайт, который дал бы возможность приглашенным отправлять ответы на приглашение (repondez s"il vous plait - RSVP) по электронной почте. Она высказала пожелание о наличии следующих основных средств:

страница, которая отображает информацию о вечеринке и форму RSVP;

проверка достоверности для формы RSVP, которая будет отображать страницу подтверждения;

страница, на которой выводится список ответов от приглашенных.

В следующих нескольких разделах мы достроим проект ASP.NET по имени TestAspNet45, созданный в начале статьи, добавив указанные средства.

Создание модели данных и хранилища

Почти все веб-приложения полагаются на какую-нибудь разновидность модели данных, независимо от технологии, используемой для их создания. Поскольку мы строим простое приложение, нам нужна лишь простая модель данных. Щелкните правой кнопкой мыши на элементе TestAspNet45 в окне Solution Explorer и выберите в контекстном меню пункт Add --> Class (Добавить --- Класс).

Если пункт меню Class отсутствует или не доступен, это может означать, что вы оставили отладчик Visual Studio в функционирующем состоянии. Среда Visual Studio ограничивает изменения, которые можно вносить в проект, пока выполняется приложение. Выберите пункт Stop Debugging (Остановить отладку) в меню Debug (Отладка) и попробуйте заново.

Откроется диалоговое окно Add New Item (Добавление нового элемента), содержащее шаблоны для всех элементов, которые можно добавлять к проекту ASP.NET. Шаблон Class (Класс) будет уже выбран, так что укажите в качестве имени GuestResponse.cs и щелкните на кнопке Add (Добавить). Среда Visual Studio создаст новый файл класса C# и откроет его для редактирования. Приведите содержимое этого файла в соответствие с кодом:

Namespace TestAspNet45 { public class GuestResponse { public string Name { get; set; } public string Email { get; set; } public string Phone { get; set; } public bool? WillAttend { get; set; } } }

В классе Guest Response применяется средство языка C# под названием автоматически реализуемые свойства, с которым вы можете быть не знакомы, если имели дело с более старыми версиями.NET Framework.

Обратите внимание, что свойство WillAttend определено с типом bool, допускающим null. Это означает, что свойство может принимать значения true, false или null. Причины выбора этого типа данных объясняются в разделе "Выполнение проверки достоверности" далее в статье.

Для представления ответов от гостей вечеринки будут применяться экземпляры класса GuestResponse. Созданные объекты GuestResponse должны записываться в хранилище. В реальном приложении в его качестве обычно выступает база данных, нам же требуется нечто быстрое и простое, поэтому мы собираемся хранить объекты в памяти. Преимущество такого подхода связано с простотой реализации, однако следует учитывать, что данные будут теряться при каждом останове или перезапуске приложения. Это было бы довольно странным выбором для реального веб-приложения, но вполне подходит для целей настоящей статьи.

Чтобы определить хранилище, добавьте в проект новый файл класса по имени ResponseRepository.cs и поместите в него код, показанный ниже:

Using System.Collections.Generic; namespace TestAspNet45 { public class ResponseRepository { private static ResponseRepository repository = new ResponseRepository(); private List responses = new List(); public static ResponseRepository GetRepository() { return repository; } public IEnumerable GetAllResponses() { return responses; } public void AddResponse(GuestResponse response) { responses.Add(response); } } }

Хранилище обычно располагает методами для создания, чтения, обновления и удаления объектов данных (вместе называемых методами CRUD (creating, reading, updating, deleting - создание, чтение, обновление, удаление) , но в этом приложении нужна только возможность чтения всех объектов данных и добавления новых объектов данных.

Создание и стилизация формы

Следующий шаг заключается в создании страницы, которая содержит информацию о вечеринке и HTML-форму, позволяющую гостям подготовить ответ. Мы будем использовать файл Default.aspx, который был создан ранее. Внесенные в него изменения представлены в коде ниже:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="TestAspNet45.Default" %>

Здесь было изменено значение атрибута id элемента form и добавлены стандартные HTML-элементы, предназначенные для отображения информации о вечеринке, а также для сбора деталей формы RSVP от пользователей. Запустив приложение (либо выбором пункта меню Start Debugging из меню Debug, либо щелчком на кнопке браузера в панели инструментов), можно посмотреть, как выглядят указанные изменения.

Элементы веб-формы стилизуются точно так же, как элементы обычной HTML-страницы - с применением каскадных таблиц стилей (Cascading Style Sheets - CSS). Для добавления к приложению нескольких базовых стилей щелкните правой кнопкой мыши на элементе TestAspNet45 в окне Solution Explorer и выберите в контекстном меню пункт Add --> StyleSheet (Добавить --> Таблица стилей). В появившемся диалоговом окне в качестве имени укажите Styles и щелкните на кнопке OK. Среда Visual Studio добавит к проекту новый файл Styles.css. Приведите содержимое этого файла в соответствие с примером ниже. Несмотря на простоту этих стилей CSS, они существенно улучшат внешний вид полей формы.

#rsvpform label { width: 120px; display: inline-block; } #rsvpform input { margin: 2px; margin-left: 4px; width: 150px; } #rsvpform select { margin: 2px 0; width: 154px; } button { margin-top: 15px; padding: 5px; }

Таблица стилей CSS ассоциируется с веб-формой с помощью элемента link. В коде ниже показано, как добавить такой элемент в раздел head файла Default.aspx:

... ...

И снова обратите внимание, что для ссылки на файл, содержащий базовые стили CSS, используется стандартный HTML-элемент. (Мы не хотим акцентировать на этом внимание, но один из замечательных аспектов работы с платформой ASP.NET состоит в том, что она построена на основе существующих знаний веб-стандартов.) Запустив приложение, можно увидеть эффект от применения CSS:

Обработка данных формы

У нас есть HTML-форма, которую можно отобразить приглашенным на вечеринку, однако при щелчке пользователями на кнопке "Отправить приглашение RSVP" постоянно отображается одна и та же страница. Чтобы исправить это, понадобится написать код, который будет обрабатывать данные формы, когда они отправляются серверу.

В начале файла Default.aspx находится следующий элемент:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="TestAspNet45.Default" %> ...

Это называется страничной директивой (или директивой Page). Определенные в ней атрибуты предоставляют ASP.NET детали о файле веб-формы. Нас интересует атрибут CodeBehind. Данный атрибут сообщает ASP.NET, какой файл класса C# содержит код, ассоциированный с веб-формой. В приведенном примере это файл Default.aspx.cs, который является файлом отделенного кода для Default.aspx.

Среда Visual Studio группирует вместе связанные файлы в виде одиночного элемента в окне Solution Explorer, что упрощает навигацию по крупным проектам. Если щелкнуть на стрелке слева от записи Default.aspx, можно увидеть файлы, сокрытые средой Visual Studio. Одним из них является файл Default.aspx.cs, на который производится ссылка с помощью атрибута CodeBehind.

Дважды щелкните на файле Default.aspx.cs, чтобы открыть его в редакторе; отобразится код, приведенный ниже:

Using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.UI; using System.Web.UI.WebControls; namespace TestAspNet45 { public partial class Default: System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { } } }

Базовым для класса отделенного кода является класс System.Web.UI.Page , который содержит несколько полезных методов и свойств для ответа на веб-запросы. Пока что в классе отделенного кода нас интересует метод Page_Load() , вызываемый ASP.NET Framework при поступлении запросов для Default.aspx и предоставляющий возможность отреагировать на такие запросы.

В рассматриваемом примере метод Page_Load() будет вызван один раз во время первоначальной загрузки страницы и еще раз - когда пользователь отправит форму. В примере ниже показан код, добавленный к методу Page_Load() для реагирования на запросы:

Using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.ModelBinding; namespace TestAspNet45 { public partial class Default: System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { if (IsPostBack) { GuestResponse rsvp = new GuestResponse(); if (TryUpdateModel(rsvp, new FormValueProvider(ModelBindingExecutionContext))) { ResponseRepository.GetRepository().AddResponse(rsvp); if (rsvp.WillAttend.HasValue && rsvp.WillAttend.Value) { Response.Redirect("seeyouthere.html"); } else { Response.Redirect("sorryyoucantcome.html"); } } } } } }

Здесь за счет проверки свойства IsPostBack выясняется, относится ли запрос, на который производится ответ, к форме, отправленной обратно серверу. Если это так, мы создаем новый экземпляр объекта GuestResponse модели данных и передаем его методу TryUpdateModel() , унаследованному от базового класса Page.

Метод TryUpdateModel() выполняет процесс, который называется привязкой модели и предполагает использование значений данных из запроса браузера для заполнения свойств соответствующего объекта модели данных. Еще одним аргументом метода TryUpdateModel() является объект, который платформа ASP.NET должна применять для получения необходимых значений - мы используем класс System.Web.ModelBindlng.FormValueProvider , который предоставляет значения из данных формы. В результате вызова метода TryUpdateModel() свойства объекта GuestResponse обновляются, чтобы отразить значения данных, которые пользователь отправил внутри формы. Затем объект GuestResponse помещается в хранилище.

Пользователю необходимо предоставить какой-либо отклик после того, как он отправил форму, и это делается с помощью метода Response.Redirect (), который выполняет перенаправление пользовательского браузера. Если свойство WillAttend равно true, пользователь придет на вечеринку, поэтому он перенаправляется на файл seeyouthere.html. В противном случае перенаправление происходит на файл sorryyoucantcome.html.

Создание HTML-файлов ответов

Не все страницы в приложении ASP.NET должны генерироваться из файлов веб-форм. Можно также включать обычные, статические HTML-файлы. Чтобы создать первый файл ответа, щелкните правой кнопкой мыши на элементе TestAspNet45 в окне Solution Explorer и выберите в контекстном меню пункт Add --> New Item (Добавить --> Новый элемент). В открывшемся диалоговом окне Add New Item укажите шаблон HTML Page (HTML-страница) и назначьте странице имя seeyouthere.html. Наконец, щелкните на кнопке Add (Добавить) для создания HTML-файла. Приведите содержимое нового файла в соответствие с примером ниже:

Увидимся на вечеринке! ;)

Приходите в 9 вечера. Маски являются обязательными!

Повторите описанный процесс для создания файла sorryyoucantcome.html с содержимым, которое показано в примере ниже:

Жаль что вы не сможете прийти:(

Увидимся в следующем году!

Установка области действия HTML-элементов

Базовая структура приложения в основном построена, однако оно еще не полностью работоспособно. Мы должны сообщить Visual Studio, какой файл необходимо загружать при запуске приложения. Ранее это не имело значения, т.к. существовал только один файл Default.aspx, а среда Visual Studio достаточно интеллектуальна, чтобы определить его в качестве стартового. Но теперь есть еще и пара HTML-файлов, поэтому нужно предоставить Visual Studio некоторую помощь. Щелкните правой кнопкой мыши на элементе Default.aspx в окне Solution Explorer и выберите в контекстном меню пункт Set as Start Page (Установить как стартовую страницу).

Теперь можно запустить приложение, либо выбрав пункт Start Debugging в меню Debug, либо щелкнув на кнопке Google Chrome в панели инструментов. Заполните поля формы и удостоверьтесь, что в элементе select выбран вариант "Да". После отправки формы вы увидите ответ, который должен отображаться в случае выбора варианта "Нет", как показано на рисунке ниже. Очевидно, что-то не в порядке.

Причина этой проблемы в том, что при обработке файлов веб-форм платформа ASP.NET ищет только элементы, которые имеют атрибут runat со значением server. Все остальные элементы игнорируются, и поскольку элементы input и select в файле Default.aspx не имеют указанной комбинации атрибута и значения, процесс привязки модели не имеет возможности найти значения, отправленные внутри HTML-формы. В примере ниже показано, как скорректировать проблему:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="TestAspNet45.Default" %>

Для атрибута runat предусмотрено только значение server. Если опустить атрибут runat или указать значение, отличное от server, то такие HTML-элементы станут невидимыми для ASP.NET. Пропуск атрибутов runat - это первое, что следует проверить в ситуации, когда веб-формы ведут себя не так, как ожидалось.

Снова запустите приложение и заполните форму. На этот раз отправка формы приводит к выдаче корректного ответа:

Создание итогового представления

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

Щелкните правой кнопкой мыши на элементе TestAspNet45 в окне Solution Explorer и выберите в контекстном меню пункт Add --> Web Form. В открывшемся диалоговом окне укажите Summary для имени веб-формы и щелкните на кнопке OK, чтобы создать новый файл Summary.aspx. Приведите содержимое файла в соответствие с примером:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Summary.aspx.cs" Inherits="TestAspNet45.Summary" %> <%@ Import Namespace="TestAspNet45" %>

Приглашения

Поскольку это первое создаваемое приложение ASP.NET, мы хотим продемонстрировать в этой статье максимально возможное количество приемов. Именно поэтому содержимое файла Summary.aspx существенно отличается от содержимого файла Default.aspx.

Вскоре мы подробно опишем различные разделы этого файла, но первое, что должно быть заметно - отсутствие элемента form в файле Summary.aspx. Название "веб-форма" несколько вводит в заблуждение, и хотя обычные формы удобны в большинстве приложений, файл веб-формы - это просто расширенный HTML-файл, который обрабатывается ASP.NET. В файле Default.aspx такие расширения имеют вид файла отделенного кода, поэтому его можно использовать для работы с отправками формы. В файле Summary.aspx дополнительно применяются дескрипторы <% и %> для добавления динамического контента к генерируемому HTML-коду, когда браузер запрашивает данный файл.

Дескрипторы <% и %> формально называются ограничителями сценариев серверной стороны, хотя более распространено название фрагменты кода . Доступны различные виды фрагментов кода и в примере были добавлены два типа таких фрагментов. Вот первый из них:

<%@ Import Namespace="TestAspNet45" %>

Фрагмент кода с открывающим дескриптором <%@ представляет собой директиву. Директивы позволяют выполнять действие, оказывающее влияние на веб-форму целиком. В данном случае была создана директива Import, которая помещает в область видимости пространство имен из проекта, что дает возможность ссылаться на классы, указывая только их имена.

Почему мы заботимся о пространствах имен? Поскольку второй фрагмент кода в примере выше является блоком кода C#, который будет выполнен при запросе страницы, ссылка на классы без снабжения их пространствами имен упрощает код. Открывающий дескриптор для блока кода выглядит просто как <% и не включает каких-либо дополнительных символов. (Закрывающий дескриптор для всех разновидностей фрагментов кода - всегда %>.)

Внутри блока кода используются обычные операторы C# для генерации набора HTML-элементов, представляющих собой строки в элементе table; в этих строках перечислены люди, принявшие приглашение на вечеринку. Для получения всех объектов данных из хранилища вызывается метод ResponseRepository.GetRepository().GetAllResponses(), а для выборки всех подтверждающих участие ответов применяется LINQ-метод Where(). Затем в цикле foreach генерируются HTML-строки для каждого объекта данных:

string htmlString = String.Format("{0}{1}{2}", rsvp.Name, rsvp.Email, rsvp.Phone);

Метод String.Format() позволяет компоновать HTML-строки, содержащие значения свойств из каждого объекта GuestResponse, который необходимо отобразить. Для добавления HTML-кода в вывод, отправляемый браузеру, используется метод Response.Write().

Форматирование динамического HTML-кода

Вы заметите, что в файл Summary.aspx включен элемент link, который импортирует файл Styles.css с содержащимися внутри него стилями. Это сделано для демонстрации того, что элемент, генерируемый в блоке кода, стилизуется точно так же, как статический HTML-элемент на странице. В примере ниже показан стиль, добавленный в файл Styles.css для применения внутри Summary.aspx.

Table, td, th { border: thin solid black; border-collapse: collapse; padding: 5px; background-color: lemonchiffon; text-align: left; margin: 10px 0; }

Тестирование динамического кода

Чтобы протестировать файл Summary.aspx, запустите приложение и воспользуйтесь страницей Default.aspx для добавления данных в хранилище - помните, что в этом примере данные не хранятся постоянно, а их нужно вводить заново при каждом запуске приложения. После нескольких отправок формы перейдите на URL вида "/Summary.aspx"; появится вывод, который похож на показанный на рисунке:

Вызов метода из отделенного кода

Хотя и можно включать блоки кода C# в файл веб-формы, обычно делать это не имеет смысла, т.к. файл становится трудным в чтении и сопровождении. Намного более ясный и распространенный подход предусматривает определение методов в файле отделенного кода, а затем использование фрагментов кода для вызова этих методов и вставки результатов в HTML-код, отправляемый браузеру.

В примере ниже показано, как определить новый метод по имени GetNoShowHtml() в файле отделенного кода Summary.aspx.cs. Этот метод генерирует таблицу строк, аналогичную той, что создавалась в предыдущем разделе:

Using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.UI; using System.Web.UI.WebControls; using System.Text; namespace TestAspNet45 { public partial class Summary: System.Web.UI.Page { protected string GetNoShowHtml() { StringBuilder html = new StringBuilder(); var noData = ResponseRepository.GetRepository() .GetAllResponses().Where(r => !r.WillAttend.Value); foreach (var rsvp in noData) { html.Append(String.Format("{0}{1}{2}", rsvp.Name, rsvp.Email, rsvp.Phone)); } return html.ToString(); } } }

После этого новый метод можно вызывать внутри фрагмента кода в файле Summary.aspx:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Summary.aspx.cs" Inherits="TestAspNet45.Summary" %> <%@ Import Namespace="TestAspNet45" %>

Приглашения

Люди которые были приглашены:

Люди которые не придут:

В этом примере применяется фрагмент кода с открывающим дескриптором <%=. Это сообщает ASP.NET о необходимости вставки результата выполнения метода в вывод, отправляемый браузеру, что представляет собой более аккуратный и читабельный подход, чем включение кода непосредственно в страницу. Генерируется такой же HTML-код, что и с помощью предыдущего фрагмента кода, но только в данном случае получается таблица строк для людей, которые отклонили приглашение на вечеринку:

Выполнение проверки достоверности

Приложение почти завершено, однако осталась еще одна нерешенная проблема: пользователи могут отправлять внутри формы Default.aspx произвольные данные или вообще отправлять пустую форму. Необходимо обеспечить наличие значений во всех полях формы, чтобы данные были корректными и отражали точно, кто принял приглашение на вечеринку, а кто от него отказался.

Платформа ASP.NET предоставляет целый набор разнообразных приемов проверки достоверности, но мы отдаем предпочтение подходу, при котором к классу модели данных применяются атрибуты, задающие требования проверки. В примере ниже показано, как реализовать базовую проверку достоверности в классе GuestResponse:

Using System.ComponentModel.DataAnnotations; namespace TestAspNet45 { public class GuestResponse { public string Name { get; set; } public string Email { get; set; } public string Phone { get; set; } public bool? WillAttend { get; set; } } }

Атрибут Required , определенный в пространстве имен System.ComponentModel.DataAnnotations, сообщает ASP.NET, что для свойства, к которому он применен, наличие значения является обязательным. Так как указанный атрибут применен ко всем свойствам в классе GuestResponse, ASP.NET известно, что все свойства класса модели данных являются обязательными. Это довольно простая форма проверки достоверности, поскольку мы не проверяем, полезно ли значение, а только сам факт его предоставления пользователем; тем не менее, такой подход вполне адекватен для рассматриваемого примера.

Когда пользователь отправляет форму в файле Default.aspx, платформа ASP.NET Framework вызывает метод Page_Load() из файла отделенного кода Default.aspx.cs. Ранее в этой статье было показано, как вызывать метод TryUpdateModel() для выполнения привязки модели. После добавления атрибута Required этот метод будет проверять, получены ли значения для всех свойств.

В файл Default.aspx понадобится внести дополнение для отображения пользователям сообщений, когда возникают проблемы с проверкой достоверности данных формы, которая была отправлена. Это дополнение показано в примере ниже:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="TestAspNet45.Default" %>

Здесь был добавлен элемент управления ASP.NET Web Forms. Такой элемент управления генерирует HTML-код внутри страницы - доступны различные виды элементов управления, которые предоставляют удобный способ инкапсуляции функциональности, делающий возможным их повторное использование в рамках приложения. Можно создавать собственные элементы управления либо применять предлагаемые Microsoft. В рассматриваемом примере был добавлен элемент управления ValidationSummary, разработанный в Microsoft, который отображает сообщения об ошибках проверки достоверности.

Для подсветки ошибок красным цветом добавьте следующий стиль в файл Styles.css:

... #validationSummary { color: red; }

Этот элемент управления генерирует порцию HTML-кода, которая выводит список проблем проверки, найденных в данных формы. Чтобы увидеть, как он работает, запустите приложение и щелкните на кнопке "Отправить приглашение RSVP", не вводя никаких данных. Результат показан на рисунке ниже:

При определении свойства WillAttend в классе GuestResponse применялся тип bool, допускающий null, который может принимать значения true и false, но также может быть null. Эта возможность используется для определения, выбрал ли пользователь значение в элементе select по имени WillAttend:

... value="" >Выберите один из вариантов value="true" >Да value="false" >Нет ...

Существует удобное взаимодействие между процессом привязки модели и атрибутом проверки достоверности Required, которым можно воспользоваться. Процесс привязки модели преобразует значение пустой строки первого элемента option в null, но атрибут Required сгенерирует ошибку проверки достоверности, если не будет получено значение true или false. Такое несоответствие позволяет автоматически генерировать ошибку, если пользователь не выбрал значения "Да" или "Нет" в раскрывающемся списке.

Единственная проблема этого подхода в том, что сообщение проверки достоверности бессмысленно для пользователя, который ничего не знает о том, что элемент select, помеченный как "Вы придете?", соответствует свойству модели данных по имени WillAttend. Чтобы решить эту проблему, необходимо предоставить атрибут Required с другим сообщением для отображения, как показано в примере ниже:

Using System.ComponentModel.DataAnnotations; namespace TestAspNet45 { public class GuestResponse { public string Name { get; set; } public string Email { get; set; } public string Phone { get; set; } public bool? WillAttend { get; set; } } }

В свойстве ErrorMessage было указано более полезное сообщение, которое отобразится в браузере, если запустить приложение и снова отправить форму, не вводя никаких данных:

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

Виртуальные пути

Между виртуальными и физическими путями существует стандартное отображение. Виртуальный путь наподобие /Content/RequestReporter.aspx соответствует файлу веб-формы /Content/RequestReporter.aspx. Главное преимущество такого отображения заключается в простоте - достаточно взглянуть на URL и немедленно понять, каким образом виртуальный путь будет применяться для генерации ответа.

Однако прямое отображение между виртуальными и физическими путями не всегда идеально. Например, модернизация приложения может привести к перемещению и переименованию файлов, из-за чего перестанут работать URL, помещенные пользователями в закладки. Может потребоваться согласование приложения Web Forms с более широкой схемой URL, которая не соответствует стандартному подходу. Подобная ситуация распространена в корпоративных приложениях, в которых согласованность URL расценивается как способ помочь пользователям в переходе непосредственно к нужному контенту или функциональности.

Короче говоря, существует множество причин для изменения URL, на которые реагирует приложение, и все они приводят к нарушению работы прямых ссылок между виртуальными и физическими путями. В последующих разделах мы опишем разнообразные подходы, доступные для управления виртуальными путями и позволяющие настраивать схему URL, которую приложение раскрывает внешнему миру.

Вы узнаете, что есть много способов достижения того же самого базового результата. Причина в том, что все эти средства постепенно добавлялись с течением времени. Самое последнее добавление - поддержка маршрутизации URL - является тем средством, с которого следует начинать. Однако мы также рассматриваем ряд удобных старых средств, т.к. часто требуется комбинировать одно из них с маршрутизацией URL, чтобы создавать специфическую функциональность в приложении.

Установка стандартных документов

По соглашению, принятому для приложений Web Forms, начальной веб-форме назначается имя Default.aspx. Это не является требованием, но его нужно придерживаться, поскольку сервер IIS сконфигурирован так, что он ищет стандартные файлы, если никакого файла в URL не указано.

Чтобы продемонстрировать это в действии, мы внесли в метод ProcessRequest(), определенный в файле SimpleModule.cs (который мы создали в предыдущей статье), небольшое изменение, которое обеспечивает вывод значения свойства FilePath и URL в окно Output среды Visual Studio. Изменение показано в примере ниже:

// ... private void ProcessRequest(HttpApplication app) { if (app.Request.FilePath == "/Test.aspx") { app.Server.Transfer("/Content/RequestReporter.aspx"); } WriteMsg("URL запроса: {0} {1}", app.Request.RawUrl, app.Request.FilePath); } // ...

Для тестирования встроенного поведения запустите приложение и запросите корневой URL (у нас он выглядит как http://localhost:32404/, но у вас может быть другой номер порта). Браузер отобразит содержимое файла Default.aspx, а в окне Output будут отображаться следующие сообщения:

Последнее из этих сообщений отражает попытку сервера IIS найти файл, с помощью которого должен быть обслужен запрос. (Первые два сообщения объясняются в следующем разделе.) Сервер IIS имеет возможность отыскать файл Default.aspx для обслуживания запроса корневого URL, т.к. мы соблюдали соглашение об именовании. В противном случае IIS Express потерпел бы неудачу и возвратил браузеру ошибку 404, указывающую на то, что файл найти не удалось.

Сервер IIS ищет следующие стандартные документы: Default.html, Default.asp, index.htm, index.html, iisstart.htm и, наконец, default.aspx. (Мы не знаем, почему имя файла default.aspx представлено символами нижнего регистра, но это не играет роли, потому что имена веб-форм нечувствительны к регистру.)

Переопределить эти стандартные документы можно в файле Web.config. Это стоит делать, если нужно, чтобы по умолчанию использовалась другая стандартная веб-форма, или требуется сократить количество местоположений, в которые сервер IIS просматривает, прежде чем передает веб-форму на обработку среде ASP.NET.

В примере ниже показаны изменения, внесенные в файл Web.config:

... ...

Элемент defaultDocument добавлен в раздел конфигурационного файла. В нем определен атрибут enabled , который по умолчанию установлен в true (значение false предотвратит попытки поиска сервером IIS стандартного документа).

Внутри defaultDocument содержится элемент , представляющий собой коллекцию стандартных документов, которые будет искать IIS. С помощью элемента мы удалили все стандартные документы, а посредством элемента задали специальную политику. В элементе defaultDocument/files/add определен единственный атрибут по имени value, применяемый для указания файла, который IIS должен искать. Мы воспользовались элементом add для установки веб-формы RequestReporter.aspx из папки Content в качестве единственного стандартного документа.

Обратите внимание, что при указании стандартного документа в атрибуте value ведущий символ / отсутствует. Добавление ведущего символа / приводит к отображению сообщения об ошибке.

Чтобы увидеть результат, запустите приложение и запросите URL вида http://localhost:<порт>/, где <порт> это номер порта, прослушиваемого сервером IIS Express на предмет поступления запросов для этого приложения. Новая политика в отношении стандартного документа будет применена, и отобразится вывод, сгенерированный веб-формой RequestReporter.aspx.

Обработка запросов для URL без расширений

При отправке запроса к корневому URL в предыдущем разделе в окне Output среды Visual Studio отображались три сообщения:

URL запроса: / / URL запроса: / / URL запроса: / /default.aspx

Мы объяснили, что последнее сообщение говорит о применении политики IIS, касающейся стандартного документа. Первоначально это был запрос к Default.aspx, но мы изменили политику IIS в отношении стандартного документа. Перед тем, как IIS применяет такую политику, он предоставляет ASP.NET шанс обработать запрос - это причина, по которой отображено первое сообщение.

Среда ASP.NET имеет обработчик для этого запроса, однако по умолчанию он не делает ничего полезного. Таким обработчиком является внутренний класс TransferRequestHandler , отвечающий за обработку URL без расширений, которые позволяют ASP.NET обрабатывать запросы к виртуальным путям, не содержащим файловые расширения, такие как.aspx.

Класс TransferRequestHandler не делает особенно много с запросами для URL без расширений. Он просто указывает серверу IIS на необходимость создания и обработки второго запроса, не используя TransferRequestHandler в качестве обработчика - именно поэтому отображается второе сообщение.

Чтобы делать нечто полезное с запросами для URL без расширений, понадобится создать обработчик и заменить им TransferRequestHandler. Мы добавили в проект новый файл класса по имени ExtensionlessHandler.cs, содержимое которого приведено в примере ниже:

Using System.IO; using System.Web; namespace PathsAndURLs { public class ExtensionlessHandler: IHttpHandler { public void ProcessRequest(HttpContext context) { context.Response.Write("

HTTP-обработчик Expressionless

Этот обработчик будет получать запросы для URL без расширений и с помощью метода HttpServerUtility.Transfer() передавать запросы веб-форме. Определение, какой веб-форме должен быть передан запрос, реализуется элементарно. Если запрошенным URL является /, мы направляем его Default.aspx, а для всех других запросов просто добавляем расширение.aspx к запрошенному URL и проверяем, существует ли в приложении файл с таким именем. Если это так, мы передаем ему запрос, а в противном случае возвращаем ответ с ошибкой 404.

Чтобы обработчик смог принимать запросы, его необходимо зарегистрировать. В примере ниже показаны изменения, внесенные в файл Web.config:

...

Для обработки URL без расширений мы устанавливаем атрибут path в "*." (символы звездочки и точки). Обработка URL без расширений выполняется перед применением политики IIS, касающейся стандартного документа, поэтому предыдущая конфигурация была переопределена и корневой URL (/) отображен на Default.aspx. В качестве дополнения мы можем запрашивать любую веб-форму, не указывая файловое расширение. Таким образом, например, запрос для виртуального пути /Content/RequestReporter сгенерирует ответ на основе веб-формы /Content/RequestReporter.aspx.

Переписывание путей

В предыдущем примере использовался метод HttpServerUtility.Transfer(), который нормально работает с веб-формами, но не очень хорошо с другими типами файлов, такими как обобщенные обработчики (файлы ashx). Мы могли бы применить прием с оболочкой для Page, но это грубый трюк, и мы не являемся его сторонниками.

Имея все это в виду, рассматриваемый далее подход может быть реализован более широко, однако это должно делаться внутри модуля. Прием называется переписыванием путей и представляет собой просто процесс изменения пути, связанного с запросом. Чтобы показать пример использования такого подхода, мы создали файл класса по имени PathModule.cs с содержимым, приведенным в примере ниже:

Using System; using System.IO; using System.Web; namespace PathsAndURLs { public class PathModule: IHttpModule { private static readonly string extensions = { ".aspx", ".ashx" }; public void Init(HttpApplication app) { app.BeginRequest += (src, args) => HandleRequest(app); } private void HandleRequest(HttpApplication app) { if (app.Request.CurrentExecutionFilePathExtension == String.Empty) { string target = null; string vpath = app.Request.CurrentExecutionFilePath; if (vpath == "/") { target = "/Default.aspx"; } else { foreach (string ext in extensions) { if (File.Exists(app.Request.MapPath(vpath + ext))) { target = vpath + ext; break; } } } if (target != null) { app.Context.RewritePath(target); } } } public void Dispose() { // Ничего не освобождается } } }

Так как это модуль, его необходимо зарегистрировать в файле Web.config:

... ...

Этот модуль обрабатывает событие BeginRequest и просматривает запросы, которые не имеют файлового расширения. В рассматриваемом примере изменяется способ обработки корневого URL, т.е. для обработки запросов применяется веб-форма Default.aspx, которую можно увидеть, запустив приложение и запросив /.

Главное улучшение по сравнению с предыдущим примером связано с проверкой существования файлов, имеющих расширения aspx или ashx, если запрошенным URL не является /. Это позволяет приложению поддерживать дружественные URL - именно так называются запросы веб-форм и обработчиков без указания файловых расширений. (Происхождение данного названия нам не известно, однако мы его придерживаемся.)

Прием является вариацией обработки URL без расширений и по-прежнему требует сопоставления виртуальных путей с файлами в приложении, но без указания расширений.aspx или.ashx, которые многие разработчики считают непривлекательными.

Ключевым в модуле является метод RewritePath() , который определен в классе HttpContext. Этот метод позволяет изменить путь при условии, что это делается перед событием жизненного цикла MapRequestHandler .

Метод RewritePath() не имеет ограничений, с которыми мы сталкиваемся при использовании методов класса HttpServerUtility, т.е. появляется возможность поддерживать запросы к обобщенным обработчикам, а также файлам веб-форм.

В классе HttpContext определено несколько перегруженных версий метода RewritePath(), которые описаны в таблице ниже:

Две перегруженных версии метода RewritePath() принимают аргумент типа bool по имени rebase, который отвечает за изменение путей, используемых элементами управления для создания URL - процесс, известный как изменение базы клиента .

В Microsoft предлагается загружаемый пакет под названием URL Rewriting Engine (Механизм переписывания URL) , который позволяет выражать правила переписывания в файле Web.config, а не в коде.

Реальный пример переписывания путей

Ранее метод HttpContext.RewritePath() использовался для добавления файлового расширения, т.е. мы могли бы поддерживать URL без расширений и дружественные URL. С помощью средства переписывания путей можно реализовать очень сложные действия, из-за чего мы применяем его в проектах, требующих поддержки необычных схем URL и таких, которые варьируются на основе характеристик запросов, отличных от путей.

В целях иллюстрации мы рассмотрим пример, основанный на одном из реальных проектов, над которым мы работали недавно. Нам необходимо было повторно построить приложение с применением ASP.NET, но старые URL были жестко закодированы в других приложениях и должны были остаться работоспособными.

Одна из проблем, с которой мы столкнулись, заключалась в том, что запросы к URL вида /accounts нужно было направлять двум веб-формам в зависимости от значения данных формы, имеющего имя function. Когда значение function не превышало 100, запрос должен отправляться веб-форме Default.aspx, а для всех других значений - веб-форме /Content/RequestReporter.aspx (разумеется, это не веб-формы из реального проекта; мы просто хотим воспользоваться уже готовыми файлами в примере приложения).

Чтобы продемонстрировать проблему, мы создали новую веб-форму по имени Split.aspx, контент которой представлен в примере ниже. Эта веб-форма будет эмулировать унаследованных клиентов с жестко закодированными URL:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Split.aspx.cs" Inherits="PathsAndURLs.Split" %>

Веб-форма содержит простую HTML-форму, которая позволяет ввести значение function и отправить его серверу по щелчку на кнопке "Отправить". Элемент