Asp семейство session contents


Содержание

ASP » Session » Contents

The Contents collection property contains all of the items that have been created and added to the Session object through script commands, rather than using the HTML tag.

The Contents collection property contains a list of all of the items that has been created and added to the Session object through script commands, rather than by using the HTML tag.

You can iterate through a collection using a For Each item in . Next loop.

Раздел 6. Основы создания Web сайтов на С# в Visual Studio 2005/2008

Материал следующих глав готовятся к печати

Глава 1. Методика создания Web сайтов

Параграф 1.1. Краткое введение в ASP.NET

Создание Web приложений и Web-сервисов в Visual Studio 2005 основано на использовании технологии ASP.NET, прообразом которой была технология ASP. Технология ASP появилась в 1997 году и предназначалась для построения web-страниц в Internet Information Server(IIS). В сценариях ASP HTML-код объединялся со сценарным кодом, интерпретируемым IIS в ответ на запросы со стороны клиента. В результате строилась страница HTML, которая возвращалась клиенту.

Технология ASP.NET (Active Server Pages .NET) позволила устранить ряд недостатков, присущих ASP (ровно, как и многим другим технологиям создания Web приложений), прежде всего, за счет вывода кода из HTML-страницы в отдельный исполняемый модуль, откомпилированный для среды .NET.

Если ASP представляла собой ISAPI DLL, с набором компонентов и несколькими системными файлами, то ASP.NET — стала частью платформы .NET. Напомним, что в NET используется Intermediate Language — общий промежуточный язык, в который компилируется любой код, независимо от исходного языка программирования. Это готовый к выполнению в среде .NET Framework код. Платформа .NET интерпретирует Intermediate Language и обеспечивает взаимодействие с операционной системой. Кроме того, .NET предоставляет интерфейс приложениям ASP.NET. ASP.NET, в свою очередь, предоставляет интерфейс Web-формам (страницам ASP.NET) и Web-службам. Такое многоуровневое построение позволяет стандартизировать обращение к системным вызовам для Windows и Web, что позволило создать единую методику и среду для разработки Windows программ, Web сайтов, сервисов, библиотек и т.п.

Таким образом, вторым преимуществом ASP.NET стало объединение методики разработки приложений для Web и для Windows. А унификация используемых языков разработки Web сайтов и Windows программ, применение единой среды разработки и отладки, во многом единых или схожих по свойствам элементов управления (controls или контролов), пространств имен (библиотек) и т.д. — сделало новую технологию самой популярной на данный момент.

С точки зрения работы сети обмен данными с web-сервисами проходит по TCP через 80 порт и с использованием стандартного метода POST протокола http.

Параграф 1.2. Где и как разрабатывать Web сайты

Web приложение ASP.NET выполняется на специальных Web серверах, на которых функционируют встроенные информационные службы Интернета — Internet Information Services (IIS). IIS поддерживают доступ по протоколам FTP и HTTP и все, что необходимо клиенту для доступа к Web содержимому сервера.

IIS, получив запрос, «смотрит», к какому типу этот запрос относится (*.asp, *.shtml, *.aspx. ). Если IIS не способен самостоятельно обработать запрос (например, *.html или *.htm он может обрабатывать самостоятельно), то он передает его соответствующему ISAPI-расширению. Чтобы увидеть все доступные расширения и библиотеки, связанные с ними, необходимо:

запустить IIS Manager (как правило, в группе Administrative Tools);

в контекстном меню узла «Web Sites» («Web узел по умолчанию») выбрать пункт меню «Properties»;

в появившемся окне свойств выбрать закладку «Home Directory» («Домашний каталог»);

в группе «Application Settings» нажать кнопку «Configurations:» («Настройка»);

перейти на закладку «Mappings» («Сопоставления»).

В списке «Application Extensions» («Расширения») будут указаны все ISAPI-расширения IIS, установленные на текущий момент. Для расширения .aspx и нескольких других (.asax, .ascx, .ashx, .asmx, .axd, .config, .cs, .csproj, .java, .jsl, .licx, .rem, .resources, .resx, .soar, .vb, .vbproj, .vsdisco, .webinfo), зарегистрирован один исполняемый файл aspnet_isapi.dll. Предполагается, что на компьютере установлен IIS, а после него — .NET Framework, при другой последовательности установки ISAPI-некоторые расширения, возможно, не будет зарегистрированы.

aspnet_isapi.dll обеспечивает обработку запросов ASP.NET и создания рабочих процессов aspnet_wp.exe, выполняющих запросы (aspnet_wp.exe — процесс, в котором, собственно, и работает ASP.NET, в Windows 2003 этот процесс носит имя — w3wp.exe).

Получив такой запрос, расширение проверяет настройки в секции

конфигурационного файла machine.config, находящегося в каталоге «%SystemRoot%\Microsoft.NET\Framework\v%CLRVersion%\CONFIG. Если уже существующий процесс aspnet_wp.exe не удовлетворяет хотя бы одному требованию, указанному в настройках, то aspnet_isapi.dll создает новый процесс с требуемыми настройками. При этом старый рабочий процесс продолжает существовать до окончания обработки выполняемых запросов, после чего удаляется. Таким образом, в любом случае, выполнение Web приложения будет осуществляться в среде IIS.

В ASP.NET 1.0 разработчик сайта, использующий ASP.NET, должен был иметь непосредственный доступ к серверу приложений и его файловой системе. Эта же возможность осталась и в ASP.NET 2.0, хотя стала наименее используемой разработчиками. Для обеспечения доступа к нужному каталогу файловой системы требовалось создать сетевое подключение, например, так. Откроем на панели Windows службу «Мой компьютер», в меню «Сервис» выберем пункт «Подключить сетевой диск». Найдем свободную букву, например «W», нажимаем кнопку «Обзор». Выбираем сетевое имя каталога сервера приложений, в котором будем вести разработку (естественно он должен быть открыт для Вас), ставим галочку «Восстанавливать при входе в систему» и нажимаем кнопку «Готово». Пусть каталог разработки будет:

В любом файловом менеджере (Проводник, Far, Windows Commander ..) в Frameworks\dev (на нашем диске «W») создаем директорию с именем нашего будущего решения, например «MySite1».

Далее, нам потребуется превратить реальный каталог в виртуальный и создать пул для приложения (поскольку эта часть не утратила актуальности, речь об этом пойдет ниже в параграфе «Развертывание Web сайтов на сервере»). С этого момента можно стартовать Visual Studio 2005 и приступать к созданию сайта на сервере.

В Visual Studio 2005 описанный выше путь стал не единственным, и, мало того, новая студия позволила создавать Web приложения вообще без использования IIS и на локальном компьютере (к IIS мы вернемся только при развертывание Web сайта, но это будет после того, как сайт создан и полностью отлажен). Иными словами, при разработке Web сайта на сервере мы предварительно выполняем настройку каталога сайта, а при разработке на локальном компьютере — при развертывании сайта.

Параграф 1.3. Создания Web сайта на локальном компьютере

Для обеспечения возможности создания сайтов на локальном компьютере без использования IIS в Visual Studio 2005 имеется собственный Web-сервер (версия бесплатного сервера Cassini).

Далее мы будем вести речь только о создании сайтов на локальном компьютере и их отладке с использованием локального Web-сервера. Хотя, существенного отличия в локальной и удаленной разработке сайтов нет (она заканчивается на этапе первого шага — выбора расположения сайта, см. ниже), но, выбираемый большинством разработчиков путь, дает Вам несомненные преимущества — возможность пошаговой отладки кода приложения, и независимость от сервера приложений.

Запустим Microsoft Visul C# Net и создадим новый Web сайт, как показано это на Рис.1. (Fole/New/Web Site).

В окне Templates диалогового окна «New Web Site» задаем «ASP.NET Web Site». В окне» Location» выбираем File System, с помощью кнопки Browse определяем папку, где будем создавать все наши сайты. В выбранной папке будет создана новая папка с именем нашего сайта (WebSite1 для Рис.1.). Не забудем выбрать Language и нажимаем «OK». Сайт создан

Рис.1. Создание ASP.NET Web сайта

Сайт на данном этапе представляет собой два файла (Рис.2.): Default.aspx и Default.aspx.cs. Файл Default.aspx определяет HTML содержимое сайта, а Default.aspx.cs — программный код, который отделен от HTML содержимого и предназначен для программного формирования данного содержимого или выполнения каких либо иных действий на сервере. Эта связь определена в директиве Page через свойство CodeFile.

Рис.2. ASP.NET решение Web сайта

Рассмотрим связанный код файла Default.aspx.cs:

Код состоит из одного класса _Default, наследника класса System.Web.UI.Page. Имя класса также присутствует в директиве Page файла Default.aspx — Inherits=»_Default»;

Для того, чтобы убедиться, что это Web сайт, нажмем кнопочку F5(меню Debug\Start Debugging). Отладчик предложит создать файл Web.config, после подтверждения согласия стартует локальный Web Server, иконка которого помещается в системный трэй, а решение отобразится в Web Browser(Рис.3.).

Рис.3. Выполнение ASP.NET сайта

Параграф 1.4. Жизненный цикл страницы

