Эндрю Троелсен - ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

// Здесь ничего не происходит, но это гарантирует

// вторичный запрос к странице.

}

}

то эти события будут перехвачены вашей страницей независимо от значения, заданного для AutoEventWireup.

В качестве заключительного замечания напомним, что с момента вызова события Unload вы не сможете взаимодействовать с подлежащим отправке HTTP-ответом (если вы попытаетесь вызвать члены объекта HttpResponse, среда выполнения сгенерирует соответствующее исключение). Поэтому здесь обработчик события Unload просто отправляет строку текста в файл на локальном диске C.

Еще одним событием, которое может происходить в цикле существования страницы, является событие Error, которое также работает в паре с делегатом System.EventHandler. Это событие возникает в том случае, когда метод производного от Page типа генерирует исключение, оставшееся без явной обработки. Предположим, что вы обработали событие Click для типа Button на странице, и в пределах обработчика события (здесь он называется btnGetFile_Click) вы пытаетесь записать, содержимое локального файла в HTTP-ответ.

Также предположим, что вам не удалось проверить присутствие этого файла с помощью стандартной технологии структурированной обработки исключений. Если при этом вы предусмотрели обработку события Error страницы, вы получите шанс решить возникшую проблему, чтобы пользователь не увидел безобразную информацию об ошибке. Рассмотрите следующий программный код.

public partial class _Default: System.Web.UI.Page {

public _Default() {

…

// Создание объекта для события Error.

this.Error += new EventHandler(_Default_Error);

void _Default_Error(object sender, EventArgs е) {

// Уничтожение текущего ответа, сообщение об сшибке

// и информирование среды выполнения о том,

// что ошибка обработана.

Response.Clear();

Response.Write("Извините… не могу найти необходимый файл.");

Server.ClearError();

}

protected void btnGetFile_Click(object sender, EventArgs e) {

// Попытка открыть несуществующий файл.

// Это порождает событие Error для данной страницы.

System.IO.File.ReadAllText(@"C:\IDontExist.txt");

}

…

}

Здесь обработчик события Error начинается с очистки всего содержимого имеющегося HTTP-ответа и вывода общего сообщения об ошибке. Чтобы получить доступ к конкретному объекту System.Exception, вы можете использовать метод HttpServerUtility.GetLastError(), доступ к которому обеспечивает унаследованное свойство Server.

void _Default_Error(object sender, EventArgs e) {

Response.Clear();

Response.Write("Извините… не могу найти необходимый файл. ‹br›");

Response.Write(string.Format("Ошибка: ‹b›{0}‹/b›", Server.GetLastError().Message));

Server.ClearError();

}

Наконец, отметьте, что перед выходом из этого общего обработчика ошибок с помощью свойства Server явно вызывается метод HttpServerUtility.ClearError(). Это необходимо, чтобы информировать среду выполнения о том, что проблема вами решена, и дальнейшего вмешательства системы не требуется. Если вы забудете сделать это, конечному пользователю будет предъявлено окно среды выполнения с сообщением об ошибке. На рис. 23.19 показан результат выполнения нашей процедуры обработки ошибок.

Рис. 23.19. Обработка ошибок на уровне страницы

В данный момент вы должны чувствовать себя довольно уверенно при работе с типом Page ASP.NET. Имея такую основу, вы теперь готовы перейти к выяснению роли Web-элементов управления ASP.NET.

Исходный код. Файлы примера PageLifeCycle размещены в подкаталоге, соответствующем главе 23.

Возможно, самым большим преимуществом ASP.NET является возможность компоновки пользовательского интерфейса страниц с помощью типов, определенных в пространстве имен System.Web.UI.WebControls. Соответствующие этим типам элементы управления (для которых могут использоваться названия серверные элементы управления, Web-элементы управления, или элементы управления Web-формы) оказываются чрезвычайно полезными в том, что они автоматически генерируют HTML-код, необходимый для запрашивающего браузера, и предлагают набор событий, которые может обработать Web-сервер, Каждому элементу управления ASP.NET соответствует класс из пространства имен System.Web.UI.WebControls, поэтому такой элемент управления может использоваться в рамках технологии ООП как в файле *.aspx (в блоке ‹script›), так и в файле внешнего кода поддержки.

Вы уже видели, что при настройке Web-элемента управления в окне свойств Visual Studio 2005 ваши изменения записываются в определение этого элемента в файле *.aspx в виде набора пар имен и значений. Например, при добавлении нового TextBox в окне проектирования файла *.aspx и изменении свойств BorderStyle, BorderWidth, BackColor, BorderColor и Text средствами IDE открывающий дескриптор ‹asp:TextBox› может измениться так, как показано ниже.

‹asp:TextBox id=myTextBox runat="server" BorderStyle="Ridge" BorderWidth="5px" BackColor="PaleGreen" BorderColor="DarkOliveGreen" Text= "Привет, Старик!" ›

‹/asp:TextBox›

Поскольку HTML-декларация Web-элемента управления в конечном счете (в цикле динамический компиляции) становится членом-переменной из пространства имен System.Web.UI.WebControls, вы можете взаимодействовать с членами соответствующего типа в рамках блока ‹script› сервера или файла с внешним кодом поддержки страницы, например:

public partial class _Default: System.Web.UI.Page {

…

protected void btnChangeTextBoxColor_Click(object sender, EventArgs e) {

// Изменение данных HTTP-ответа для данного элемента.

this.myTextBox.BackColor = System.Drawing.Color.Red;

}

}

Все Web-элементы управления ASP.NET восходят к общему базовому классу с именем Sуstem.Web.UI.WebControls.WebControl. Класс WebControl получается из System.Web.UI.Control (который, в свою очередь, получается из System.Objeсt). Классы Control и WebControl определяют свои наборы свойств, общие для всех серверных элементов управлений. Перед тем как рассмотреть наследуемые функциональные возможности элементов управления, давайте выясним, что формально означает обработка серверных событий.

С учетом сегодняшнего состояния World Wide Web нельзя не принимать во внимание природу взаимодействия браузера и Web-сервера. В основе такого взаимодействия лежит цикл запросов и ответов HTTP в процессе выполнения которых состояния не сохраняются. И хотя серверные элементы управления ASP.NET делают все возможное, чтобы избавить разработчика от необходимости непосредственного обращения к настройкам протокола HTTP, никогда не забывайте о том, что трактовка Web в терминах управления событиями – это великолепный "фокус" CLR, далеко не эквивалентный модели управления событиями пользовательского интерфейса Windows.