5.12. Некоторые приёмы работы со страницами

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

Класс HtmlForm

Класс HtmlForm является производным от HtmlContainerControl и обеспечивает разработчику программный доступ к HTML-элементу <form>, осуществляемый посредством свойств, перечисленных в табл. 24.

Таблица 24

Специфичные свойства класса HtmlForm

Свойство	Описание
DefaultButton	Строка с идентификатором кнопочного элемента управления, который будет используемым по умолчанию элементом 
DefaultFocus	Строка с идентификатором кнопочного элемента управления, который получит фокус ввода при отображении формы 
Disabled	Булево значение, указывающее, отключена ли форма. Соответствует HTML-атрибуту disabled
EncType	Возвращает и позволяет задать тип кодировки. Соответствует HTML-атрибуту enctype
Method	Значение, указывающее, как браузер возвращает данные формы серверу. По умолчанию это свойство имеет значение POST; при желании ему можно присвоить значение GET
Name	Возвращает значение свойства UniqueID
SubmitDisabledControls	Указывает, следует ли отключенным на клиенте элементам управления предоставлять свои значения для включения в состав возвращаемых данных. По умолчанию ‑ false 
TagName	Возвращает значение "form"
Target	Имя фрейма или окна для рендеринга сгенерированного для страницы HTML-кода

Форма всегда должна иметь уникальное имя. Если программист никак ее не назвал, ASP.NET сама генерирует имя по встроенному алгоритму. Идентификатор формы можно задать в свойстве ID либо в свойстве Name. Когда установлены оба эти свойства, предпочтение отдается первому¹.

В составе одной страницы не может быть нескольких видимых серверных форм. То есть, на странице можно разместить несколько элементов <form> с атрибутом runat="server", но только у одного из них свойство Visible может быть равно true. Допускается наличие в составе страницы серверной формы и обычной HTML-формы (т. е. без атрибута runat="server").

Перенаправление пользователя

При разработке приложений ASP.NET типичной является задача перенаправления пользователя на другую страницу. Например, в обработчике события Click кнопки нужно проверить введенные пользователем данные регистрации и направить его на страницу «Успешная регистрация». Как правило, для этих целей используют метод Redirect() объекта Response:

protected void btnRegister_Click(object sender, EventArgs e)

{

if (IsUserDataCorrect())

{

Response.Redirect("~/success.aspx");

}

}

Метод Response.Redirect() может перенаправить пользователя на любой URL, не обязательно на страницу текущего веб-приложения. Кстати, обратите внимание, что в коде обработчиков событий и в атрибутах серверных элементов управления ASP.NET для указания корня веб-приложения можно использовать символ "~".

Альтернативой методу Response.Redirect() может служить метод Server.Transfer(). При использовании этого метода переход осуществляется на сервере: URL новой страницы не отражается в строке адреса браузера, а если за вызовом метода Transfer() следует еще какой-либо код, он никогда не выполняется. Ограничение метода Transfer() – переход возможен только на страницы внутри одного веб-приложения.

Межстраничный постинг

В ASP.NET 2.0 появился механизм, позволяющий изменить стандартный цикл обработки страницы ‑ возврат данных самой себе. В ASP.NET 2.0 те элементы управления страницы, которые реализуют интерфейс IButtonControl, можно сконфигурировать таким образом, чтобы они осуществляли возврат формы другой странице. Это называется межстраничным постингом.

Для межстраничного постинга у кнопочных элементов управления изменяется свойство PostBackUrl. В нем задается URL целевой страницы.

<asp:button ID="btnPostBacks" runat="server" Text="Click"

PostBackUrl="target.aspx" />

Для ссылки на страницу, выполнившую отправку, и доступа ко всем ее элементам управления используется свойство PreviousPage. Вот код целевой страницы, извлекающий содержимое текстового поля формы:

protected void Page_Load(object sender, EventArgs e)

{

// находим элемент на предыдущей странице

var tbxControl = (TextBox)PreviousPage.FindControl("tbxName");

}

Используя свойство PreviousPage класса Page, можно обращаться к любым элементам управления страницы, выполнившей постинг. Доступ к элементам управления осуществляется слабо типизированным и косвенным способом, через метод FindControl(). Дело в том, что целевой странице не известен тип исходной. PreviousPage объявлено как свойство типа Page, а потому оно не может предоставить доступ к странице производного класса. Если страница была вызвана сама по себе, а не является объектом межстраничного перехода, свойство PreviousPage возвращает null.

