Наверно редкое собеседование по 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 представление для всей страницы. |
Знакомство с 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 дают первоначальное знакомство с солидной технологией создания веб-приложений. Не усложняя первые шаги фреймворками 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.
Последнее обновление: 31.10.2015
Мастер-страницы используются для создания единообразного, унифицированного вида сайта. По сути мастер-страницы - это те же самые представления, но позволяющие включать в себя другие представления. Например, можно определить на мастер-странице общие для всех остальных представлений элементы, а также подключить общие стили и скрипты. В итог нам не придется на каждом отдельном представлении прописывать путь к файлам стилей, а потом при необходимости его изменять. А используемые на мастер-страницах заполнители или плейсхолдеры позволят вставить на их место другие представления.
По умолчанию при создании нового проекта ASP.NET MVC 5 в проект уже добавляется мастер-страница под названием _Layout.chtml , которую можно найти в каталоге Views/Shared . В приложении из второй главы мы ее изменили следующим образом:
@ViewBag.Title @RenderBody()
На первый взгляд это обычное представление за одним исключением: здесь используется метод @RenderBody() , который является заместителем и на место которого потом будут подставляться другие представления, использующие данную мастер-страницу. В итоге мы сможем легко установить для представлений веб-приложения единообразный стиль.
Чтобы в представлении использовать мастер-страницу, нам надо в секции Layout указать путь к нужной мастер-странице. Например, в представлении Index.cshtml можно определить мастер-страницу так:
Если мы не используем мастер-страницу, то указываем Layout = null; .
Также необязательно для всех представлений использовать одну и ту же мастер-страницу. Можно определить несколько мастер-страниц, например, одну для форума, одну для блога и т.д., и в зависимости от раздела сайта подключать нужную. Добавляются в проект они также как и обычные представления.
Мастер-страница может иметь несколько секций, куда представления могут поместить свое содержимое. Например, добавим к мастер-странице секцию footer:
@ViewBag.Title
@RenderBody() @RenderSection("Footer")Теперь при запуске предыдущего представления Index мы получим ошибку, так как секция Footer не определена. По умолчанию представление должно передавать содержание для каждой секции мастер-страницы. Поэтому добавим вниз представления Index секцию footer. Это мы можем сделать с помощью выражения @section:
@{ Layout = "~/Views/Shared/_Layout.cshtml"; } @section Footer { Все права защищены. Syte Corp. 2012. }
Но при таком подходе, если у нас есть куча представлений, и мы вдруг захотели определить новую секцию на мастер-странице, нам придется изменить все имеющиеся представления, что не очень удобно. В этом случае мы можем воспользоваться одним из вариантов гибкой настройки секций.
Первый вариант заключается в использовании перегруженной версии метода RenderSection , которая позволяет указать, что данную секцию не обязательно определять в представлении. Чтобы отметить секцию Footer в качестве необязательной, надо передать в метод в качестве второго параметра значение false:
@RenderSection("Footer", false)
Второй вариант позволяет задать содержание секции по умолчанию, если данная секция не определена в представлении:
@if (IsSectionDefined("Footer")) { @RenderSection("Footer") } else { Содержание элемента footer по умолчанию. }
ViewStartЕсли у нас в проекте пара-тройка представлений, мы легко можем изменить вручную для каждого описание мастер-страницы в секции Layout, если, например, мы решим использовать другую мастер-страницу. Но если у нас много представлений, то это делать будет не очень удобно.
Для более гибкой настройки представлений предназначена страница _ViewStart.cshtml . Код этой страницы выполняется до кода любого из представлений, расположенных в том же каталоге. Данный файл последовательно применяется к каждому представлению, находящемуся в одном каталоге.
При создании проекта ASP.NET MVC 5 в каталог Views уже по умолчанию добавляется файл _ViewStart.cshtml . Этот файл определяет мастер-страницу, используемую по умолчанию:
@{ Layout = "~/Views/Shared/_Layout.cshtml"; }
Данный код выполняется до любого другого кода, определенного в представлении, поэтому из других представлений мы можем удалить секцию Layout . Если же представление должно использовать другую мастер-страницу, то мы просто переопределяем свойство Layout , дописывая его определение в начало представления.
Привет w3ii в HTMLЭтот код показывает пример как HTML страницы:
Hello w3ii!
firstpage.htm », а также создать ссылку на файл, как это: firstpage.htm
Привет w3ii в ASP.NETСамый простой способ, чтобы преобразовать страницу HTML в ASP.NET страницу, чтобы скопировать файл HTML в новый файл с .aspx расширения.
Этот код показывает наш пример, как на странице ASP.NET:
Hello w3ii!
Если вы хотите попробовать это самостоятельно, сохранить код в файле под названием « firstpage.aspx », а также создать ссылку на файл, как это: firstpage.aspx
Как это работает?Фундаментально страница с ASP.NET точно такой же, как HTML-страницы.
HTML страница имеет расширение.htm. Если браузер запрашивает страницу HTML с сервера, сервер отправляет страницу в браузер без каких-либо изменений.
Страница ASP.NET имеет расширение.aspx. Если браузер запрашивает страницу ASP.NET, сервер обрабатывает любой исполняемый код страницы, до того, как результат отправляется обратно в браузер.
Страница ASP.NET выше, не содержит какой-либо исполняемый код, так что ничего не выполняется. В следующих примерах мы добавим исполняемый код страницы, чтобы продемонстрировать разницу между статической HTML-страницами и динамическими страницами ASP.
Классический ASPАктивные серверные страницы (ASP) были вокруг в течение нескольких лет. С ASP, исполняемый код может быть размещен внутри HTML-страниц.
Предыдущие версии ASP (before ASP .NET) часто называют классический ASP.
ASP.NET не полностью совместит с классическим ASP, но большинство страниц Классического ASP будут работать нормально, как страницы ASP.NET, лишь с незначительными изменениями.
Если вы хотите узнать больше о классическом ASP, пожалуйста, посетите наш ASP Учебник .
Динамические страницы в классическом ASPЧтобы продемонстрировать, как ASP может отображать страницы с динамическим содержимым, мы добавили некоторый исполняемый код (in red) в предыдущем примере:
Hello w3ii!
Код внутри теги выполняется на сервере.
Response.Write является ASP код для записи что-то в выходной HTML поток.
Now() является функцией возврата серверов текущей даты и времени.
Если вы хотите попробовать это самостоятельно, сохранить код в файле под названием « dynpage.asp », а также создать ссылку на файл, как это: dynpage.asp
Динамические страницы в ASP .NETЭтот код отображает наш пример, как на странице ASP.NET:
Hello w3ii!
Если вы хотите попробовать это самостоятельно, сохранить код в файле под названием « dynpage.aspx », а также создать ссылку на файл, как это: dynpage.aspx
ASP.NET против классического ASPПредыдущие примеры не демонстрируют каких-либо различий между ASP.NET и классический ASP.
Как вы можете видеть из двух последних примеров нет никаких различий между этими двумя страницами ASP и ASP.NET.
В следующих главах вы увидите, как серверные элементы управления ASP.NET сделать более мощным, чем классический ASP.
