Для примера предположим, что вы добавили в свой файл *.aspx еще один тип Button, который реализует обработчик события Click сервера так.
protected void btnHttpResponse_Click(object sender, EventArgs e) {
Response.Write("‹b›Moe имя :‹/b›‹br›");
Response.Write(this.ToString());
Response.Write("‹br›‹br›‹b›Boт Ваш последний запрос:‹/b›‹br›");
Response.WriteFile("MyHTMLPage.htm");
}
Роль этой вспомогательной функции (которая может вызываться некоторым: обработчиком события на стороне сервера) очень проста. Единственным заслуживающим внимания моментам здесь является то, что метод HttpResponse. WriteFile() теперь отправляет содержимое файла *.htm сервера из корневого каталога Web-узла.
Снова подчеркнем, что вы, конечно, можете использовать подход "старой школы", чтобы отображать HTML-дескрипторы и содержимое, используя метод Write(), но этот подход в рамках ASP.NET применяется гораздо реже, чем в рамках классической технологии ASP. Причина здесь (снова) в наличии серверных Web-элементов управления. Скажем, чтобы отобразить блок текстовых данных в браузере, достаточно просто присвоить подходящее значение свойству Text элемента Label.
Перенаправление пользователей
Другой возможностью типа HttpResponse является перенаправление пользователя по новому адресу URL.
protected void btnSomeTraining_Click(object sender, EventArgs e) {
Response.Redirect("http://www.IntertechTraining.com");
}
Если этот обработчик событий вызвать с помощью вторичного обращения клиента к серверу, пользователь будет автоматически перенаправлен по указанному URL.
Замечание. Вызов метода HttpResponse.Redirect() всегда влечет за собой обращение к браузеру клиента. Если нужно просто передать управление файлу *.aspx в том же виртуальном каталоге, более эффективным будет вызов метода HttpServerUtility.Transfer() (доступного через наследуемое свойство Server).
На этом мы завершим обсуждение функциональных возможностей System.Web.UI.Page. Чуть позже мы рассмотрим роль базового класса System.Web.UI.Control, однако нашим следующим заданием будет исследование цикла существования объектов, производных от Page.
Исходный код. Файлы примера FunWithPageMembers размещены в подкаталоге, соответствующем главе 23.
Цикл существования Web-страницы ASP.NET
Каждая Web-страница ASP.NET имеет свой "жизненный цикл". Когда среда выполнения ASP.NET получает входящий запрос для данного файла *. aspx, в памяти размещается соответствующий тип, производный от System.Web.UI.Page, для создания которого используется конструктор, заданный по умолчанию. После этого среда обработки автоматически генерирует серию событий.
По умолчанию сгенерированная в Visual Studio 2005 страница с внешним кодом поддержки определяет обработчик события Load страницы.
public partial class _Default: System.Web.UI.Page {
protected void Page_Load(object sender, EventArgs e) {
}
}
Кроме события Load, тип Page может выполнять перехват любого из событий, указанных в табл. 23.8 в том порядке, в котором эти события возникают.
Таблица 23.8. События типа Page
Событие Описание PreInit Используется инфраструктурой .NET для размещения Web-элементов управления, применения тем, создания шаблона страницы и установки профиля пользователя. Вы можете перехватить это событие, чтобы внести изменения в соответствующий процесс Init Используется для установки свойств Web-элементов управления в предыдущее состояние с помощью вторичного запроса или просмотра данных состояния (подробнее об этом говорится в главе 24) Load Возникает тогда, когда страница и ее элементы управления полностью инициализированы, а их предыдущие значения восстановлены. С этого момента вполне безопасно начать взаимодействие с любым из Web-элементов "Событие, вызвавшее вторичный запрос" События с таким именем, конечно же, не существует. Так здесь обозначено любое событие, заставившее браузер отправить вторичный запрос Web-cер-веру (это может быть, например, щелчок на кнопке) PreRender Привязка данных и конфигурация пользовательского интерфейса завершена, и элементы управления готовы отправить свои данные в поток исходящего HTTP-ответа Unload Страница и её элементы управления завершили процесс передачи данных, и объект страницы готов к уничтожению. Взаимодействие с исходящим HTTP-ответом в этот момент породит ошибку среды выполнения. Можно выполнить захват этого события для "уборки мусора" на уровне страницы (чтобы закрыть файлы и базы данных, выполнить процедуру выхода из системы, освободить ресурсы и т.д.)
Замечание. Все события типа Page работают с делегатом System.EventHandler.
Роль атрибута AutoEventWireUp
Чтобы обработать события для страницы, нужно добавить в блок ‹script› или файл с внешним кодом поддержки подходящий обработчик события. В отличие от ASP.NET 1.x. теперь не требуется вводить всю программную логику события вручную. Нужна только определить соответствующий метод, используя следующий шаблон.
protected Page_nameOfTheEvent(object sender, EventArgs e)
Например, cобытие Unload можно обработать так.
public partial class _Default: System.Web.UI.Page {
protected void Page_Load(object sender, EventArgs e) {
}
protected void Page_Unload(object sender, EventArgs e) {
}
}
Этот метод, как по волшебству, вызывается при выгрузке страницы (несмотря на то, что вы не применяли синтаксис событий C#), поскольку атрибут AutoEventWireUp устанавливается равным true (истина) по умолчанию в директиве ‹%@Page%› вашего файла *.aspx.
‹%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %›
Как подсказывает имя этого атрибута, при его активизации будет создана необходимая оснастка событий в рамках автоматически генерируемого парциального класса, описанного в этой главе выше. Если установить этот атрибут равным false, не будут вызваны обработчики событий ни для Load, ни для Unload страницы Default (вы можете проверить это непосредственно, установив контрольные точки в пределах обработчиков событий Page_Load() и Page_Unload()).
Однако, если вы используете стандартный синтаксис событий C# для обработки событий Load и Unload, как показано ниже:
public partial class _Default: System.Web.UI.Page {
public _Default() {
// Явный перехват событий Load и Unload.
this.Load += new EventHandler(Page_Load);
this.Unload += new EventHandler(Page_Unload);
}
protected void Page_Load(object sender, EventArgs e) {
Response.Write("Сработало событие Load!");
}
protected void Page_Unload(object sender, EventArgs e) {
// Направить данные в HTTP-ответ здесь невозможно,
// поэтому выполняется запись в локальный файл.
System.IO.File.WriteAllText(@"C:MyLog.txt", "Выгрузка страницы.");
}
protected void btnPostback_Click(object sender, EventArgs e) {
// Здесь ничего не происходит, но это гарантирует
// вторичный запрос к странице.
}
}
то эти события будут перехвачены вашей страницей независимо от значения, заданного для AutoEventWireup.
В качестве заключительного замечания напомним, что с момента вызова события Unload вы не сможете взаимодействовать с подлежащим отправке HTTP-ответом (если вы попытаетесь вызвать члены объекта HttpResponse, среда выполнения сгенерирует соответствующее исключение). Поэтому здесь обработчик события Unload просто отправляет строку текста в файл на локальном диске C.
Еще одним событием, которое может происходить в цикле существования страницы, является событие Error, которое также работает в паре с делегатом System.EventHandler. Это событие возникает в том случае, когда метод производного от Page типа генерирует исключение, оставшееся без явной обработки. Предположим, что вы обработали событие Click для типа Button на странице, и в пределах обработчика события (здесь он называется btnGetFile_Click) вы пытаетесь записать, содержимое локального файла в HTTP-ответ.
Также предположим, что вам не удалось проверить присутствие этого файла с помощью стандартной технологии структурированной обработки исключений. Если при этом вы предусмотрели обработку события Error страницы, вы получите шанс решить возникшую проблему, чтобы пользователь не увидел безобразную информацию об ошибке. Рассмотрите следующий программный код.