Свойство IsCrossPagePostBack класса Page возвращает true, если текущая страница вызвала другую страницу ASP.NET. Разумеется, для целевой страницы оно всегда возвращает false.

Обработка ошибок

Если в процессе работы страницы было сгенерировано необработанное исключение, ASP.NET показывает «желтый экран смерти» ‑ стандартную страницу, содержащую информацию об ошибке. Естественно, в реальных приложениях желательно изменить данное поведение (хотя бы с точки зрения дружественного дизайна).

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

Рассмотрим пример обработчика события Error на странице.

protected void Page_Error(object sender, EventArgs e)

{

// перехватываем ошибку

var ex = Server.GetLastError();

// выбираем в зависимости от её типа страницу и делаем переход

if (ex is NotlmplementedException)

{

Server.Transfer("~/errorpages/notimplemented.aspx");

}

else

{

Server.Transfer("~/errorpages/apperror.aspx");

}

}

Объект, представляющий исключение, можно получить с помощью метода GetLastError() объекта Server. В обработчике события Error можно передать управление определенной странице и таким образом вывести персонализированное сообщение, индивидуальное для конкретной ошибки. При этом URL в адресной строке браузера не изменится, поскольку переключение страниц будет выполнено на сервере. Благодаря использованию метода Server.Transfer() информация об исключении сохранится, и страница с сообщением об ошибке сама сможет вызвать метод GetLastError(), чтобы вывести для пользователя максимально подробные сведения. После того как исключение будет полностью обработано, необходимо удалить объект-ошибку, вызвав метод Server.ClearError().

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

Для работы с ошибками можно использовать раздел <customErrors> файла web.config приложения.

<system.web>

<customErrors mode="RemoteOnly" />

</system.web>

Обязательный атрибут mode определяет, будет ли вывод пользовательских сообщений об ошибках включен, отключен или включен только для удаленных клиентов. По умолчанию он имеет значение RemoteOnly, при котором удаленные пользователи видят стандартную страницу с минимально информативным сообщением об ошибке, а локальные пользователи при этом получают сообщения ASP.NET с детальными описаниями ошибок.

Какое бы значение не было выбрано для атрибута mode, стандартные страницы ASP.NET с сообщениями об ошибках не порадуют информативностью. Для того чтобы выводить более профессиональные и дружественные пользователю сообщения, которые были бы согласованы с общим интерфейсом сайта, необходимо включить в файл web.config такие установки:

<system.web>

<customErrors mode="RemoteOnly"

defaultRedirect="GenericError.aspx" />

</system.web>

После этого, какой бы ни была ошибка, ASP.NET станет переадресовывать пользователя на страницу GenericError.aspx¹, содержимое и структура которой всецело определяются разработчиком. Это происходит благодаря необязательному атрибуту defaultRedirect, в котором задается страница с сообщением об ошибке. Если атрибут mode установлен в On, и локальные, и удаленные пользователи перенаправляются на стандартную страницу с сообщением об ошибке. Если же этот атрибут установлен в RemoteOnly, удаленные пользователи перенаправляются на указанную вами страницу, а локальные (которыми обычно являются разработчики) ‑ на выводимую по умолчанию.

Перенаправление пользователей к единой для всех ошибок странице ‑ не единственная возможность, которую предоставляет ASP.NET; эта система позволяет задать отдельную страницу для каждой из ошибок HTTP. Соответствие между страницами с сообщениями об ошибках и кодами состояния HTTP также определяется в web.config. Для раздела <customErrors> поддерживается внутренний тэг <error>, который можно использовать для связывания кодов состояния HTTP с пользовательскими страницами ошибок.

<customErrors mode="RemoteOnly"

defaultRedirect="GenericError.aspx" >

<error statusCode="404" redirect="Error404.aspx" />

<error statusCode="500" redirect="Error500.aspx" />

</customErrors>

В атрибуте statusCode этого тэга задается код ошибки HTTP, а в атрибуте redirect – страница, куда в случае возникновения такой ошибки должен быть перенаправлен пользователь.