Класс Page. Основы Master Pages
Страница 10 из 11
Создание страницыИспользование шаблонов дизайна налагает свои требования на страницы. Поскольку шаблон содержит элементы управления ContentPlaceHolder, то страница должна содержать элементы управления Content, содержащие код разметки и другие элементы управления, которые будут отображать на результирующей странице. На странице не должно быть каких-либо серверных элементов управления или кода разметки вне элементов управления Content.
- Страница 2
Страница 3
Страница 1
Также как и в случае с шаблоном, код логики страницы создается обычным образом. Единственное отличие в том, что страница не имеет собственных объектов вроде HeadControl, поэтому нужно использовать ссылку на страницу шаблона через свойство Master.
Protected void Page_Load(object sender, EventArgs e){
if (!Page.IsPostBack) Master.Page.Header.Title = "Домашняя страница";}
protected void btnShow_Click(object sender, EventArgs e){ PlaceHolder.Controls.Add(
new LiteralControl(" alert("Добрый день, " + txtName.Text + ""); "));
Master.Page.Header.Title = "Добрый день, " + txtName.Text;}
Для того чтобы привязать страницу к шаблону используется атрибут MasterPageFile директивы Page. Если же необходимо привязать один и тот же шаблон ко всем страницам в директории, то нет необходимости указывать атрибут MasterPageFile для каждой страницы, достаточно задать базовый шаблон в файле web.config.
Кроме того, ASP.NET позволяет устанавливать тему оформления программным образом. Как было сказано выше, загрузка и связывание с шаблоном оформления происходит во время подготовки страницы к инициализации. Поэтому, если необходимо сменить шаблон оформления страницы, необходимо делать это в обработчике события PreInit.
Protected void Page_PreInit(object sender, EventArgs e){ Page.MasterPageFile = "AnotherMaster.master";}
Обработка шаблонов средой ASP.NETВо время первого обращения к какой-либо странице, ASP.NET осуществляет поиск и компиляцию сборок для всех шаблонов в директории. Эта операция занимает некоторое время, зависящее от количества страниц шаблонов в директории, но выполняется только один раз. Поэтому, если в директории присутствуют не использующиеся шаблоны, это не приводит к потерям производительности в процессе работы приложения, единственное неудобство – дополнительное время, а компиляцию ненужных сборок для неиспользуемых страниц.
При обращении к aspx файлу страницы с заданным шаблоном оформления процесс компиляции почти ничем не отличается от обычного процесса компиляции страницы, за исключением того, что создается класс шаблона MasterPage ссылка на который доступна в свойстве Page.Master.
Затем страница проходит все те шаги, которые описаны выше в этой статье, в результате чего генерируется HTML код, который отправляется клиенту. В полученном браузером HTML коде уже нельзя определить, какая часть кода задана в шаблоне оформления, а какая часть кода определена на самой странице, поскольку элементы управления ContentPlaceHolder и Content не имеют каких-либо HTML соответствий и не порождают дополнительных тегов, кроме своего содержимого.
Домашняя страница
Страница 2 |
|
Время: 20.03.2005
Поскольку шаблон является подмножеством страницы, то допустимо создавать вложенные шаблоны, указывая для шаблона в директиве Master путь к другому шаблону с помощью атрибута MasterPageFile. Для этого необходимо в основном шаблоне определить элементы управления ContentPlaceHolder, а в «дочерних» шаблонах на ряду с ContentPlaceHolder элементами определить элементы управления Content для замещения содержимого элементов ContentPlaceHolder базового шаблона.
Использование разных шаблонов для разных браузеровЛюбому Web-разработчику хорошо известно, что разные браузеры (например, Microsoft Internet Explorer, Netscape Navigator, Mozilla FireFox и др.) по разному обрабатывают HTML код и, что особенно важно, обладают несколько разными программируемыми моделями, что усложняет создание клиентских сценариев.
Для разрешения этой проблемы существует два основных метода, которые используются и в ASP.NET 1.x и в классическом ASP. Первый заключается в том, что браузеру клиента отправляется клиентский код, который, основываясь на типе и версии браузера, выполняет некоторые действия. Второй состоит в перенаправлении браузера пользователя на те страницы, которые специально оптимизированы под конкретный браузер. ASP.NET упрощает создание подобных страниц, поскольку среда выполнения генерирует HTML код для стандартных серверных элементов управления основываясь на информации о браузере клиента.При использовании шаблонов оформления, можно создать несколько шаблонов, для каждого браузера и в директиве Page страницы указать, какой шаблон использовать.
Список браузеров и используемые средой ASP.NET свойства браузеров можно найти в директории %WINDIT%\Microsoft.NET\Framework\версия\CONFIG\Browsers.
Первые страницы на ASP.NET дают первоначальное знакомство с солидной технологией создания веб-приложений. Не усложняя первые шаги фреймворками WebForms, MVC, WebAPI создадим простые веб-страницы с внедренным программным кодом для двух обработчиков представлений - ASPX и Razor . Обработчики кода, называемые еще механизмами визуализации или движками, предназначены для динамического создания веб-страницы путем замены программного кода соответствующей html разметкой.
Движок ASPX - стандартная модель добавления кода на веб-страницу ASP.NET. ASPX использует блоки объявления типов, процедур и переменных runat="server"> и встроенный блок отрисовки html разметки. Модель добавления программного кода ASPX с некоторыми изменениями перешла в ASP.NET из первой платформы ASP.
Razor новый механизм визуализации программного кода в html странице. Razor это интеллектуальный движок динамического создания html разметки. Имеет понятный синтаксис и упрощает внедрение кода в веб-страницу. Для отличия программного кода от html кода использует символ @, в сочетании с фигурными скобками и без скобок.
Для создание первых веб-страниц будем использовать бесплатную программную среду для работы с веб-сайтами WebMatrix . На текущий момент создана 3-я версия этого, достаточного для создания профессиональных сайтов, инструмента программирования. Скачать ее можно с сайта компании Microsoft по ссылке WebMatrix . В состав программы WebMatrix входит все необходимое для создания и тестирования веб-сайтов на основе ASP.NET: редактор кода с подсветкой и IntelliSense, вебсервер IIS Express, система управления базами данных SQL LocalDB.
Сайт включает из три страницы: главная и две одинаковые страницы динамического создания таблиц на движках ASPX и Razor. Размерность таблицы можно задавать в строке запроса двумя параметрами. Надо сказать, что в принципе оба обработчика эффективно создают html разметку, но предоставляют разный комфорт работы.
Движок ASPX требует заключения всех частей и частичек программного кода в блоки вида. Типы, процедуры и переменные можно объявлять в блоке runat="server"> … . Атрибут runat="server" отличает данный блок от блока javascript и обозначает обработку кода в этом блоке непосредственно на сервере.
Листинг №1 Вебстраница на движке ASPX< !DOCTYPE html > < html xmlns ="http://www.w3.org/1999/xhtml"> < head runat ="server"> < meta http-equiv ="Content-Type" content ="text/html; charset=utf-8"/> < title > < link rel ="stylesheet" type ="text/css" href ="/css/style.css" /> < body > < h1 > < p >< a href ="/"> На главную < p > Количество стобцов - < br /> Количество строк - < table > < tr > < tr > < td >
Ниже показан код веб страницы для обработчика внедренного программного кода Razor . Обратите внимание на гармоничное слияние html кода и выражений на языке C#. Движок Razor позволяет использовать html теги непосредственно внутри программного кода: интеллектуальная составляющая обработчика ловко отделяет html разметку от программного кода C#.
Листинг №2 Вебстраница на движке Razor< !DOCTYPE html > < html lang ="ru"> < head > < meta http-equiv ="Content-Type" content ="text/html; charset=utf-8"/> < meta charset ="utf-8" /> < title > @ namepage < link rel ="stylesheet" type ="text/css" href ="/css/style.css" /> < body > < h1 > @ namepage < p >< a href ="/"> На главную @ Html.Raw(createLinks.GetLinks()) < p > Количество стобцов - @ numberColumns < br /> Количество строк - @ numberRows < table > < tr > @ for (int i = 0; i < numberColumns; i++) { < th > Заголовок № @(i + 1 ) } @ for (int row = 0; row < numberRows; row++) { < tr > @ for (int col = 0; col < numberColumns; col++) { < td > @(row+1 ) х@(col+1 ) } }
Протестировать работу сайта можно несколькими способами:
В заключении можно добавить, что для пользователя сайта, информация о том на каком движке работают веб-страницы не сильно важна. Но программист, поработав с каждым обработчиком внедренного кода, наверняка сделает выбор в пользу Razor.
ASP.NET master pages allow you to create a consistent layout for the pages in your application. A single master page defines the look and feel and standard behavior that you want for all of the pages (or a group of pages) in your application. You can then create individual content pages that contain the content you want to display. When users request the content pages, they merge with the master page to produce output that combines the layout of the master page with the content from the content page.
How Master Pages WorkMaster pages actually consist of two pieces, the master page itself and one or more content pages.
Master PagesA master page is an ASP.NET file with the extension .master (for example, MySite.master) with a predefined layout that can include static text, HTML elements, and server controls. The master page is identified by a special directive that replaces the directive that is used for ordinary .aspx pages. The directive looks like the following.
The @ Master directive can contain most of the same directives that a directive can contain. For example, the following master-page directive includes the name of a code-behind file, and assigns a class name to the master page.
In addition to the @ Master directive, the master page also contains all of the top-level HTML elements for a page, such as html, head, and form. For example, on a master page you might use an HTML table for the layout, an img element for your company logo, static text for the copyright notice, and server controls to create standard navigation for your site. You can use any HTML and any ASP.NET elements as part of your master page.
Replaceable Content PlaceholdersIn addition to static text and controls that will appear on all pages, the master page also includes one or more controls. These placeholder controls define regions where replaceable content will appear. In turn, the replaceable content is defined in content pages. After you have defined the controls, a master page might look like the following.
Master page title
You define the content for the master page"s placeholder controls by creating individual content pages, which are ASP.NET pages (.aspx files and, optionally, code-behind files) that are bound to a specific master page. The binding is established in the content page"s @ Page directive by including a attribute that points to the master page to be used. For example, a content page might have the following @ Page directive, which binds it to the Master1.master page.
In the content page, you create the content by adding controls and mapping them to controls on the master page. For example, the master page might have content placeholders called Main and Footer. In the content page, you can create two controls, one that is mapped to the control Main and the other mapped to the control Footer, as shown in the following figure.
Replacing placeholder content
In general, this structure has no effect on how you construct your pages or program them. However, in some cases, if you set a page-wide property on the master page, it can affect the behavior of the content page, because the master page is the closest parent for the controls on the page. For example, if you set the property on the content page to true but set the same property to false in the master page, view state will effectively be disabled because the setting on the master page will take priority.
Master Page and Content Page PathsWhen a content page is requested, its content is merged with the master page, and the page runs in the context of the content page. For example, if you get the property of the object, whether in content page code or in master page code, the path represents the location of the content page.
The master page and content page do not have to be in the same folder. As long as the attribute in the content page"s @ Page directive resolves to a .master page, ASP.NET can merge the content and master pages into a single rendered page.
Referencing External ResourcesBoth the content page and master page can contain controls and elements that reference external resources. For example, both might contain image controls that reference image files, or they might contain anchors that reference other pages.
The context for the merged content and master pages is that of the content page. This can affect how you specify URLs for resources, such as image files and target pages, in anchors.
Server ControlsIn server controls on master pages, ASP.NET dynamically modifies the URLs of properties that reference external resources. For example, you might put an control on a master page and set its property to be relative to the master page. At run time, ASP.NET will modify the URL so that it resolves correctly in the context of the content page.
ASP.NET can modify URLs in the following cases:
The URL is a property of an ASP.NET server control.
The property is marked internally in the control as being a URL. (The property is marked with the attribute .) In practical terms, ASP.NET server control properties that are commonly used to reference external resources are marked in this way.
ASP.NET cannot modify URLs on elements that are not server controls. For example, if you use an img element on a master page and set its src attribute to a URL, ASP.NET will not modify the URL. In that case, the URL will be resolved in the context of the content page and create the URL accordingly.
In general, when working with elements on master pages, it is recommended that you use a server control, even for elements that do not require server code. For example, instead of using an img element, use an server control. That way, ASP.NET can resolve URLs correctly and you can avoid maintenance issues that might arise if you move the master or content page.
For more information about specifying paths for ASP.NET server controls, see ASP.NET Web Site Paths .
Master Pages and ThemesYou cannot directly apply an ASP.NET theme to a master page. If you add a theme attribute to the @ Master directive, the page will raise an error when it runs.
However, themes are applied to master pages under these circumstances:
If a theme is defined in the content page. Master pages are resolved in the context of content pages, so the content page"s theme is applied to the master page as well.
If the site as a whole is configured to use a theme by including a theme definition in the element.
You can attach content pages to a master page at three levels:
At the page level You can use a page directive in each content page to bind it to a master page, as in the following code example.
At the application level By making a setting in the pages element of the application"s configuration file (Web.config), you can specify that all ASP.NET pages (.aspx files) in the application automatically bind to a master page. The element might look like the following.
If you use this strategy, all ASP.NET pages in the application that have controls are merged with the specified master page. (If an ASP.NET page does not contain controls, the master page is not applied.)
At the folder level This strategy is like binding at the application level, except that you make the setting in a Web.config file in one folder only. The master-page bindings then apply to the ASP.NET pages in that folder.
Знакомство с ASP.NET 2.0 Введение
Каждый раз, разрабатывая проект и создавая
Web-приложение, пользуются различными средствами для создания
архитектуры приложения, редактирования кода и публикации результатов
своего труда на Web-сервере. При этом для конечного пользователя
Web-приложение любой сложности остается набором HTML-страниц, каждая из
которых имеет свой уникальный URL. По большом счету, пользователю нет
дела до того на какой платформе или с использованием какой технологии
создано приложение. У пользователя есть цель, которую он хочет достичь и
универсальное средство, практически любой используемый им Web-браузер. В
этом заключено огромное преимущество приложений для Internet по
сравнению с приложениями для настольных систем – существование
общепринятого «языка общения», HTML кода. Для того, чтобы развернуть
Web-приложение достаточно установить его на сервер, после чего
приложение может быть доступно любому клиенту с установленным
Web-браузером. К сожалению, здесь тоже существует очевидная проблема в
обработке HTML кода браузерами разных производителей.
Задача разработчика заключается в том, чтобы создать приложение,
генерирующее HTML код, оптимальный для большинства браузеров, которыми
пользуется конечный пользователь. Каждая технология, используемая для
создания Web-приложения, позволяет генерировать HTML код, поэтому, в
конечном итоге, выбор технологии, на основе которой будет создано
Web-приложение, зависит лишь от удобства и скорости разработки и
простоты развертывания и поддержки конечного продукта.
Преимущество технологии ASP.NET перед остальными в высокой степени
абстракции, построенной над стандартным HTML кодом: использование
объектно-ориентированной парадигмы, поддержку нескольких языков
программирования, наличие универсального основания, содержащего тысячи
уже готовых для использования в проектах решений – Microsoft .NET
Framework.
При этом для разработки приложения может быть использована любая среда
разработки или даже текстовый редактор, позволяющий создавать,
редактировать и сохранять текстовые файлы. Если же разработчик желает
воспользоваться всей мощью Microsoft .NET Framework и ASP.NET и, при
этом, затратить как можно меньше усилий, то ему нужно воспользоваться
подходящей для его задач средой разработки. Одним из наиболее
эффективных средств создания Web-приложений ASP.NET является Microsoft
Visual Studio. Поддержка ASP.NET 2.0 включена в версию Visual Studio
2005.
В данной статье кратко
рассказывается о
большинстве новых возможностей ASP.NET 2.0, новой версии среды ASP.NET.
Далее в тексте считается, что читатель знаком с технологией ASP.NET 1.0
или ASP.NET 1.1. Если рассматриваемая тема выходит за
рамки статьи, то непосредственно в тексте располагается гиперссылка на
статью, содержащую подробную информацию. Также, в конце статьи
приводится список литературы в порядке изложения информации в данной
статье.
Microsoft .NET Framework и Visual Studio 2005
поддерживает несколько языков программирования, таких как Visual Basic,
Visual C#, Visual C++, Visual J#. Поскольку эти языки используют единую
среду выполнения CLR (Common
Language Runtime
) и соответствуют общим стандартам
CLS (Common
Language Specification)
, то сборка, созданная с применением
одного из.NET языков, может быть использована в проекте,
разрабатываемом на другом языке программирования, также, как если бы эта
сборка и приложение были написаны на одном и том же языке.
С выходом Microsoft .NET Framework 2.0
стало возможно использовать в одном и том же проекте разные языки
программирования. То, что Web-приложение ASP.NET может быть написано на
нескольких языках программирования, очень удобно, если уже есть
проверенные решения на одном из языков, а проект пишется с
использованием другого языка, либо, если в команде имеются разработчики,
использующие различные языки программирования. О том, как использовать
разные языки в одном проекте можно прочитать в
этой статье .
Технология разделения кода
Основа всего в Web-приложении – это страница.
Пользователь, пользуясь браузером, перемещается между страницами,
периодически возвращаясь к уже просмотренным ранее страницам, вводя
какие-то данные в HTML формы и получая некоторый результат. В ASP.NET
страница чаще всего представляет собой Web-форму, содержащую различные
элементы управления, реагирующую на события, создаваемые пользователем.
ASP.NET 1.x позволяет разделять код логики от кода представления, то
есть помещать код программной логики страницы в файл.cs или.vb,
отдельно от кода собственно страницы, размещаемом в.aspx файле. Эта
технология называется
Code-Behind . Таким образом, дизайн страницы может быть изменен не
затрагивая кода страницы, что позволяет разделить ответственность за
внешний вид и работу страницы между дизайнером и программистом. Для
этого в.aspx файле можно задать параметры директивы Page.
Но для поддержки редактирования с помощью Microsoft Visual Studio .NET в ASP.NET странице необходимо указать класс, соответствующей данной странице и файл, в котором находится код этого класса. Для этого директива Page преобразуется с использованием ключевых слов Codebenind и Inherits.
В ASP.NET 2.0 используется иной механизм разделения кода. В директиве Page при этом необходимо использовать другие ключевые слова: CodeFile и Inherits.
В этом случае код класса программной логики страницы будет размещен в файле указанном в атрибуте CodeFile. Надо отметить, что Visual Studio 2005 использует разделяемые классы (partial classes).
Public partial class Default: System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { } }
Поэтому разработчик может поместить код класса в
нескольких файлах, но подобное рассредоточение кода делает приложение
весьма громоздким и трудным в поддержке и разработке.
Используемая в Visual Studio 2003 модель Code-Behind обладает
несколькими весьма существенными недостатками. Прежде всего, используя
Visual Studio разработчику необходимо компилировать проект перед
публикацией, поскольку ASP.NET компилирует страницы, только если указан
атрибут Src, не используемый Visual Studio. При этом, поскольку среда
ASP.NET обнаруживает изменение даты создания сборки, после каждой замены
старой сборки в каталоге bin происходит перезапуск домена приложения,
что выливается во временную «заторможенность» в работе приложения.
Visual Studio 2005 использует новые ключевые слова, поддерживаемые
средой выполнения ASP.NET 2.0, а среда выполнения, в свою очередь,
использует новую технику компиляции страниц. Это позволяет решить
проблему замены сборки на более новую.
Несмотря на это, Visual Studio 2005 по-прежнему позволяет отказаться от
разделения кода и поместить код программной логики в самом файле
страницы, и использовать теги . Более
того, по умолчанию Visual Studio создает именно страницы без разделения
кода.
Сравним действия, которые совершает ASP.NET 2.0 и
ASP.NET 1.0, когда пользователь запрашивает файл с расширением.aspx. В
ASP.NET 1.x среда выполнения анализирует директиву Page страницы,
осуществляет поиск соответствующего класса в сборке приложения, затем на
основании кода страницы создается класс, производный от класса
программной логики страницы. В случае если сборка отсутствует, то
осуществляется поиск файла программной логики, указанного в атрибуте Src
директивы Page. Если файл найден, то происходит компиляция сборки, если
нет, то ASP.NET выбрасывает исключение.
В ASP.NET 2.0 среда выполнения также анализирует директивы Page,
осуществляет поиск сборки соответствующей классу логики страницы, после
чего создается класс страницы. В отличие от ASP.NET 1.x, родительским
классом для класса страницы является System.Web.UI.Page, поскольку
создаваемый динамический класс является собственно классом страницы
(используются разделяемые классы для класса страницы и класса
программной логики), а не потомком класса программной логики. Поэтому,
если в ASP.NET 1.x класс Web-формы мог называться также как и сама
Web-форма.
… public class frmDefault: System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { } }
В ASP.NET 2.0 это недопустимо, поскольку элемент
управления System.Web.UI.Form является элементом класса.
Основным преимуществом ASP.NET является то, что в случае отсутствия
сборки, необходимой для выполнения страницы, происходит компиляция
только файла программной логики страницы, без перекомпиляции всей
сборки. Поскольку существует динамическая компиляция, то необходимо
обеспечить возможность создавать код, общий для всех страниц приложения.
Для этой цели в ASP.NET 2.0 существуют специальные директории,
являющиеся дочерними директориями корневой директории приложения, одна
из которых App_Code, служит для хранения файлов, содержащих общий код
для всех страниц. При выполнении динамической компиляции, код из
директории App_Code компилируется и становится доступным для всех
страниц Web-приложения. При этом
Visual Studio
2005 поддерживает код, находящийся в директории
App_Code, поэтому работает подсветка синтаксиса и
IntelliSense.
Исследовать генерируемые средой выполнения
ASP.NET 2.0 файлы, и подробно разобраться в процессе компиляции можно
изучив содержимое директории:
%WINDIT%\Microsoft.NET\Framework\версия\Temporary ASP.NET
Files\имя_приложения, куда
ASP.NET 2.0
помещает динамически созданные сборки.
Либо, вызвав ошибку на
ASP.NET
странице
в режиме отладки выбрать ссылку
Show Complete Compilation Source.
Если же необходимо заренее скомпилировать проект, перед развертыванием на сервере в ASP.NET 2.0 существует возможность полной или частичной прекомпиляции Web-приложения. Подробнее о прекомпиляции можно прочесть в этой статье .
Изменения в структуре проекта Visual StudioВ версии Visual Studio 2005 больше нет файлов.csproj или.vbproj, которые раньше создавались для каждого из типов проектов ASP.NET. Вместо файлов проекта Visual Studio использует структуру директорий, таким образом, для того чтобы включить в проект существующий файл достаточно просто скопировать его в директорию проекта. Следует отметить, что если файл или директория удаляется из дерева файлов проекта в окне Solution Explorer, то файл или директория физически удаляются из файловой системы.
Страница ASP.NET 2.0 Директива @PageДля внесения новых возможностей в ASP.NET 2.0 было необходимо внести изменения и дополнения в класс страницы Page. Поскольку для установке свойств страницы в design-time используются атрибуты директивы Page, то здесь будут рассмотрены новые атрибуты, появившиеся для реализации механизмов персонализации, шаблонов дизайна, оформления и асинхронной работы станиц. Подробнее о назначении новых атрибутов можно узнать в части статьи, посвященной новым свойствам и методам класса Page.
Async
Указывает на то, какой из интерфейсов IHttpHandler или IHttpAsyncHandler реализует класс страницы. После установки этого атрибута в true, генерируемый динамически класс страницы будет реализовать от IHttpAsyncHandler, в противном случае класс будет реализовать IHttpHandler. Если класс страницы реализует IHttpAsyncHandler, то код страницы может выполнятся асинхронно до наступления нового события в жизненном цикле страницы PreRender, ко времени наступления которого происходит синхронизация и подготовка HTML-кода для отправки браузеру клиента.
AsyncTimeOut
Позволяет установить ограничение по времени, отведенное для выполнения асинхронных операций. По умолчанию этот параметр равен 45 секундам.
Culture
Устанавливает набор региональных параметров (Culture) , используемый для страницы.
EnableTheming
Позволяет включить или выключить поддержку тем оформления. По умолчанию включено.
MasterPageFile
Указывает путь к шаблону, который будет использован для создания кода этой страницы.
StyleSheetTheme
Позволяет установить идентификатор темы оформления, которая будет использоваться для изменения установленной темы оформления (в атрибуте Theme или в файле web.confg). Таким образом можно установить общую тему оформления для всего сайта, а с помощью атрибута StyleSheetTheme вносить некоторые изменения в общее оформление страницы и /или некоторых элементов управления, содержащихся на странице.
Theme
Указывает название темы оформления, которая будет использована для оформления кода данной страницы.
UI Culture
Устанавливает набор региональных параметров (Culture) , используемый для пользовательского интерфейса страницы.
Жизненный цикл страницыЖизненный цикл страницы ASP.NET начинается с
получения и обработки Web-сервером IIS запроса к данной странице и
передачи этого запроса среде выполнения ASP.NET. В момент получения
запроса, среда выполнения загружает
класс
вызываемой
страницы, устанавливает свойства
класса страницы, выстраивает дерево элементов, заполняет свойства
Request и
Response и вызывает метод
IHttpHandler.ProcessRequest.После этого среда
выполнения проверяет каким образом была вызвана эта страницы
и если
страница вызвана путем передачи данных с
другой страницы, о чем будет рассказано далее, то среда выполнения
устанавливает свойство
PreviousPage.
Стоит отметить также, что помимо рассмотренных ниже этапов
выполнения страницы существуют еще и этапы уровня приложения, не
специфичные для страницы. Подробно об этапах выполнения приложения
написано в
этой
статье .
| Запрос станицы | Запрос страницы осуществляетс ядо начала жизненноцо цикла страницы. Когда пользователь осуществляет запрос, среда выполнения ASP.NET устанавливает, необходимо ли осуществить компиляцию страницы и начать жизненный цикл, либо можно выдать в качестве ответа страницу из кеша, таким образом не выполняя страницы. |
| Начало жизненного цикла | На этом этапе происходит установка свойство Response и Request и свойства UICulture. Также, на этом этапе устанавливается, была ли эта страница запрошена в результате постбэка (отправления данных на сервер) и соответствующим образом устанавливается свойсто IsPostBack. |
| Инициализация страницы | Ко времени инициализации страницы все дочерние пользовательские элементы управления уже созданы и имеют установленный свойства UniqueID. В это же время к странице применяются темы оформления. Если страница вызвна в результате постбэка, то данные, отправленные на сервер, еще не загружены в свойства элементов управления, на этом этапе. | Если страница вызвана в результате постбэка, то на этом этапе устанавливаются свойства элементов управления, на основании информации о состоянии (ViewState и ControlState). |
| Валидация | Вызывается метод Validate() для всех, находящихся на странице валидаторов. |
| Обработка постбэка | Вызываются обработчики событий (при условии, что постбэк произошел). |
| Рендеринг | Сохраняется информация о состоянии, затем класс страницы вызывает соответствующие методы дочерних элементов управления для генерации HTML представления и передачи его в Response.OutputStream. |
| Выгрузка | Выгрузка происходит после того, как создано HTML представление для всей страницы. |
Во время прохождения этапов
жизненного цикла возникают события, подписавшись на которые, разработчик
может выполнять свой собственный код. Стоит упомянуть атрибут
AutoEventWireup, директивы
@Page:
если этот атрибут установлен в
true (значение по
умолчанию), то методы класса страницы, названные
Page_НазваниеСобытия,
автоматически становятся обработчиками соответствующих событий
жизненного цикла станицы.
Для того, чтобы проследить жизненный цикл страницы и
последовательность возникновения событий, можно установить атрибут
Trace директивы
@Page в
true, а атрибут
TraceMode
в
"SortByTime". Тогда в разделе
Trace
Information можно найти список произошедших событий
(колонка
Message). Например:
| aspx.page | Begin PreInit | ||
| aspx.page | End PreInit | 0.0364973314167865 | 0.036497 |
| aspx.page | Begin Init | 0.0379050459346291 | 0.001408 |
| aspx.page | End Init | 0.047693704143491 | 0.009789 |
| aspx.page | Begin InitComplete | 0.0477864508468221 | 0.000093 |
| aspx.page | End InitComplete | 0.0481875670270608 | 0.000401 |
| aspx.page | Begin PreLoad | 0.0489879732516718 | 0.000800 |
| aspx.page | End PreLoad | 0.0494462283607275 | 0.000458 |
| aspx.page | Begin Load | 0.0494924892194238 | 0.000046 |
| aspx.page | End Load | 0.0553441897381414 | 0.005852 |
| aspx.page | Begin LoadComplete | 0.0554711043059809 | 0.000127 |
| aspx.page | End LoadComplete | 0.055942153615399 | 0.000471 |
| aspx.page | Begin PreRender | 0.0561455634022874 | 0.000203 |
| aspx.page | End PreRender | 0.0618604874695332 | 0.005715 |
| aspx.page | Begin PreRenderComplete | 0.06269871008062 | 0.000838 |
| aspx.page | End PreRenderComplete | 0.0633259746265858 | 0.000627 |
| aspx.page | Begin SaveState | 0.080360541216174 | 0.017035 |
| aspx.page | End SaveState | 0.213795377788888 | 0.133435 |
| aspx.page | Begin SaveStateComplete | 0.213911298043872 | 0.000116 |
| aspx.page | End SaveStateComplete | 0.214385763389788 | 0.000474 |
| aspx.page | Begin Render | 0.214440078745078 | 0.000054 |
| aspx.page | End Render | 0.315044337228923 | 0.100604 |
Из всех событий жизненного цикла страницы, разработчик может
подписаться только на пять, помимо событий дочерних элементов
управления. Эти события:
PreInit, Init, Load, PreRender, Unload.
Рассмотрим варианты использования этих событий.
| PreInit |
Во время этого события можно использовать свойство IsPostBack, для того, чтобы определить вызвана ли эта страница в первый раз или в результате постбэка. В плане управления страницей разработчик может: создавать динамически элементы управления, динамически устанавливать шаблон дизайна или тему оформления, считывать или устанавливать свойства объекта Profile. Стоит особо отметить, что на данном этапе, если страница была вызвана в результате постбэка, свойства элементов управления еще не установлены. В случае, если разработчик самостоятельно установит свойства на этом этапе, на следующем установленный значения могут быть изменены. |
| Init | На этом этапе разработчик может считывать или инициализировать свойства элементов управления. |
| Load | На этом этапе разработчик может считывать или изменять свойства элементов управления. |
| PreRender | Последняя возможность внести изменения во внешний вид страницы. |
| Unload | Освобождение занятых ресурсов (закрытие
открытых соединений с базой данных, завершение работы с файлами
и т.п.)
Важно, что на этом этапе уже создано HTML представление страницы и попытка внести какие-либо изменения (например, вызвав метод Response.Write()), приведет к исключению. |
Для управления приведенными в предыдущем разделе событиями и получении информации о результатах их выполнения, у объекта Page в ASP.NET 2.0 появились следующие новые методы и свойства. Подробная информация по перечисленным ниже объектам и свойствам, а также их использовании последует далее в следующем разделе этой статьи.
EnableTheming
Свойство, позволяющее отключить поддержку тем оформления на странице, если применение темы нежелательно.
GetValidators
Метод, возвращающий коллекцию валидаторов данной страницы.
Header
Ссылка на объект HtmlHead, позволяющий контролировать содержимое раздела HTML страницы, при условии, что для элемента head установлен атрибут runat="server".
IsAsync
Свойство, указывающее на способ обработки страницы – синхронный или асинхронный.
IsCrossPagePostBack
Свойство, позволяющее определить была ли данная страница запрошена в ответ на отправку данных с другой страницы.
MasterPageFile
Свойство, содержащее имя файла шаблона страницы.
MaxPageStateFieldLength
Устанавливает максимальный размер одного поля, хранящего состояние, в байтах. Если этому свойству присвоено число, меньшее, чем размер информации о состоянии, которую необходимо сохранить, то будет создано несколько скрытых полей, объем данных в каждом не будет превышать значения MaxPageStateFieldLength.
PageAdapter
Свойство возвращает объект PageAdapter, управляющий генерацией HTML представления страницы. Конкретный PageAdapter устанавливается средой выполнения в зависимости от параметров Requets. Если выбран PageAdapter, то события жизненного цикла страницы замещаются событиями PaeAdapter.
SetFocus
Метод, позволяющий установить выделение на какой-либо из видимых на
странице элементов управления.
StyleSheetTheme, Theme
Смотрите выше описание новых атрибутов директивы @Page.
TestDeviceFilter
Метод, проверяющий является ли текущий браузер браузером указанного в качестве аргумента типа.
Title
Свойство, позволяющее получить и изменить заголовок страницы.
Использование новых объектов страницы ASP.NET 2.0 Объект ClientScriptManagerClientScriptManager предоставляющий методы для работы скодом сценариев, которые будут использоваться в клиентской части Web-приложения. Теперь все методы, которые в ASP.NET 1.x использовались для регистрации клиентских скриптов или скрытых полей принадлежат классу ClientScriptManager. Например, иногда бывает необходимо регистрировать клиентский сценарий динамически, в зависимости от каких-либо параметров. Например, при перезагрузке страницы форума нужно указать пользователю, что ему пришло новое личное сообщение. Это можно сделать как показано в нижеследующем примере.
Protected void Page_Load(object sender, EventArgs e) { if (CheckMail()) { string startupScript = "" + "if(confirm("Вам пришло новое сообщение. Прочесть?"))" + "window.navigate("/ReadMail.aspx");" + ""; ClientScript.RegisterStartupScript(this.GetType(), "MailAlertScript", startupScript); } }
Объект HtmlHeadДля каждой страницы ASP.NET, в HTML коде которой
присутствует тег автоматически создается
экземпляр объекта HtmlHead, позволяющий управлять заголовком страницы,
добавлять теги META и ссылки на каскадные таблицы стилей.
Раньше разработчику страницы ASP.NET 1.0 приходилось добавлять
специальное свойство или переменную в класс страницы или придумывать
какой-либо обходной путь для того, чтобы получить возможность управлять
заголовком и метаданными страницы. Например, так как это показано в
следующем примере.
С появлением объекта HtmlHead подобные ухищрения уходят в прошлое.
Page.Header.Title = "HtmlHead Test Page"; Page.Header.Metadata.Add("Author", "Gaidar Magdanurov"); Page.Header.Metadata.Add("E-Mail", "[email protected]");
Помимо этого, как и любой элемент, способный содержать вложенные элементы, HtmlHead позволяет добавлять произвольные элементы.
((Control)Page.Header).Controls.Add(new LiteralControl (""));
Управление страницей Установка выделения на элемент управленияИногда бывает необходимо, чтобы после загрузки страницы выделение было установлено на какой-то определенный элемент управления (например в поисковой форме логично установить фокус ввода на основное поле поиска), для этого можно задать значение атрибута defaultfocus тега form.
Выделением можно управлять программно, вызывая метод SetFocus, в качестве параметра передавая уникальный идентификатор этого элемента:
Protected void Page_Load(object sender, EventArgs e) { if(isPostBack) { SetFocus("txtLastName"); } else { SetFocus("txtFirstText"); } }
Обновление данных без перезагрузки страницы
В ASP.NET 2.0 стало возможным обновлять данные на
странице без отправки страницы на сервер и ее полного обновления. Это
стало возможно благодаря появлению клиентских сценариев с обратным
вызовом (callback scripts или клиентские коллбэки). После того, как
некоторое событие вызывает запрос к серверу, обновленные данные
передаются непосредственно в клиентский сценарий в качестве аргументов
функции.
Подобный способ обновления данных на странице удобно и выгодно
применять, когда для обновления всей информации требуется много ресурсов
и достаточно длительное время, при этом эти часть данных обновляется
часто, а остальные данные статичны. Тогда время на обновления данных,
например, одного пользовательского элемента, учитывая время запроса к
серверу, обработки и получения ответа, будет существенно ниже, чем время
обновления всей страницы.
Допустим, существует страница, на которой находится выпадающий
список. Когда пользователь выбирает некоторое значение из списка, в
некоторый элемент управления загружается значение, логически связанное с
выбранным из списка значением. При этом задача такова, что нельзя
хранить все данные на стороне клиента (возможно данных слишком много и
страница будет долго передаваться по сети, либо данные генерируются на
сервере не только в зависимости от выбранного пользователем элемента
выпадающего списка). В ASP.NET 1.x
для решения
этой задачи необходимо привязать к событию изменения значения в
выпадающем списке серверный метод. При этом список должен вызывать
отправку страницы на сервер при каждом изменении значения
(AutoPostBack="True").
Protected void ddStatic_SelectedIndexChanged(object sender, EventArgs e) { // На основании значения ddStatic.Items.Value // метод устанавливает свойства дригих элементов управления }
В ASP.NET 2.0, как уже было сказано выше, существует
возможность не обновлять всю страницу целиком. В данном случае разумно
обновить только необходимые данные, поскольку обновлять всю страницу
только для того, чтобы установить одно значение слишком расточительно.
Для реализации механизма обновления данных без перезагрузки страницы
необходимо создать клиентскую функцию обратного вызова, принимающую
переданные с сервера параметры, серверную функцию, принимающую параметры
от клиента и возвращающую клиенту значения на основании полученных
параметров и связать эти две функции. Мало того, механизм обратного
вызова в ASP.NET 2.0 позволяет возвращать результат асинхронно. Для
этого в интерфейсе ICallbackEventHandler определены два метода:
RaiseCallbackEvent, для получения параметров на сервере и
GetCallbackResult для возвращения результата клиенту. Для реализации
функциональности предыдущего примера в ASPX файле помещается следующий
код.
function UpdateText(result, context)
{
dSpan.innerText = result;
}
Класс страницы, использующей функции с обратным вызовом должен реализовывать интерфейс ICallbackEventHandler.
Public partial class ScriptCallback_aspx: System.Web.UI.Page, System.Web.UI.ICallbackEventHandler { }
Сигнатуры функций, поддерживающие обратный вызов выглядят следующим образом:
Public virtual void PrepareCallbackEvent(string Аргументы) public virtual string RenderCallbackResult() private string EventArgument = ""; public void PrepareCallbackEvent(string eventArgument) { EventArgument = eventArgument; } public string RenderCallbackResult() { return EventArgument; // значение типа string }
Последним шагом к поставленной цели является связывание серверной и клиентских функций.
Protected void Page_Load(object sender, EventArgs e) { // создаем ссылку на функцию обратного вызова string callbackFunction = Page.ClientScript.GetCallbackEventReference (this, "document.all["ddDynamic"].value", "UpdateText", "null"); // Привязываем сценарий к событию изменения значения выпадающего // списка ddDynamic.Attributes["onchange"] = String.Format("javascript:{0}", callbackFunction); }
Метод GetCallbackEventReference объекта
ClientScriptManager принимает в качестве параметров ссылку на объект
страницы, строку, указывающую на значение, которое необходимо передавать
на сервер при обратном вызове, имя метода на стороне клиента и
принимающего ответ сервера. Подробное описание можно получить в
документации MSDN или с помощью инструмента Visual Studio - Object
Browser.
Используя эту технологию можно создавать сложные методы обновления
данных страницы и позволяющие получить значительный выигрыш в
производительности, для этого достаточно разобраться в том, какой код
генерирует среда выполнения ASP.NET, реализуя эту функциональность.
// Список, вызывающий перезагрузку страницы // Список вызывающий метод с обратным вызовом
Стандартная функция doPostBack весьма проста и служит для сохранения данных о событии в скрытые поля формы.
Var theForm = document.forms["frmCallBack"]; function __doPostBack(eventTarget, eventArgument) { if (theForm.onsubmit == null || theForm.onsubmit()) { theForm.__EVENTTARGET.value = eventTarget; theForm.__EVENTARGUMENT.value = eventArgument; theForm.submit(); } }
При использовании функций с обратным вызовом механизм
значительно сложнее. Код функции WebForm_DoCallback гораздо больше, чем
doPostBack, поскольку эта функция определяет тип объектной модели
браузера, после чего загружает необходимый для передачи данных с модуль.
Например, для браузера поддерживающего DOM это будет Microsoft.XMLHTTP.
Посмотреть код различных клиентских функций, используемых средой
ASP.NET 2.0 можно сохранив страницу, поддерживающую функции с обратным
вызовом на жесткий диск и открыв в текстовом редакторе файл
WebResource.axd, ссылка на который имеется в HTML странице.
Более подробное описание возможностей и
области применения клиентских функций обратного вызова описано в
статье Дино Эспозито .
Существенное ограничением серверных форм в ASP.NET
1.0 – отсутствие возможности непосредственно передавать данные,
введенные в форме, другой странице. Чтобы отправить значения элементов
форму другой странице необходимо использовать простою HTML форму и в
атрибуте action указать путь к странице, которая должна получить данные.
При этом теряются преимущества использования серверных форм.
В ASP.NET 2.0 тег элемента управления может иметь дополнительный
атрибут PostBackUrl, позволяющий указать какой странице система должна
передать Web-форму, если отправление данных на сервер инициировано этим
элементом управления.
После щелчка по кнопке, браузер пользователя будет
переадресован на страницу crosspost.aspx, при этом вся информация об
элементах управления формы, с которой произошло отправление данных,
будет также передано.
Чтобы реализовать эту возможность, среда ASP.NET 2.0 осуществляет
проверку ASPX страниц на предмет наличия элементов управления с заданным
атрибутом PostBackUrl и, при наличии таковых, создает на странице
дополнительное скрытое поле __PREVIOUSPAGE, которое и содержит
информацию о состоянии элементов формы. Эта информация доступна
странице-получателю через свойство PreviousPage.
Void Page_Load(object sender, EventArgs e) { if (PreviousPage != null) { // Получаем объекты отправленной формы TextBox txtFirstName = (TextBox)PreviousPage.FindControl("txtFirstName"); TextBox txtLastName = (TextBox)PreviousPage.FindControl("txtLastName"); // Используем данные txtInfo.Text = "Добрый день, " + txtFirstName.Text + "!"; } }
На уровне HTML кода, отправка данных другой форме выглядит следующим образом.
Из чего можно заключить, что данные формы не направляются из браузера непосредственно странице CrossPage.aspx, а предварительно направляются все той же странице GetValues.aspx, которая содержит форму frmTest. Это необходимо для поддержки серверной проверки (validation) введенных данных с использованием элементов управления RequiredFieldValidation, RangeValidation и других. Ознакомиться с методом WebForm_DoPostBackWithOptions можно в файле WebResource.axd, упомянутом в предыдущем параграфе этой статьи.
Шаблоны дизайна страницЧто, прежде всего, отличает один Web-сайт от другого?
Для простого пользователя сети Интернет основное отличие заключается в
разнообразном дизайне странице. Прежде чем встретится с функциональными
возможностями Web-приложения, посетитель сайта оценивает, нравится ли
ему внешний вид страниц. Поэтому дизайн страниц является едва ли менее
важным, чем общая функциональность.
Задача разработчика писать код, а задача художника-дизайнера
заниматься внешним оформлением и версткой HTML кода страниц. При этом в
большинстве случаев необходимо обеспечить возможность параллельной
работы над кодом приложения и HTML шаблоном. С этим весьма успешно
справлялась технология разделения кода программной логики и HTML кода
страницы Code-Behind. Но, при этом, при работе над каждой страницей,
разработчику приходится, так или иначе, сталкиваться с разметкой
страницы.
Стоит заметить, что большинство современных Web-сайтов имеют сходный
внешний вид всех страниц и каждая страница имеет общие элементы дизайна.
В ASP.NET 1.x
общие элементы дизайна страниц
заключали в пользовательские элементы управления и включались в каждую
страницу, либо, наоборот, страницы преобразовывали в элементы
управления, используя одну страницу в качестве основы в которую
загружали элементы управления в зависимости от строки URL.
Подход в ASP.NET 2.0 близок ко второму из названных подходов, но
заключает в себе существенные преимущества. Разработчику больше нет
нужды преобразовывать страницы в пользовательские элементы управления,
что существенно упрощает разработку и отладку. А также существенно
упрощает работу дизайнера, поскольку его задача сводится лишь во
включении нескольких ASP.NET элементов в код страницы-шаблона. Для более
подробного сравнения технологии шаблонов ASP.NET 2.0
с существующими ранее техниками использования шаблонов
рекомендуется обратится к
статье Фрица Оньена .
Шаблон дизайна страниц (Master pages) представляет
собой обычную ASP.NET страницу, обладающую несколькими дополнительными
атрибутами и свойствами и содержащую один или несколько специальных
элементов управления ContentPlaceHolder. Для того чтобы преобразовать
обычную страницу в шаблон, достаточно заменить директиву Page на
директиву Master.
После этого необходимо вставить в разметку страницы серверные элементы
управления ContentPlaceHolder, в те части страницы, где будет
размещаться информация, не относящаяся к общему дизайну.
Моя домашняя страница
Время:
Также как и для обычной страницы, в файле программной
логики можно работать с имеющимися элементами управления, создавать и
добавлять новые, основываясь на параметрах запроса изменять страницу и
ее поведение. Таким образом, можно вынести логику создания внешнего
облика Web-приложения практически полностью в шаблон страницы.
Элемент управления ContentPlaceHolder позволяет определить
содержимое, которое будет использоваться в случае, если страница,
использующая шаблон, не переопределит содержимое элемента управления.
- Главная страница
- Оглавление
Работа с элементами управления страницы шаблона ничем не отличается от работы с элементами управления для обычной страницы. Таким же образом можно определить методы и свойства, которые будут доступны всем страницам использующим данный шаблон.
Protected void Page_Load(object sender, EventArgs e) { PageTime.InnerText = DateTime.Now.ToShortDateString(); } public string Title { get { return PageTitle.InnerText; } set { PageTitle.InnerText = value; } }
Создание страницыИспользование шаблонов дизайна налагает свои требования на страницы. Поскольку шаблон содержит элементы управления ContentPlaceHolder, то страница должна содержать элементы управления Content, содержащие код разметки и другие элементы управления, которые будут отображать на результирующей странице. На странице не должно быть каких-либо серверных элементов управления или кода разметки вне элементов управления Content.
- Страница 1
- Страница 2
- Страница 3
Также как и в случае с шаблоном, код логики страницы создается обычным образом. Единственное отличие в том, что страница не имеет собственных объектов вроде HeadControl, поэтому нужно использовать ссылку на страницу шаблона через свойство Master.
Protected void Page_Load(object sender, EventArgs e) { if (!Page.IsPostBack) Master.Page.Header.Title = "Домашняя страница"; } protected void btnShow_Click(object sender, EventArgs e) { PlaceHolder.Controls.Add(new LiteralControl(" alert("Добрый день, " + txtName.Text + ""); ")); Master.Page.Header.Title = "Добрый день, " + txtName.Text; }
Для того чтобы привязать страницу к шаблону используется атрибут MasterPageFile директивы Page. Если же необходимо привязать один и тот же шаблон ко всем страницам в директории, то нет необходимости указывать атрибут MasterPageFile для каждой страницы, достаточно задать базовый шаблон в файле web.config.
Кроме того, ASP.NET позволяет устанавливать тему оформления программным образом. Как было сказано выше, загрузка и связывание с шаблоном оформления происходит во время подготовки страницы к инициализации. Поэтому, если необходимо сменить шаблон оформления страницы, необходимо делать это в обработчике события PreInit.
Protected void Page_PreInit(object sender, EventArgs e) { Page.MasterPageFile = "AnotherMaster.master"; }
Обработка шаблонов средой ASP.NETВо время первого обращения к какой-либо странице,
ASP.NET осуществляет поиск и компиляцию сборок для всех шаблонов в
директории. Эта операция занимает некоторое время, зависящее от
количества страниц шаблонов в директории, но выполняется только один
раз. Поэтому, если в директории присутствуют не использующиеся шаблоны,
это не приводит к потерям производительности в процессе работы
приложения, единственное неудобство – дополнительное время, а компиляцию
ненужных сборок для неиспользуемых страниц.
При обращении к aspx файлу страницы с заданным шаблоном оформления
процесс компиляции почти ничем не отличается от обычного процесса
компиляции страницы, за исключением того, что создается класс шаблона
MasterPage ссылка на который доступна в свойстве Page.Master.
Затем страница проходит все те шаги, которые описаны выше в этой
статье, в результате чего генерируется HTML код, который отправляется
клиенту. В полученном браузером HTML коде уже нельзя определить, какая
часть кода задана в шаблоне оформления, а какая часть кода определена на
самой странице, поскольку элементы управления ContentPlaceHolder и
Content не имеют каких-либо HTML соответствий и не порождают
дополнительных тегов, кроме своего содержимого.
Домашняя страница
|
|
Время: 20.03.2005
Поскольку шаблон является подмножеством страницы, то допустимо создавать вложенные шаблоны, указывая для шаблона в директиве Master путь к другому шаблону с помощью атрибута MasterPageFile. Для этого необходимо в основном шаблоне определить элементы управления ContentPlaceHolder, а в «дочерних» шаблонах на ряду с ContentPlaceHolder элементами определить элементы управления Content для замещения содержимого элементов ContentPlaceHolder базового шаблона.
Использование разных шаблонов для разных браузеровЛюбому Web-разработчику хорошо известно, что разные
браузеры (например, Microsoft Internet Explorer, Netscape Navigator,
Mozilla FireFox и др.) по разному обрабатывают HTML код и, что особенно
важно, обладают несколько разными программируемыми моделями, что
усложняет создание клиентских сценариев.
Для разрешения этой проблемы существует два
основных метода, которые используются и в ASP.NET 1.x и в классическом
ASP. Первый заключается в том, что браузеру клиента отправляется
клиентский код, который, основываясь на типе и версии браузера,
выполняет некоторые действия. Второй состоит в перенаправлении браузера
пользователя на те страницы, которые специально оптимизированы под
конкретный браузер. ASP.NET упрощает создание подобных страниц,
поскольку среда выполнения генерирует HTML код для стандартных серверных
элементов управления основываясь на информации о браузере клиента. При
использовании шаблонов оформления, можно создать несколько шаблонов, для
каждого браузера и в директиве Page страницы указать, какой шаблон
использовать.
Список браузеров и используемые средой ASP.NET
свойства браузеров можно найти в директории
%WINDIT%\Microsoft.NET\Framework\версия\CONFIG\Browsers.
Для локализации приложений в ASP.NET 1.x разработчику часто приходилось писать код для определения региональных настроек пользователя. Этот код часто помещался в global.asax и его задачей стояла установка языка пользователя в качестве языка текущего процесса, путем создания объекта CultureInfo и присвоения его свойствам CurrentCulture и CurrentUICulture объекта CurrentThread :
Void Application_BeginRequest (Object sender, EventArgs e) { if (Request.UserLanguages.Length > 0) { CultureInfo UserCulture = CultureInfo.CreateSpecificCulture(Request.UserLanguages); Thread.CurrentThread.CurrentCulture = UserCulture; Thread.CurrentThread.CurrentUICulture = UserCulture; } }
В ASP.NET 2.0 существует возможность переложить определение региональных настроек пользователя на среду выполнения. Достаточно установить атрибуты Culture="auto" и UICulture="auto" директивы @Page , чтобы для страницы региональные настройки пользователя определялись автоматически. В случае. если необходимо достичь этого эффекта на всех страницах сайта, достаточно в файл web.config добавить следующую строку:
Выражения для локализации
ASP.NET 2.0 позволяет генерировать сборки с локальными ресурсами для каждой страницы и связывать элементы управления с данными, хранимыми в этих ресурсах с помощью выражений, размещаемых непосредственно в коде представления в ASPX файле. Для этого используется атрибут meta:resourcekey, значение которого анализируется во время выполнения страницы.
Select Language
Либо может быть использовано новое выражение :
Для того, чтобы таким же образом можно было локализовать статический текст, в ASP.NET 2.0 появился новый элемент управления Localize, позволяющий использовать указанные выше выражения локализации.
Text
Text
Подробнее и выражениях, генерации ресурсов и определении региональных настроек пользователя можно прочесть в этой статье .
ЗаключениеВ этой статье приведены лишь некоторые основные сведения о новшествах в технологии ASP.NET 2.0 по сравнению с ASP.NET 1.x . Особенности ASP.NET были очень описаны кратко и данная статья может служить отправной точной для изучению этой передовой технологии. Для более подробного описания упомянутых в статье технологий и новых возможностей, рекомендуется обратиться к списку дополнительной литературы. В статье не был затронут ряд важных нововведений - асинхронное выполнение кода, новые элементы управления, шифрование фрагментов файла web.config , новые механизмы доступа к данным и многое-многое другое. Все это является материалом, которому можно посвятить не одну книгу. По возможности автор постарается осветить эти нововведения в будущих статьях.
Наверно редкое собеседование по ASP.NET не обходится без вопроса о жизненном цикле страницы в ASP.NET Web Forms (далее для краткости ASP.NET). Попытаемся разобраться в этом вопросе. Разделил тему на две. В текущей статье разберем этапы жизненного цикла страницы в ASP.NET .
Общий план Жизненный цикл страницы ASP.NET- получение и обработка web-сервером IIS запроса к странице
- дальнейшая передача запроса среде выполнения ASP.NET
среда выполнения:
* загружает класс вызываемой страницы * устанавливает свойства класса страницы * выстраивает дерево элементов * заполняет свойства Request и Response * вызывает метод ```IHttpHandler.ProcessRequest```
Выделяется 8 основных этапов. Наглядно это демонстрирует следующая схема
| Запрос станицы | Запрос страницы осуществляется до начала жизненного цикла страницы. Пользователь осуществляет запрос, среда выполнения ASP.NET устанавливает, необходимо ли осуществить компиляцию страницы и начать жизненный цикл, либо можно выдать в качестве ответа страницу из кеша, не выполняя страницы. |
| Начало обработки | На этом этапе происходит установка свойство Response и Request и свойства UICulture . Также, на этом этапе устанавливается, была ли эта страница запрошена в результате postback и соответствующим образом устанавливается свойство IsPostBack . |
| Инициализация страницы | Ко времени инициализации страницы все дочерние пользовательские элементы управления уже созданы и имеют установленный свойства UniqueID . В это время к странице применяются темы оформления. Если страница вызвана в результате postback, то данные, отправленные на сервер, еще не загружены в свойства элементов управления, на этом этапе. | Если страница вызвана в результате postback, то на этом этапе устанавливаются свойства элементов управления, на основании информации о состоянии (ViewState и ControlState). |
| Валидация | Вызывается метод Validate() для всех, находящихся на странице валидаторов. |
| Обработка постбэка | Вызываются обработчики событий если postback произошел. |
| Рендеринг | Сохраняется информация о состоянии, затем класс страницы вызывает соответствующие методы дочерних элементов управления для генерации HTML представления и передачи его в Response.OutputStream. |
| Выгрузка | Выгрузка происходит после того, как создано HTML представление для всей страницы. |