И хотя наш сайт пуст, но он уже «ведет насыщенную жизнь». Для того, чтобы убедиться в этом, добавим в директиву Page свойство Trace=»true» (Директива Page имеет множество свойств, о которых мы будем вести речь по мере их востребования). Вновь нажимаем F5. Результат показан на Рис.4.

Рис.4. Жизненный цикл страницы

Мы видим множество событий, которые произошли при отображении даже пустой страницы. При создании страницы одно из событий (Load) оформляется как метод класса (Page_Load). Однако разработчику доступны и еще четыре события: PreInit, Init, PreRender, Unload. Для каждого из них в класс может быть включен метод его обработки. Кроме того, разработчику будут доступны и события дочерних элементов управления, которые возникают между событиями Load и PreRender страницы. Это следует хорошо запомнить (к этому мы вернемся в следующем параграфе).

Параграф 1.5. Добавление функциональности сайту

На данном этапе наш сайт работоспособен. Добавим на сайт несколько контролов. В окне дизайнера формы (вкладка Designe файла Default.aspx) или на вкладку Source (в отличие от Visual Studio 2003) мы можем перетащить доступные визуальные контролы из окна Toolbox с любой его вкладки, например, Button и Label с вкладки Standart(Рис.5.).

Рис.5. Добавление контролов на сайт

После добавления контрола можно посмотреть и установить его свойства, воспользовавшись его контекстным меню и вызвав окно свойств (пункт Properties) или задать события для обработки, перейдя на вкладку Events окна Properties и кликнув мышкой в окошечке рядом с именем события. Напомним, что двойной клик по самому контролу вызывает его наиболее часто (по мнению разработчиков) востребованное событие (для кнопки это OnClick и обработчик события Button_Click).

В файле Default.aspx.cs добавим (напишем по образцу метода Page_Load) методы Page_PreInit, Page_Init, Page_PreRender, Page_Unload. Создадим событие Button1_Click, Button1_Init, Button1_Load, Button1_PreRender, Button1_Unload (методы для обработки событий пишутся для страницы, а для контролов создаются, а не пишутся, иначе в файле Default.aspx контрол будет не связан с событием).

Файл Default.aspx (его содержимое между тэгами Body) примет вид:

Наполним содержанием методы событий. Поставим целью показать не только возможности вывода текста на страницу, но и возможности изменения свойств элементов управления на различных этапах жизненного цикла страницы. Будем исследовать свойство Text элемента управления Label. Для контрола Label сначала установим свойство EnableViewState в true (по умолчанию), а затем в false и проанализируем результаты функционирования кода.

Свойство страницы IsPostBack равно false только при первом вызове страницы.

Выполним решение (F5), результат показан на Рис.6.

Рис.6. События жизненного цикла страницы и их влияние на свойства элементов

Из анализа функционирования данного кода видно:

Событие PreInit фиксирует этап начала персонализации и формирования страницы в целом. У дочерних элементов это событие не возникает. В обработчике Page_PreInit можно устанавливать шаблоны и темы оформления, изменять свойства элементов. При повторном вызове страницы обработчик данного события также вызывается, но его действие не изменит свойства элементов, у которых установлено свойство EnabledViewState в true.

Событие Init — начало рекурсивной инициализации содержания дочерних элементов страницы. Событие Init дочерних элементов вызывается ранее события Init страницы. Для событий Init дочерних элементов могут быть созданы собственные обработчики события (например, Button1_Init). В Page_Init возможно считывать и инициализировать свойства всех дочерних элементов. При повторном вызове страницы обработчики данного события также вызывается, но их действие, как и в PreInit, не изменит свойства элементов, у которых установлено свойство EnabledViewState в true.

Событие Load возникает как для страницы, так и для дочерних элементов. События дочерних элементов возникают позже чем событие загрузки страницы (в отличии от событий Init). На этом этапе доступны все свойства элементов управления, не зависимо от свойства EnableViewState.

Событие PreRender возникает тогда, когда начинается проверка создания всех элементов страницы. Это последняя возможность внести изменения в свойства страницы и ее элементов.

Событие Unload — начало освобождение занятых ресурсов (закрытие файлов, открытых соединений с базой и т.п.). Свойства страницы на данном этапе недоступны.

Параграф 1.6. Установка Web сайта на сервер

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

Настройка функционирования сайта на локальном компьютере во многом схожа с настройкой его функционирования на сервере приложений и проходит ряд этапов.

Этап 1. Публикация сайта

Сайт перед развертыванием должен быть опубликован — то есть, исполняемый модуль должен быть превращен в dll, а файл странички Default.aspx получить ссылку на эту dll. Сайт перед развертыванием должен быть опубликован — то есть, исполняемый модуль превращен в dll, а страничка aspx получить ссылку на эту dll. Для публикации сайта создадим какой либо каталог (поближе к корню жесткого диска, например C:\MySite_1). Последовательно выполним в меню Visual Studio подпункт Rebuild Web Site пункта Build, а затем подпункт Publish Web Site. В появившемся окне Publish Web Site (Рис.7.) пишем или выбираем C:\MySite_1. Нажимаем кнопочку OK. Сайт опубликован (Рис.7.). Он состоит из нашего файла Default.aspx, файла Web.config (к этому файлу мы не раз еще вернемся), необязательного для сайта файла PrecompiledApp.config и библиотеки со случайным именем.

Рис.7. Публикация Web сайта

Обратим внимание на то, что файл Default.aspx остался таким же, как мы его создали. Изменилась только директива Page — в ней добавилась ссылка на библиотеку класса.

Этап 2. Настройка IIS для работы с сайтом

Для функционирования Web сайтов на Вашем локальном компьютере (не только данного сайта) должна быть установлена служба IIS. Если для выхода в Интернет используется прокси-сервер (на домашних компьютерах прокси для этого никогда не используется), может потребоваться настроить Internet Explorer так, чтобы обходить прокси-сервер (например, так, как показано на Рис.8.).

Рис.8. Настройка Internet Explorer

IIS при установке Windows обычно по умолчанию не устанавливаются. Установить IIS или выбрать дополнительные компоненты можно с помощью приложения «Установка и удаление программ» панели управления Windows. Чтобы установить IIS, добавить или удалить компоненты, нажимаем кнопку «Пуск», «Настройка», выбираем «Панель управления», «Установка и удаление программ». Открываем вкладку «Добавление и удаление компонентов Windows» и ставим галочку напротив Internet Information Serveces (IIS) — Рис.9.

Рис.9. Установка IIS

Далее следуем появляющимся на экране инструкциям для установки, удаления или добавления компонентов IIS.

После установки программы на компьютере создаются следующие каталоги с пользовательским содержимым:

Вы работаете в Visual Studio и на Вашем компьютере Net Framework был установлен вместе со студией.

Если Вы устанавливаете сайт на другом компьютере, то вам придется выполнить установку Net Framework. В Windows Vista Net Framework должен быть предустановлен, ровно как и в Widdows XP с Servis Pak 2, для остальных Windows потребуется установить дистрибутивный пакет Microsoft .NET Framework 2.0, который устанавливает среду .NET Framework и связанные с ней файлы, необходимые для запуска приложений, созданных для работы в среде выполнения .NET Framework 2.0.

Все необходимое можно скачать бесплатно с сайта Microsoft и более близких ссылок: Ссылка 1, Ссылка 2, Ссылка 3. В любом поисковике наберите «Microsoft .NET Framework скачать» и Вы найдете еще множество ссылок и инструкций по установке (хотя они и не требуются, пакет устанавливается как обычная программа).

Этап 3. Проверка работоспособности

Для проверки работоспособности IIS набираем в браузере (в Explorer):

Если все настройки Windows правильны, то в браузере должны отобразиться страницы:

Теперь можно страницы ASP просто копировать в папку.

Доступ к файлу из браузера

Если проверка пройдет неудачно, проверьте настройки ISS (кнопка «Пуск», «Настройка», выбираем «Панель управления», «Администрирование», «Internet Information Services», развертываем в дереве компьютера «Веб-узел по умолчанию») и, в контекстном меню «Веб-узел по умолчанию», выбираем пункт «Свойства». На вкладке «Домашний каталог» и

Рис.10. настройки ISS

вкладке ASP.NET (Рис 2.4) устанавливаем настройки, показанные на рисунках.

Рис.11. настройки ISS

Для развертывания программы потребуется еще одно действие — создание виртуального каталога для программы.

Этап 4. Установка сайта на локальный сервер

Скопируйте всю директорию C:\MySite_1 с нашим сайтом в каталог C:\Inetpub\wwwroot\ (именно сюда).

Вновь запустите IIS (кнопка «Пуск», «Настройка», выбираем «Панель управления», «Администрирование», «Internet Information Services», развертываем в дереве компьютера «Веб узел по умолчанию»). В его дереве появилась папка MySite_1. Осталось превратить ее в виртуальный каталог. На вкладке «Каталог», даем права данному приложению и нажимаем кнопку «Создать».

Рис.12. Создание виртуального каталога

При создании виртуального каталога следует продумать и определить права доступа (В разных версиях IIS список прав может отличаться от приведенного на рисунке):

Доступ к тексту сценариев (Scripts Source Access) — разрешает выполнение ASP.NET файлов.

