ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание
Шрифт:
Наконец, отметьте, что перед выходом из этого общего обработчика ошибок с помощью свойства Server явно вызывается метод HttpServerUtility.ClearError. Это необходимо, чтобы информировать среду выполнения о том, что проблема вами решена, и дальнейшего вмешательства системы не требуется. Если вы забудете сделать это, конечному
Рис. 23.19. Обработка ошибок на уровне страницы
В данный момент вы должны чувствовать себя довольно уверенно при работе с типом Page ASP.NET. Имея такую основу, вы теперь готовы перейти к выяснению роли Web-элементов управления ASP.NET.
Исходный код. Файлы примера PageLifeCycle размещены в подкаталоге, соответствующем главе 23.
Природа Web-элементов управления
Возможно, самым большим преимуществом 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› может измениться так, как показано ниже.
Поскольку HTML-декларация Web-элемента управления в конечном счете (в цикле динамический компиляции) становится членом-переменной из пространства имен System.Web.UI.WebControls, вы можете взаимодействовать с членами соответствующего типа в рамках блока ‹script› сервера или файла с внешним кодом поддержки страницы, например:
Все 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.
Поэтому, хотя пространства имен System.Windows.Forms и System.Web.UI.WebControls определяют типы с аналогичными именами (Button, TextBox, GridView, Label и т.д.), они предлагают разные наборы событий. Например, когда пользователь помещает указатель мыши на поверхность Button Web-формы, у вас нет возможности обработать событие MouseMove на стороне сервера. И это, очевидно, разумно. (Кто обрадуется перспективе посылать вторичные запросы серверу при каждом движении мыши?)
Поэтому Web-элементы управления ASP.NET предлагают ограниченные наборы событий, результатом которых, в конечном итоге, оказывается новое обращение к Web-серверу. Для обработки событий клиента вы должны создать соответствующие элементы программного кода сценария JavaScript/VBScript клиента, которые будут обрабатываться механизмом обслуживания сценариев соответствующего браузера.
Свойство AutoPostBack
Следует также подчеркнуть то, что многие Web-элементы управления ASP.NET поддерживают свойство AutoPostBack (это очень важно для CheckBox, RadioButton и TextBox, а также для элементов управления, получаемых из абстрактного типа ListControl). По умолчанию это свойство получает значение false (ложь), что означает отключение автоматической отправки серверных событий (даже при наличии соответствующей настройки в файле внешнего кода поддержки). Во многих случаях это оказывается именно тем, что требуется. Но если вы хотите, чтобы какой-то из элементов управления обращался к обработчику события на сервере, нужно установить для AutoPostBack значение true (истина). Это может оказаться полезным тогда, когда данные одного элемента управления должны автоматически становиться данными другого в пределах одной и той же страницы.
Для примера создайте Web-узел, содержащий один элемент управления TextBox (с именем txtAutoPostback) и один ListBox (с именем lstTextBoxData). Затем обработайте событие TextChanged элемента TextBox и в серверном обработчике события добавьте в ListBox текущее значение TextBox (уследили за идеей?).
Если выполнить приложение в таком виде, вы обнаружите, что в процессе ввода в TextBox ничего не происходит. Более того, ничего не произойдет и после ввода в TextBox при переходе к следующему элементу управления по нажатию клавиши табуляции. Причина в том, что свойство AutoPostBack типа TextBox по умолчанию имеет значение false. Но если установить для этого свойства значение true, как показано ниже:
то вы увидите, что при выходе из TextBox по нажатию клавиши табуляции (или при нажатии клавиши ‹Enter›), ListBox автоматически получает текущее значение из TextBox. Без сомнения, кроме случая добавления данных одного элемента управления в другой, необходимости изменения состояния свойства AutoPostBack в других случаях не возникает.