Чтение (Read) — IIS дает доступ пользователю к запрошенному ASP файлу каталога. Предоставление этого права не дает пользователю права на чтение конфигурационных файлов ASP NET, а отсутствие этого права запрещает доступ и к другим типам файлов (например, HTML и любым не ASP NET файлам).

Запись (Write) — разрешение на запись в каталог.

Выполнение (Execute) — разрешение на запуск других исполняемых файлов (например, ISAPI и CGI).

Запись в журнал (Log Visits) — разрешение на запись в журнал.

Обзор каталогов (Directory Browsing) — разрешение на просмотр файлов каталога.

Индексация каталога (Index this resource).

Проверяем установки на вкладках «Каталог», «Документы» и «ASP.NET» (Рис.13.) и нажимаем кнопку «OK».

Илон Маск рекомендует:  Пример простейшего сниффера для w2kxp

Рис.13. Создание виртуального каталога для папки MySite_1

Обратим внимание на изменившийся вид папки MySite_1 — этот вид соответствует виртуальным каталогам и к ним можно обращаться по URL (Рис.14.).

Рис.14. Виртуальный каталог MySite_1.

Набрав в Explorer следующую строку, мы вызываем программу, она выполняет то, что презентовано выше.

Этап 5. Установка сайта на сервер приложений

Установка сайта на сервер приложений практически нечем не отличается от установки приложения на локальную машину. Скопируйте всю директорию C:\MySite_1 с нашим сайтом в каталог Веб узла по умолчанию сервера приложений. Для этого у вас должен быть соответствующий доступ к этому каталогу и IIS удаленного сервера. После этого сделайте каталог MySite_1 виртуальным, как мы делали выше. Единственное отличие на серверах приложений обычно требуется выбрать Application pool, который должен быть ASP.Net.2 (Рис.15.). Если вы сами разворачиваете сервер приложений, то возможно Вам придется его создать через контекстное меню узла Application Pools (Рис 16).

Рис.15. Виртуальный каталог MySite_1 на сервере приложений


Рис.16. Создание Application Pool для приложения

Глава 2. Подготовка setup файлов и инсталляция web сайтов

На данном этапе у нас есть решение, созданное на локальной машине в директории C:\SamplesASP\WebSite1, виртуальная директория для решения MySite_1 (C:\Inetpub\wwwroot\MySite_1). Мы можем воспользоваться заделом или создать новый сайт.

Изменим решение, убрав из него все лишнее, и вновь поместим на форму контрол Label и Button:

Наполним сайт содержанием:

Вызываем для решения Solution Explorer (View/Solution Explorer) и в самой верхней строчке решения вызываем контекстное меню пункт Add, выбираем пункт New Project. В открывшемся окне Add New Priject выбираем Project Types Setup and Deployment Projekts и Templates Web Setup Project, Name выбираем любое. Location также не имеет существенного значения — это где будут находиться файлы Setup (Рис.17,18.).

Рис.17. Создание проекта инсталляции

Рис.18. Создание проекта инсталляции

В окне File System (MySite1) добавляем через контекстное меню Web Application Folder, пункт Add/Project Output Content Files (рис 19.).

Рис.19. Создание проекта инсталляции

Для Web Application Folder вызываем контекстное меню, выбираем пункт Properties Window и можем поменять директорию установки на сервере — пункт Virtual Directory — изменим на созданную нами виртуальную директорию MySite_1 (Рис.20.).

Рис.20. Создание проекта инсталляции

Вызываем контекстное меню в Solution Explorer для узла MySite1 и выполняем пункт Rebuild (Перед этим необходимо выполнить Build/Rebuild Solutation в режиме Release).

Инсталляционные файлы находятся по адресу заданному нами в Location (Рис.18.) в директории Release. Это файлы MySite1.msi и setup.exe.

Стираем все из директории C:\Inetpub\wwwroot\MySite_1\ и выполняем установку, запустив на выполнение файл setup.exe. Согласившись со всеми настройками, мы закончим установку приложения. Вызываем сайт:

Аналогично можно поступить и на сервере приложений. Копируем файлы MySite1.msi и setup.exe. в любую директорию сервера приложений и выполняем установку, запустив на выполнение файл setup.exe (естественно на сервере) или MySite1.msi. Согласившись со всеми настройками, мы закончим установку приложения. Вызываем страничку из браузера:

Глава 3. HTML и Web контролы и их использование

3.1. HTML и Web контролы

Для уяснения разницы в использовании контролов вкладок HTML и Standart добавим в созданный выше проект два контрола Button — один с вкладки HTML, другой с вкладки Standart. Зададим соответствующие надписи на кнопках, чтобы можно было их различить, и рассмотрим HTML код в файле .aspx. Кнопка с вкладки Standart (Button1), в отличие от кнопки с вкладки HTML, имеет в задании кода также говорит о ее назначении для серверной обработки событий. Кнопка с вкладки HTML является аналогом кнопки HTML документа и может быть использована соответствующим образам (например для запуска скриптов формы и т.п.).

HTML контролы могут быть преобразованы в так называемые, серверные элементы управления (HTML Server Controls) — серверные аналоги стандартных элементов HTML. Для преобразования достаточно вызвать контекстное меню для этого контрола и указать для него режим «Run as Server Control».

Серверные контролы — уже имеют все для выполнения функций серверных или, как принято в данном случае говорить, сетевых элементов управления. Сетевые элементы управления в отличии от серверных имеют множество свойств и событий и отвечают требованиям стандартов разработки приложений Windows, (например, выше, мы использовали обработчик события нажатия кнопки, созданный как для обычного Windows приложения). Кроме того, несмотря на возможность преобразований, между двумя вариантами контролов остаются различия:

В большинстве HTML-редакторов, например, FrontPage, серверные элементы управления будут не видны. Перед Web-дизайнерами встает вопрос: воспользоваться средствами программирования NET или средствами Web-дизайна HTML-редакторов, к которым они привыкли. В тоже время Microsoft, в настоящее время, создала свои средства визуальной разработки (Visual Web Developer 2005), а, учитывая, что продукты фирмы имеют один из самых больших секторов на компьютерном рынке, то следует ожидать и поддержку Net от разработчиков других фирм.

Серверные элементы управления могут быть представлены множеством тегов (например DataGr ).

Если серверный и HTML контрол выполняют одинаковую функцию отправки информации на сервер (например, из текстового поля), то серверный контрол сохранит эту информацию (если обработчик какого либо события не изменит ее), а информация в HTML контроле будет стерта после отправки.

Серверные элементы имеют возможность корректировать код (подстраиваться) под тип браузера.

И, как отмечалось, серверные элементы имеют более развитую функциональность и поддерживают стандартный интерфейс разработки Windows приложений.

Перечисленное выше говорит о предпочтительности использования серверных контролов.

И в заключении рассмотрим сгенерированный HTML код страницы с двумя кнопками, который будет отображен в браузере.

Данный код, в отличии от исходного в файле aspx, не имеет уже выражения runat=»server» (браузеру нет смысла его интерпретировать), но появилось дополнительное скрытое поле (input type=»h ) всех серверных элементов управления.

3.2. Динамическое создание таблиц и работа с ними

Как пример использования серверных Web контролов имеющих аналог среди HTML контролов, рассмотрим динамическое создание таблиц. Этот пример призван показать богатство возможностей серверных контролов по сравнению с их «младшими братьями».

Для динамического создания таблиц в пространстве имен System.Web.UI.WebControls имеются ряд классов, основные из которых: HtmlTable, HtmlTableRow, HtmlTableCell, HtmlTableCellCollection, HtmlTableRowCollection

В Visual Studio реализована поддержка простой модели таблицы. Это означает, что нельзя динамически создать , , ,

, , элементы.

Обратим внимание, что создавать контролы придется каждый раз при перезагрузке страницы так как элемент Таблица добавляется в экземпляр класса страницы, который формируется заново при каждой загрузке страницы. Однако содержимое ячеек таблицы и состояние контролов восстанавливается (используется встроенный механизм ViewState).

Ниже приведен пример динамического создания таблицы, вывода в ячейки созданной таблицы информации и элементов управления, которые так же создаются динамически. Кроме того, показан пример использования событий динамически созданных и добавленных в ячейки таблицы элементов управления. На форме решения web сайта размещены три контрола: PlaceHolder, Label ( >

Рис.21. Пример работы с динамически созданной таблицей

Глава 4 Управление состоянием Web приложений

Параграф 4.1. Использование VIEWSTATE

Ранее мы отмечали, что код файла aspx. после первого вызова страницы с сервера, в отличии от исходного, уже не имеет свойства runat=»server» (браузеру он не нужен), но содержит дополнительное скрытое поле (input type=»h , то можно просмотреть вид и объем информации, передаваемой сервером (Рис.22.).

Рис.22. VIEWSTATE и объем передаваемой информации

Имеется возможность запретить использование __VIEWSTATE как для страницы целиком, так и для отдельных элементов, используя свойство EnableViewState, которое имеется и у директории Page, и у многих контролов.

Разработчик может хранить в VIEWSTATE и свою информацию, например, число ошибок допущенных при тестировании (в директиве Page EnableViewState должно быть true).

В приведенном примере значение переменной viNumError после отсылки страницы на сервер и ее возврата клиенту не сохраняется. VIEWSTATE помогает поместить ее значение в поле сохранения и восстановить при загрузке страницы. Этот механизм достаточно удобен при работе на одной страницы. Переход на другую страницу сайта (например, Response.Redirect(«Default2.aspx»)) и последующий возврат на исходную, ведет к потере сохраненных значений. Кроме того, VIEWSTATE текущей страницы недоступно странице, на которую будет выполнен переход.

Параграф 4.2. Передача информации между страницами сайта

4.2.1. Использование URL

Существует несколько способов передачи данных между страницами. Самый простой — включить значение переменной в URL(строку запроса) вызываемой страницы. Передаваемые данные должны следовать за URL вызываемой страницы после вопросительного знака. Данные включаются по принципу «имя-значение» и разделяются знаком &.

Для демонстрации данной возможности, добавим в решение еще одну Web страничку ()

URL вызова будет:

Этот метод имеет как свои преимущества (нет дополнительной нагрузки на сервер, высокая скорость передачи данных), так и недостатки (открытость и незащищенность информации, ограниченность объема — предельная длина URL обычно 1-2кб и ограниченный набор символов, допустимых в URL.

Для приема данных используется метод QueryString класса Request.

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

Кликнем правой кнопкой мышки на имени решения в SolutionExplorer и, выбрав пункт контекстного меню Add, подпункт Add WebForm, добавим к решению еще одну форму, которая по умолчание будет иметь имя WebForm2. На форму поместим контрол Label и в Page_Load запишем следующий код:

По нажатии кнопки 2 будет не только вызвана страничка WebForm2.aspx, но и передан наш текст в Label.

Еще одна возможность передачи данных в URL — передача и получение информации о контроле, который вызвал Redirect на страницу. Пусть у нас несколько событий нажатия кнопок замкнуты на один обработчик, например Button1_Click. Тогда мы можем передать информацию страничке на которую переходим следующим образом:

На страничке WebForm2.aspx мы легко можем узнать по какой кнопке выполнен Redirect:

Cookie(печенье) — небольшие файлы, создаваемые на жестком диске или в памяти браузера машины клиента, позволяющие Web серверам хранить в них информацию.

Это достаточно удобный метод хранения информации, но, и он не лишен некоторых недостатков, таких как: возможность удаления cookie пользователем или принудительного отключения, доступность только из встроенных браузеров, доступность и открытость хранимой информации.

Для получения доступа к cookie в приложении должна быть подключено пространство имен:

Для работы с cookie используется классы Request и Response. Следующий пример демонстрирует создание и использование cookie. На форме решения поместим три контрола: Button, Label и TextBox. В обработчиках событий запишем следующий код:

Результат работы показан на Рис.23.

Рис.23. Пример использования cookie

В файле C:\Documents and Settings\Имя_Компьютера\Cookies\, найдем наше «печенье». Имя cookie включает имя_пользователя_компьютера@имя_сервера[1] (где имя_сервера localhost, yandex и т.п.) при старте будет записано:

После регистрации и второго вызова:

Параграф 4.3. Сеансы и их использование

4.3.1. Понятие сеанса в ASP.NET

Необходимость использования сеансов возникла из за потребности хранения больших объемов информации, хранение которых уже рассмотренными нами способами либо невозможно, либо нецелесообразно.

Сеанс (сессия) объединяет некоторую информацию серии запросов с одного адреса (одного клиента) в течении определенного времени. Каждый клиент, который получает доступ к сайту, получает свой сеанс и, как следствие, свою коллекцию данных. Сеанс начинается, когда пользователь в первый раз запрашивает страницу сайта, и заканчивается, когда приложение явно закрывает сеанс или когда превышено заданное время ожидания.

ASP.NET содержит необходимую структуру данных состояния каждого сеанса, позволяющую:

Автоматически определять и классифицировать запросы, приходящие от клиента.

Хранить данные с ограниченной областью действия на сервере.

Создавать соответствующие события управления жизненным циклом сессии (Session_OnStart, Session_OnEnd и т. д.).

Автоматически освобождать данные сеанса, если клиент не посещает сайт определенный период времени.

Каждый активный сеанс ASP.NET имеет идентификатор, представляющий собой 120-разрядную строку — SessionID, состоящую из допустимых в URL-адресах знаков ASCII. Алгоритм генерации значений SessionID гарантирует уникальность (во избежание совпадений идентификаторов сеансов) и случайность. Нельзя воспользоваться значением SessionID для вычисления значения идентификатора сеанса. В зависимости от параметров приложения строка SessionID передается между сервером и клиентом посредством файлов cookie или с помощью включения значения SessionID в URL-адрес. Этот идентификатор является единственным фрагментом информации сессии, которая передается между сервером и клиентом.

Когда клиент предъявляет идентификатор сеанса, то сервер находит соответствующий сеанс, извлекает данные, преобразует их в объекты и помещает в коллекцию данных, откуда данные становятся доступны программному коду страницы запроса. Идентификаторы у разных клиентских запросов различны, как результат — доступ возможен только к своей коллекции данных. До тех пор, пока клиент не использует сеанс для сохранения данных, идентификатор сеанса при каждом запросе генерируется вновь (иначе, сеанс сохраняется только если было сохранение данных). Это позволяет сократить затраты памяти и время на сохранение данных и идентификатора сеанса.

Основной недостаток сеансов — это затраты памяти, которые при большом объеме хранимой информации и большом числе обращений к серверу могут значительно снизить его производительность.

4.3.2. Свойства и методы объекта Session

Для организации работы с сеансами используется класс System.Web.SessionState.HttpSessionState, который на web странице приложения доступен как встроенный объект Session.

Перечислим основные свойства и методы HttpSessionState:

Основные свойства

CodePage — возвращает или задает идентификатор кодовой страницы для текущего сеанса.

Contents — возвращает ссылку на текущий объект состояния сеанса. Иначе, семейство Contents объекта Session содержит все хранящиеся переменные сеанса.

Count — возвращает число элементов в коллекции состояния сеанса.

IsCookieless — возвращает значение, показывающее, был ли идентификатор сеанса внедрен в URL-адрес или сохранен в файле cookie.

IsNewSession — возвращает значение, показывающее, был ли создан сеанс с текущим запросом.

IsReadOnly — возвращает значение, показывающее, доступен ли сеанс только для чтения.

IsSynchronized — возвращает значение, показывающее, синхронизирован ли доступ к коллекции значений состояний сеанса (потокобезопасный доступ).

Item — возвращает или устанавливает индивидуальные значения сеанса. (в C# является индексатором класса HttpSessionState).

Keys — возвращает коллекцию ключей всех значений, сохраненных во время сеанса.

LCID — возвращает или задает идентификатор языка и стандартов (LCID) текущего сеанса.

Mode — возвращает текущий режим состояния сеанса.

SessionID — возвращает уникальный идентификатор сеанса, применяемый для определения сеанса.

StaticObjects — возвращает коллекцию объектов, объявленных тегами файла приложения ASP.NET: global.asax.

SyncRoot — возвращает объект, который можно использовать для синхронизации доступа к коллекции значений состояния сеанса.

Timeout — возвращает и задает допустимое время ожидания (в минутах) между запросами перед завершением сеанса провайдером состояния сеанса.

Основные методы

Abandon — уничтожает все объекты, хранимые в объекте Session и освобождает их ресурсы. Если метод Abandon не вызван явно, сервер уничтожит объекты при истечении времени ожидания сеанса. При вызове метода Abandon запрашивается удаление текущего объекта Session, но он не удаляется до тех пор, пока не будут обработаны все команды сценария на текущей странице. (можно обращаться к переменным, хранимым в объекте Session, с той же страницы, где расположен вызов Abandon, но не с любой последующей веб-страницы).

Add — добавляет новый элемент в состояние сеанса.

Clear — удаляет все значения из состояния сеанса.

CopyTo — Копирует коллекцию значений состояния сеанса в одномерный массив, начиная с заданного индекса массива.

Equals — (унаследовано от Object)- определяет, равны ли два экземпляра Object.

GetEnumerator — возвращает перечислитель всех значений состояния сеанса для текущего сеанса.

GetHashCode — (унаследовано от Object) — служит хеш-функцией для конкретного типа, пригоден для использования в алгоритмах хеширования и структурах данных, например в хеш-таблице.

GetType (унаследовано от Object) — возвращает Type текущего экземпляра.

Remove — удаляет элемент из коллекции состояний сеанса.

RemoveAll — удаляет все значения состояния сеанса.

RemoveAt — удаляет элемент по заданному индексу из коллекции состояний сеанса.

ToString (унаследовано от Object) — возвращает строку, которой представлен текущий Object.

4.3.3. Пример использования сеанса

Рассмотрим пример хранения некоторого класса RegInfo с использованием сессии. Для этого объявим класс в, котором пользователь будет накапливать некоторую регистрационную информацию:

Несколько примеров использования свойств и методов Session:


Использование метода IsCookieless:

При значении свойства cookieless=»true», URL запроса будет выглядеть примерно так:

С помощью метода Remove семейства Contents можно выборочно или полностью удалить ссылки на переменные, которые добавлялись при соответствующем состоянии сеанса:

4.3.4. Настройка состояния сеанса

Конфигурационные данные хранятся в текстовом файле Web.config (в Visual Studio .Net генерируется автоматически), находящемся в каталоге приложения. Этот файл определяет условия выполнения приложений ASP .NET — такие как параметры отладки и системы безопасности. Состояние сеанса также хранится в файле Web.config.

Пример фрагмента файла Web.config:

Параметр mode может иметь значения: «InProc» — (по умолчанию) внутренний режим состояния сеанса (информация хранится в том же процессе, где и рабочие потоки), «off» — отключено управление состоянием сеанса, «StateServer» — использование отдельной службы сервера для управления сеансом, «SqlServer» — использование базы данных SQL для хранения состояния сеанса.

Если в приложении не используются сеансы, то для некоторого повышения производительности целесообразно задать mode=»Off», mode=»InProc» обеспечивает высокую производительность, но не сохраняет сеанс при перезапуске страницы.

При использовании mode=»StateServer», служба управления состоянием сеанса (служба ASP.NET State Server), запущенная на сервере, дает базовый уровень защиты при перезапуске процесса, что, естественно, влечет дополнительные временные издержки. В этом случае обязательно указание параметра stateConnectionString (TCP/IP компьютера — служба может быть запущена и на другом компьютере). Служба запускается из Administrative Tools панели управления, пункт Services, найти ASP.NET State Server и через контекстное меню строки с именем сервера выполнить пункт меню Start. Через контекстное меню, пункт Properties, выполняется и установка Startup Type (например, на автоматический запуск — выбрать Automatic).

При использовании mode=»SqlServer», Sql сервер обеспечивает самый надежный, но и самый медленный метод хранения данных. Метод требует задания параметров sqlConnectionString, включая пароль доступа (явно нежелательно при неиспользовании интегрированных методов доступа), установку специальных хранимых процедур для сохранения и извлечения информации о сеансе, и временных баз данных для сеансов.

ASP.NET включает для этой цели сценарий Transact-SQL с именем InstalSqlState.Sql (каталог Winnt\Microsoft.Net\Framework\номер_версии, сценарий можно запустить используя утилиты SQL Server OSQL.exe или Query Analyzer). После выполнения сценария средства все указанные средства, обеспечивающие работу с сессией и хранения данных в Sql БД становятся доступными, в том числе и после перегрузке компьютера.

Значении параметра cookieless=»true» означает, что идентификатор сеанса внедряется в URL-адрес.

Значение timeout устанавливает время жизни сеанса.

Глава 5. Класс — HttpApplication и состояние приложения

В ASP.NET есть специальный класс — HttpApplication (System.Web.HttpApplication), представляющий все приложение. Он контролирует его общее состояние, и обрабатывает глобальные события. В основном этот класс используется для хранения объектов уровня приложения, к которым может получить доступ любой клиент.

Класс HttpApplication предоставляет программный доступ к методам HttpApplication.Init и HttpApplication.Dispose и событиям Application_OnStart и Application_OnEnd и др. Кроме того, из него есть доступ ко всем public свойствам и событиям во всех модулях приложения.

Глава 6. Новые возможности передачи данных между формами в ASP.Net 2.0

В ASP.NET 2.0 появилась возможность непосредственно передавать данные, введенные на одной странице в некоторой вводной форме (в поле элемента управления) другой странице формы одного решения. Причем, данный механизм позволяет получать в вызываемой форме значения свойств элементов из вызывающей формы. Для этого в ASP.NET 2.0 для ряда контролов введено дополнительное свойство — PostBackUrl, позволяющие указать какой именно странице решения должна быть передана информация из элементов управления вызывающей страницы, если обращение к серверу инициировано этим элементом управления.

Например, создадим решение, имеющее две формы (Default и WebForm2). Разместим на форме Default контролы TextBox и Button. Для контрола Button установим свойство PostBackUrl в значение WebForm2 (Рис.24, 25).

Рис.24. Решение сайта

Рис.25. Решение сайта

Выполним решение сайта. Убедимся, что даже при отсутствии обработчика нажатия кнопки, сервер, при нажатии кнопки «Передать», выполнит редирект на WebForm2. Но не только пользователь будет переадресован на страницу WebForm2.aspx, но и вся информация об элементах управления формы Default.aspx, будет также передана форме WebForm2.aspx. Для реализации этой возможности, ASP.NET 2.0 проверяет формы на наличие в них элементов управления с атрибутом PostBackUrl и, при их наличии, создает для страницы дополнительное скрытое поле __PREVIOUSPAGE, которое и содержит информацию о состоянии элементов формы. Эта информация может быть извлечена на вызываемой странице через свойство PreviousPage.

Илон Маск рекомендует:  Что такое код get_defined_constants

Для демонстрации возможности передачи информации (из контрола TextBox формы Default.aspx в форму WebForm2.aspx) на странице WebForm2 разместим контрол Label и контрол TextBox.

В файле WebForm2.aspx.cs напишем следующий код:

Теперь, при нажатии в форме Default.aspx кнопки «Передать» будет вызвана форма WebForm2, и в ней отобразится информация, введенная в textBox1 формы Default.aspx (Рис.26.).

Рис.26. Выполнение решения сайта

Другая возможность получения доступа с использованием PreviousPage показана на Рис.27. В форме Default мы объявили public переменную viI и при загрузке присвоили ей значение 10.

Далее, используя приведение PreviousPage к странице родителю мы можем получить доступ к public свойствам и переменным вызвавшей страницы.

Рис.27. Выполнение решения сайта

Отметим, что PreviousPage содержит информацию практически обо всей вызвавшей странице: Title, Header, IsVal >

Уроки ASP-технологий

Объект Application

Теперь давайте рассмотрим объект Application. Он предназначен для хранения глобальных переменных ASP-приложения, то есть переменных, которые доступны каждому сеансу приложения. Эти переменные находятся в коллекции Contents, к которой обычно обращаются сокращенно. Например, запишем следующий код в файл default.asp.

Затем создадим файл test.asp и наберем такой код:

После этого исполним сценарий default.asp, а затем test.asp. Последний выведет строку test в окне браузера. Вообще, в какой бы сценарий приложения мы не вставили код test.asp, результат будет одним и тем же.

Объект Application предоставляет разработчикам два метода:

Они предназначены для блокирования и разблокирования, соответственно, всего приложения. Например, чтобы избежать ситуации, когда в переменную уровня приложения записываются одновременно два значения, можно применить следующий код:

Кроме коллекций и свойств у объекта Application есть два события: Application_OnEnd и Application_OnStart, которые мы рассмотрим чуть позже.

Объект Session

Этот объект предназначен для управления сеансами. Он имеет четыре свойства:

Первые два свойства — это таблица кодировки и идентификатор локали. Их мы рассматривать не будем, так как они практически не используются.

Свойство SessionID доступно в режиме «только для чтения» и возвращает уникальный идентификатор сеанса. Использование:

Свойство TimeOut отвечает за время, через которое движок ASP прервет сеанс и удалит всю связанную с ним информацию на сервере. Установка этого свойства не позволяет оставлять данные о конкретном пользователе на сервере после того, как он отключился. Принимает значения в минутах. Например:

Объект Session имеет один метод — Abandon, который позволяет принудительно прервать сеанс до истечения срока, указанного в свойстве TimeOut. Пример использования:

В объекте Session, как и в объекте Application, можно хранить данные. Для этого используются переменные уровня сессии. Например:

Кроме того, объект Session предоставляет разработчикам два события: Session_OnStart и Session_OnEnd, которые мы рассмотрим немного ниже.

Файл Global.asa

С чего начинается … нет, не Родина �� — web-приложение? Ответ такой: с файла Global.asa. Он является главным файлом приложения. В этом файле могут существовать только следующие элементы:

  • Четыре события: Application_OnStart, Application_OnEnd, Session_OnStart, Session_OnEnd;
  • Тэги

Атрибут RUNAT всегда принимает значение Server. Атрибут SCOPE определяет область видимости компоненты (Application или Session). ID — это идентификатор, с помощью которого в дальнейшем можно будет получить доступ к объекту. Далее вы указываете PROGID или CLASSID, которые нужны, чтобы идентифицировать компонент.

Например, вы хотите создать экземпляр компонента BrowserCapabilities (он рассматривался выше), который был бы доступен каждому сеансу приложения. Для этого в файле global.asa необходимо написать примерно следующий код:

После этого вы получаете доступ к свойствам и методам данного компонента из любого сценария вашего приложения простым обращением к переменной MyBrowser. Например:

Также экземпляры ActiveX-компонентов можно создавать с помощью подключения библиотеки типов данной компоненты. Делается это следующим образом:

Атрибут TYPE всегда принимает значение TypeLib. В атрибуте FILE необходимо указать путь к библиотеке типов вашего компонента. UUID — это уникальный идентификатор этой библиотеки. Указывать можно либо FILE, либо UUID. VERSION — это, естественно, версия компоненты :-). Атрибут LCID отвечает за идентификатор локали.

Например, у вас есть библиотека динамической компоновки MyLib.dll, а у нее есть библиотека типов MyLib.lib. Вы можете подключить ее в файле global.asa вот таким способом:

Затем в любом сценарии приложения можно использовать этот компонент следующим образом:

ASP Объект Session

Объект Session хранит информацию о, или изменения настроек для сеанса пользователя.

Объект Session

Когда вы работаете с приложением на вашем компьютере, вы открываете его, сделать некоторые изменения, а затем закрыть его. Это очень похоже на сессии. Компьютер знает, кто ты. Он знает, когда вы открываете приложение и при его закрытии. Тем не менее, в Интернете есть одна проблема: веб-сервер не знает, кто вы и что вы делаете, так как адрес HTTP не поддерживает состояние.

ASP решает эту проблему, создавая уникальные кук для каждого пользователя. Печенье отправляется на компьютер пользователя и содержит информацию, которая идентифицирует пользователя. Этот интерфейс называется объект Session.

Объект Session хранит информацию о, или изменения настроек для сеанса пользователя.

Переменные, хранящиеся в сессии объекта хранения информации об одном пользователе, и доступны для всех страниц в одном приложении. Общая информация, хранящаяся в сессионных переменных имя, идентификатор и предпочтения. Сервер создает новый объект Session для каждого нового пользователя, и уничтожает объект Session, когда истекает сессия.

Когда делает Start Session?

Сеанс начинается, когда:

  • Новый пользователь запрашивает файл ASP, а файл Global.asa включает процедуру Session_OnStart
  • Значение хранится в переменной Session
  • Пользователь запрашивает файл ASP, а файл Global.asa использует тег для создания экземпляра объекта с областью сеанса

Когда сеанс End?

Сессия заканчивается, если пользователь не запросил или обновлять страницу в заявке на определенный период времени. По умолчанию это 20 минут.

Если вы хотите установить интервал времени ожидания , который короче или длиннее , чем по умолчанию, используйте Timeout свойство.

Приведенный ниже пример задает интервал времени ожидания 5 минут:

Используйте Abandon метод немедленно завершить сеанс:

Note: Основная проблема с сессиями, когда они должны закончить. Мы не знаем, если последний запрос пользователя был последний один или нет. Таким образом , мы не знаем , как долго мы должны держать сессию «alive» . Ожидание слишком долго простоя сеанса использует ресурсы на сервере, но если сессия будет удалена слишком рано, пользователь должен начать все сначала, потому что сервер удалила всю информацию. Поиск подходящего интервала ожидания может быть трудно!

Tip: только хранить небольшое количество данных в переменных сеанса!

Хранить и получать переменные сеанса

Самое главное об объекте Session является то, что вы можете хранить переменные в нем.

В приведенном ниже пример будет установить переменную Session username для «Donald Duck» и Session переменного age до «50» :

Когда значение сохраняется в переменной сеанса может быть достигнуто с любой страницы в приложении ASP:

Линия выше возвращений: «Welcome Donald Duck» .

Можно также сохранять пользовательские настройки в объекте Session, а затем получить доступ к этому предпочтению выбрать, какую страницу, чтобы вернуться к пользователю.

В приведенном ниже пример задает текстовую версию страницы, если пользователь имеет низкое разрешение экрана:

Удаление переменных сеанса

Коллекция Содержание содержит все переменные сессии.

Можно удалить переменную сеанса с помощью метода Remove.

В приведенном ниже примере удаляет переменную сеанса «sale» , если значение переменной сеанса «age» ниже , чем 18:

Для того, чтобы удалить все переменные в сеансе, используйте метод RemoveAll:

Проходной коллекции Содержание

Коллекция Содержание содержит все переменные сессии. Вы можете перебрать коллекции Contents, чтобы увидеть, что в нем хранятся

Если вы не знаете, количество элементов в коллекции Contents, вы можете использовать свойство Count:

Проходной коллекции StaticObjects

Вы можете перебрать коллекцию StaticObjects, чтобы увидеть значение всех объектов, хранящихся в объекте Session:

Session in > Ask Question

I’w working on a project in classic ASP and I want to add, for example, some users for a temporary list and when I submit the form, this data will be save to DB.

I know how to work with this in asp.net, but not in classic asp.

Is it possible to create lists of users, for example, and manage this in a session?

2 Answers 2

yesa, you can use this, or the application state. one thing do note, you cant save objects in it, so you’ll need to do some serialization if you want to store any complex things in it.

OPINION

You do have a couple of options of which a session is not one I would recommend. Just using form posting would be preferable just because of all the potential overhead with sessions in general. The most you would generally want to use them for is login data storage for a user logged into a site.

Asp семейство session contents

Нередко для обработки запроса требуется информация о контексте запроса: какой у пользователя браузер, ip-адрес, с какой страницы или сайта пользователь попал к нам. И ASP.NET MVC позволяет получить всю эту информацию, используя объект HttpContext.

Хотя в контроллере мы также можем обратиться к объекту ControllerContext , который имеет свойство HttpContext и по сути предоставляет доступ к той же функциональности и информации. Но в то же время между ними есть некоторые различия. Объект HttpContext описывает данные конкретного http-запроса, который обрабатывается приложением. А ControllerContext описывает данные http-запроса непосредственно по отношению к данному контроллеру.

Вся информация о контексте запроса доступна нам через свойства объекта HttpContext. Так, все данные запроса содержится в свойстве Request . HttpContext.Request представляет объект класса, унаследованного от HttpRequestBase , и поэтому содержит все его свойства. Рассмотрим некоторые из них:

Получение браузера пользователя: HttpContext.Request.Browser

Иногда просто браузера недостаточно, тогда можно обратиться к агенту пользователя: HttpContext.Request.UserAgent

Получение url запроса: HttpContext.Request.RawUrl

Получение IP-адреса пользователя: HttpContext.Request.UserHostAddress

Получение реферера: HttpContext.Request.UrlReferrer == null ? «» : HttpContext.Request.UrlReferrer.AbsoluteUri Так как реферер может быть не определен, то сначала смотрим, не равен ли он null

Отправка ответа

Если HttpContext.Request содержит информацию о запросе, то свойство HttpContext.Response управляет ответом. Оно представляет объект HttpResponse , который передает на сторону клиента некоторые значения: куки, служебные заголовки, сам ответ в виде кода html. Например, установим кодировку ответа: HttpContext.Response.Charset = «iso-8859-2»;

Методы объекта HttpResponse позволяют управлять ответом. Например, метод AddHeader позволяет добавить к ответу дополнительный заголовок.

Кроме того, нам необязательно вызывать метод View в действия контроллера, чтобы отправить клиенту ответ запроса. Мы вполне можем воспользоваться методом HttpContext.Response.Write :

Метод HttpContext.Response.Write здесь добавляет в поток определенное содержимое, переданное в качестве параметра. Но в реальности, конечно, проще использовать методы, генерирующие объекты ActionResult, например, представления.

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

Также объект HttpContext содержит информацию о пользователе в свойстве HttpContext.User :

Подробнее об идентификации пользователя можно узнать в главе про аутентификацию и авторизацию.

Работа с куки

Чтобы получить куки, нам надо воспользоваться свойством HttpContext.Request.Cookies :


В данном случае, если у нас установлена на стороне клиента куки «id», то мы получим ее значение.

Однако прежде чем получать значения куки, их естественно надо установить. Для установки значения куки мы можем использовать свойство HttpContext.Response . Например, установим в куки значение «id»:

Сессии

Сессии также, как и куки, используются для хранения некоторых данных, которые можно получить в любом месте приложения. Для работы с ними используется объект Session . Например, установим в одном методе контроллера мы можем установить значение сессии:

А получить можно в другом методе:

Если мы хотим удалить значение сессии для ключа name, мы можем просто присвоить значение null: Session[«name»]=null;

Управление состоянием в ASP.NET — Серверные методы. Session

Written on 27 Декабря 2006 . Posted in ASP.NET

ОГЛАВЛЕНИЕ

Session

Контейнер Session похож на Application, с той лишь разницей, что для каждого пользователя приложения создается своя собственная сессия со своими собственными значениями. Для идентификации пользователей ASP.NET использует 120-битный ключ, именуемый SessionID и состоящий только из ASCII-символов, которые допустимы для использования в URL. В зависимости от настроек веб-приложения, этот ключ сохраняется либо в Cookie либо включается как часть URL.

Если приложение настроено на использование URL для хранения SessionID, то написав в браузере, например, http://localhost/StateManagement/SessionStateTest.aspx, после загрузки страницы мы увидим вместо него нечто такое http://localhost/StateManagement/(evzobo45mp1rat55b3qm5o55)/SessionStateTest.aspx, где evzobo45mp1rat55b3qm5o55 — тот самый SessionID

При поступлении запроса от пользователя, у которого нет соответствующего Cookie или он не имеет SessionID в URL запроса, инициируется создание новой сессии. При этом происходит генерация нового уникального SessionID. После чего возникает событие Session_Start веб-приложения.

Сессия существует до тех пор, пока пользователь работает с веб-приложением и еще немного после. Для этого в настройках аппликации выставляется таймаут сессии, который по умолчанию составляет 20 минут. Т.е. если пользователь в течение 20 минут не совершил ни одного запроса к приложению, то сессия этого пользователя уничтожается. При этом возникает событие Session_End приложения.

Также как Application, для совместимости с предыдущими версиями ASP, контейнер включает в себя две коллекции Contents и StaticObjects. Для доступа к Contents можно либо использовать одноименное свойство, либо индексатор Session. Например:

Коллекция StaticObjects является read-only коллекцией, ее элементы определяются в файле Global.asax с помощью тега . Например:

Использовать его можно аналогично вышеуказанному примеру для Application:

Механизм сессий, в отличие от Application, предоставляет несколько способов сохранения. Какой из них использовать в приложении, определяется атрибутом mode тега в файле web.config. Этот атрибут может принимать пять значений:

Off. Сессии отключены, т.е. данные сессии никак не сохраняются.

InProc. Способ, унаследованный от предыдущих версий ASP. Сессия храниться в локальной памяти веб-сервера. В результате при сбое приложения или перезапуске веб-сервера все данные теряются. Это может быть вызвано, например, настройками из тега

ASP Session

The Session Object in ASP is a great tool for the modern web site. It allows you to keep information specific to each of your site’s visitors. Information like username, shopping cart, and location can be stored for the life of the session so you don’t have to worry about passing information page to page.

In old web page designs you might have to try to pass information this information through HTML Forms or other methods.

ASP Session Object

Contained within the Session Object are several important features that we will talk about in this lesson. The most important thing to know about ASP’s Session Object is that it is only created when you store information into the Session Contents collection. We will now look into creating and storing information in an ASP Session.

ASP Session Variables

To store a Session Variable you must put it into the Contents collection, which is very easy to do. If you have already read the ASP Arrays Lesson then this bit of code will be a cinch!

Here we are saving the Time when someone visited this page into the Session Contents collection and then displaying it .

ASP Code:

Display:

Here we are creating two things actually: a key and a value. Above we created the key «TimeVisited» which we assigned the value returned by the Time() function. Whenever you create a Session Variable to be stored in the Session Contents collection you will need to make this Key / Value pair.

ASP Session ID

The ASP Session ID is the unique identifier that is automatically created when a Session starts for a given visitor. The Session ID is a property of the Session Object and is rightly called the SessionID property. Below we store the user’s SessionID into a variable.

ASP Code:

ASP Session Timeout

A Session will not last forever, so eventually the data stored within the Session will be lost. There are many reasons for a Session being destroyed. The user could close their browser or they could leave their computer for an extended amount of time and the Session would time out. You can set how long it takes, in minutes, for a session to time out with the Timeout property.

Below we set our session to timeout after 240 minutes, which should be more than enough time for most web sites.

ASP Code:

Display:

Note: Timeout is defined in terms of minutes.

Found Something Wrong in this Lesson?

Report a Bug or Comment on This Lesson — Your input is what keeps Tizag improving with time!

ASP Sessions and Applications

The most powerful aspect of server-side scripting languages such as ASP is their almost magical ability to turn the Web – a medium originally crafted to serve one static document after another – into a platform that delivers rich, interactive experiences. These experiences come in the form of online applications that respond differently to different users in different situations.

To make this transformation possible, ASP must not only be able to produce dynamically-generated Web pages in response to requests. It must also have the ability to track information that’s specific to the users of a set of related ASP scripts (e.g. an online discussion forum), and permit those scripts to share information with each other.

In this, the fourth article in SitePoint’s series on ASP, I’ll be describing the features of ASP that make the above possible: Applications and Sessions. To start, I’ll take you through the steps required to create a Web Application in Microsoft Internet Information Server (IIS), and I’ll explain how applications and sessions fill the need for persistent data. I’ll then introduce you to the Application and Session objects in ASP that are the center of the magic, and also explain the role of the global.asa file. Finally, I’ll take you through the code of a complete example that deals with tracking the number of users on your site at any given time.

This article assumes that you’re familiar with the concepts covered in the previous articles in this series, beginning with Getting Started with ASP. If you haven’t read them, and you’re approaching ASP for the first time, I would suggest at least skimming through those previous articles before you jump into this one.

Web Applications in IIS

A Web application is a lot like any other software application that you’d run on your computer, except that the interface is provided by a set of Web pages, and the code of the application runs mainly on the Web server from which you fetch those pages. Examples of common Web applications today include discussion forums, book stores, and custom news feeds.

From the point of view of an ASP developer, however, a Web application is just a collection of ASP files that work together to provide this kind of service. This group of ASP files is generally stored in a single directory, and possibly a number of subdirectories. The first step in taking advantage of the features that ASP provides to support the development of Web applications is to identify that ‘application root directory’ to IIS.

I’ll assume for the moment that you have administrator-level access to the IIS server that you’re using for ASP development. In this case, your first task is to define a Web application on your server. Create a directory anywhere on the server (I chose c:MyApplication ) that you’ll use for the examples in this article. Open Control Panel, Administrative Tools, and Internet Information Services, then navigate to the Default Web Site. Right-click on it and select New, Virtual Directory. When prompted by the wizard, type an alias for the directory as it will appear in the URL (e.g. a virtual directory with the alias myapp will be accessible as http://localhost/myapp/ from your computer and as http://your.host.name/myapp/ from other computers on your network), and then browse to the directory you just created. For the access permissions, leave the default options (Read and Run Scripts) selected. When you’ve completed the wizard, the new virtual directory should appear in the tree view as shown here:

You’ve now defined a Web application on your server. All the ASP files contained in that directory (or its subdirectories) will be considered a part of the myapp application (or whatever you chose to call it). Before we explore further the features of ASP that take advantage of this, let’s stop and examine what we need a Web application for.

The Need for Persistent Data

As we’ve seen in previous articles in this series, you can store values in ASP variables and display them as part of a dynamic Web page. One limitation of variables, however, is that they only exist for as long as the particular ASP script that created them runs. Once an ASP script has ended, and the last of the Web page has been sent to the requesting browser, all the variables that were created during the course of the script’s execution are destroyed to free up memory, to enable later page requests to be processed.

There are many situations where it would be handy to have a variable that stayed in memory at the end of one ASP script so that the value stored within it could be picked up and used again by another script later on. In the last article, we saw how we could pass information from one page to another, either through a form submission or with a URL query string; however, these methods are not always adequate.

For instance, take the example we looked at in that article. Here we prompted the user for his or her name with an HTML form that appeared on the first page requested when they entered the site. We then passed that name on to each additional page with a query string that contained the name the user entered. Imagine the implications of putting this example to practical use on a site the size of SitePoint.com. Every single link in every single page would have to be individually coded to pass the username variable on to the next page. Plain HTML pages could not be used even when it wasn’t necessary to display any dynamic data on a given page, because an HTML page would not be able to pass on the username to subsequent pages.

As you can see, when your goal is to create a variable that you can use throughout your site, passing it from one page to the next is rarely a practical solution. Fortunately, ASP Web Applications were designed with just this sort of thing in mind. You’ll also recall from our last article that ASP has a number of built-in objects – Request and Response being prime examples of these. Two other objects that all ASP scripts have access to are Application and Session , and it is these special objects that let us store data that will be accessible by all ASP scripts in the current Web application.

The Application Object

Whereas every page request gets its own Request and Response objects, all requests for ASP pages in a Web application share the same Application object. This object is created the first time an ASP page is requested from the application after the Web server starts up, and is destroyed when the Web server shuts down, or when the Web application is unloaded manually in the IIS management console. Because this object persists from one page request to another, it can be used to store data that you want to share with all other pages in your application.

To store a value in the application object, simply use the following syntax:

You can then access that stored value as you would a regular variable, except as Application(«varName») . A simple use of the Application object would be for a hit counter. You could record the number of hits your Website has received as Application(«hits») , and increment that value with each page request. Here’s the basic code involved:

Line 8 adds 1 to the value of Application(«hits») , and line 9 then prints out the updated value. Save the above code in an ASP file (e.g. counter.asp ) in your application directory, and then load it repeatedly into your browser (e.g. http://localhost/myapp/counter.asp ). Watch as the count increases by 1 with each page request. By including this code fragment on each page of your site, you can count the total number of page requests, as all of your pages will share the same Application(«hits») value.

While the above method of value storage and retrieval represents the way you’ll use the Application object 90% of the time, this object does have a few more methods you should be aware of.

First of all, Application(«hits») is actually just a shortcut. The hits variable is actually a member of a collection called Contents , which is a property of Applications . Thus, the longhand version is Application.Contents(«hits») . There’s no reason for you to use this longer version when accessing stored values, but you must use it when you remove a stored value from the application. To do this, call the Remove method of the Contents collection, as follows:

This code would delete the «hits» stored value from the application. To remove all stored values from the application, you can use the RemoveAll method:

To understand the purpose of the remaining two methods of the Application object, Lock and Unlock , we must first take a close look at Line 8 from the hit counter example above:

As you can see, this line actually accesses the stored application value twice. The first time (on the right of the equals sign), it retrieves the stored value. Then, after adding 1 to the retrieved value, it accesses the stored value a second time (on the left of the equals sign) to record the updated value over the top of the existing value.

What’s important to understand is that the three steps described above do not necessarily occur as an uninterrupted sequence of events. If two Web browsers were to access your site at the same time, the events for each browser could intermingle, producing a sequence like this:

  • browser 1 reads «hit»
  • browser 2 reads «hit»
  • browser 1 stores «hit + 1»
  • browser 2 stores «hit + 1»

    If you look at this sequence closely, you’ll realize that the two hits that should have been recorded only resulted in an increase of 1 to the stored «hit» value! To avoid this happening, your code should «lock» the Application object before undertaking a series of events like this that should occur in an uninterrupted sequence. Thus, Line 8 above should be replaced with these three lines:

    The call to Application.Lock on Line 8 waits for any other processes to finish accessing the Application object, before locking access to it. This forces other clients to wait until the call to Application.Unlock on Line 10 before they can read or write the stored values again. This effectively prevents the occurrence of mix-ups like the one above, as ‘browser 2’ would have to wait for ‘browser 1’ to read and then store its updated value before it could read the value and update it itself.

    The Session Object

    The Session object is very similar to the Application object, as it allows you to store values that are shared between all the pages of your site. The main difference between the two is that, where a single Application object is shared by all pages and all clients that access your site, each client (browser) is assigned its own Session object.

    Thus, a Session object must be created for each user session that occurs on your Website. Here’s an updated version of the hit counter example we saw in the previous section:

    Save this page and open two copies of your Web browser. It’s important that you actually launch your browser application twice – opening it once and then opening a new window will make the two windows part of the same session, whereas actually opening two separate copies of your browser will cause them each to be assigned separate Session objects on your server. Load the above page into both browsers, and refresh it a few times in each. Observe that the counter stored in the Session object only counts the hits from each browser, while the counter stored in the Application object stores the total page request count.

    A typical use of the Session object is to store a user’s shopping cart on an online shopping site. Obviously it doesn’t make sense for all your users to share a single shopping cart, so the fact that each user gets a Session object of his or her own fits the bill precisely.

    As for the Application object, Session(«hits») is actually just shorthand for Session.Contents(«hits») . Session.Contents.Remove(«hits») can be used to delete a single stored value, while Session.Contents.RemoveAll will delete all values stored in the current session.

    Every user that connects to your site is assigned his or her own Session object for the duration of his or her visit, so there must be some mechanism in place to prevent old Session objects from adding up and consuming all the memory on your server. By default, a Session object will expire and be deleted from your server if the client that corresponds to that session doesn’t request a page from your server for 10 minutes. In most cases, this means that the user has closed the browser or has moved on to another Website. If your application has a typical ‘time between page requests’ of more than 10 minutes, this default timeout value will prevent your application from working properly. To specify your own session timeout interval, set the Timeout property of the Session object:

    You can also end the current session immediately, for instance, if you wanted to ‘log out’ the current user from your Web application:

    The global.asa File

    This is the basic structure of a global.asa file. Let’s say, just for fun, that we wanted to start the count of our global (Application) hit counter at 1000. The code for the /Application_OnStart section (lines 2-4) might look like this:

    In a more practical example, you might use Application_OnEnd to save the current hit count into a text file when the server is shut down, and Application_OnStart to load that value when the server starts up again.

    Putting it All Together

    To demonstrate the use of Application, Session, and global.asa together in a single system, let’s create a more practical and interesting version of the example we saw last time. In this example, users were prompted for their name, and were then welcomed by a personalized message at the top of each page they visited. This time, we’ll use the Session object to track each user’s name, instead of having to code every link on our site to pass the variable onto the next page. We’ll also use the Application object to track the number of users on our site (and how many of those have given us their name).

    To start, create a new global.asa file with the following contents:

    When a user leaves the site, and their session times out after the requisite 5 minutes’ inactivity, we again Lock the Application in preparation for the changes we’re about to make, and decrease the user count by 1. Next, we check the length of the string that’s stored in Session(«name») with the help of the built-in Len() function. If the string is longer than zero characters (i.e. «»), we know that the user has logged in by providing a name, so we also decrease the namedUsers count by 1.

    Now we need to create a sample page on our site. Name the file default.asp and type the following code:

    The magic is in the tags. As there’ll be a significant chunk of code involved in handling both the login process, and in displaying the tally of users, and since this is something we’ll presumably want to handle on every page of our site, we’re going to place the code for each of these functions in separate files ( login.asp and welcome.asp respectively). This means we’ll only have to type this code once in order to have all pages on our site share the same code. This tag basically inserts the contents of the specified file at the location of the tag, before the ASP code in the file is processed.

    So our next task, obviously, is to create the login.asp and welcome.asp files. We’ll start with welcome.asp :

    We start by checking the length of the Session(«name») variable to see if the user has logged in. If they have, we display the message /»Logged in as: name«. Otherwise, we display «Not logged in», followed by a link for the user to log in. The code for this link may seem a little complicated at first, but bear with me as I explain it.

    That’s all there is to welcome.asp ; now here’s login.asp :

    First, we catch page requests that result from the user clicking the «Log In» link generated by welcome.asp above. As we saw in the previous article, we spot this by checking if Request.QueryString(«login»).Count is greater than zero. When such a request is found, we display a simple page that prompts the user for his or her name. The form submits to Request.ServerVariables(«SCRIPT_NAME») , so our next task in this script is to process submissions of this form, which will be marked by Request.Form(«name»).Count greater than zero:

    This code begins by taking the name submitted in the form ( Request.Form(«name») ) and storing it in Session(«name») . Then we Lock the Application and increase the number of named users by 1. Finally, we redirect the user to the page that was originally requested.

    With all these files in place, load default.asp (e.g. http://localhost/myapp/default.asp ) in a few instances of your browser, and you should see the system in action!

    Summary

    In this article we explored the primary mechanisms provided by ASP to support persistent data. With the Application object, we can store data values that are shared by all pages and all users on our site, such as the simple hit counter that we looked at. The Session object, meanwhile, gives the power to associate persistent data with each active user on our site. In our final example, we used this to store the name of each user and display it at the top of each page.

    In a public Web forum, this stored value could save the user from having to type his or her name to post a message. Used in combination with a database that stored a list of authorized users and their passwords, the system we developed in this article could be expanded to act as an access control system.

    In the next article in this series, we’ll look at how ASP interfaces with a relational database such as Microsoft Access. This very powerful combination of ASP with a backend database is what drives many of the hottest sites on the Internet today.

    Объектная модель ASP.NET

    ASP.NET является объектно-ориентированной моделью разработки Web-приложений. Сами ASP.NET-страницы являются объектами классов. Можно создавать программный код с возможностью его повторного использования классами. Эти классы можно использовать для создания экземпляров объектов.

    Объектная модель — это иерархия объектов, предоставляющих разработчикам определенные возможности. В ASP.NET используется новая структура Web-страниц, которая отличается от структуры ASP-страниц и обеспечивает поддержку объектной модели для сохранения содержимого ASP.NET-страницы. Добавлен новый класс элементов управления — серверные элементы управления. Можно добавлять собственные комментарии и связывать эти данные с серверными элементами управления. Для оформления Web-страниц имеются наборы директив, которые предназначены для установки параметров. Например, параметры TraceContext и isEnabled позволяют, соответственно, включить и отключить механизм отслеживания Web-запросов.

    ASP.NET определяет шесть внутренних объектов структуры страниц:

    Эти объекты встроены в модель ASP.NET-страниц и готовы к использованию.

    В объекте application хранятся данные, которые будут доступны всем пользователям, одновременно работающим с Web-приложением.

    Данные о сеансе работы каждого отдельного пользователя сохраняет объект session. Объект application используется для хранения глобальных переменных, которые содержат информацию, общедоступную для всех пользователей Web-приложения, например, приветственное сообщение или индекс посещения Web-страницы. Этот объект представляет собой коллекцию разнородных элементов. Пользователи совместно используют объекты Web-приложения, поэтому требуется гарантировать, что несколько пользователей не смогут одновременно изменять переменные, хранимые в объекте application. Для блокирования содержимого коллекции объектов от изменения применяется метод Lock, для разблокирования — метод Unlock. Так же существуют методы Contents.Remove и Contents.RemoveAll, которые удаляют один элемент из семейства Contents или все сразу соответственно.

    С помощью объекта ObjectContext выполняется фиксация или откат транзакций, управляемых MTS. Транзакции могут быть инициированы со страницы ASP.NET. Методы SetComplete и SetAbort объекта ObjectContext используются, соответственно, для фиксации и отката транзакций.

    Объект response можно использовать для передачи выходной информации клиенту. Методы объекта respons:

    AddHeader — устанавливает заголовок HTML имя равным значению.

    AppendToLog — добавляет строку в конец записи журнала веб-сервера, относящейся к этому запросу.

    BinaryWrite — записывает предоставленную информацию в текущий вывод HTTP без преобразования наборов символов.

    Clear — стирает любой буферизованный вывод HTTP.

    End — останавливает обработку файла .asp и возвращает текущий результат.

    Flush — немедленно передает буферизованный вывод.

    Redirect — отправляет обозревателю сообщение о перенаправлении, вызывая попытку обозревателя подключиться к другому URL.

    Write — записывает переменную в виде строки в текущий вывод HTTP.

    Илон Маск рекомендует:  Шаблон сайта благотворительность HTML, CSS, 1 страница
  • Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL