Asp взаимодействие с клиентскими сценариями


Содержание

Доступ к клиентскому сценарию из ASP

14.12.2008, 16:52

С какой БД работать клиентскому приложению?
Здравствуйте! Есть клиентское приложение (C#), которое получает данные с сервера. Эти данные нужно.

Подключение БД к клиентскому приложению с механизмом ADO
Господа,какую нужно сделать базу данных для делфи? Смотрел видео и там нужно было подключить базу.

Доступ к данным по ip на ASP
Подскажите пожалуйста. Как сделать на ASP, чтобы проверив IP-адрес клиента народ из внутренней сети.

доступ к БД из ASP кода
Как получить доступ к БД (SQL Server) из ASP кода? Например, код обычного VB риложения для этого.

Доступ из ASP приложения к БД Oracle
Господа, я пытаюсь из приложения подключиться к Oracle DB. Мне велено использовать.

Asp взаимодействие с клиентскими сценариями

Представленная ниже страница, лишь часть огромного сайта посвященного различной компьютерной документации, на сайте собрано более 800 мб информации. Если Вы не нашли в этой статье, то что Вы ищите попробуте посмотреть здесь, cпросить на форуме или поискать необходимую Вам информацию в нашем каталоге ссылок сайтов компьтерной тематики.

Если же Вы хотите приобрести бумажную копию представленных здесь
материалов, обращайтесь в наш книжный магазин.

С уважением,
команда разработчиков eManual.ru

Азы ADO и ASP

FileArea.co.il Азы ADO и ASP
Азы ADO и ASP Майкл Оути
Листинг 1. Применение объекта ADO Соединение
Листинг 2. Использование объекта ADO Набор записей
Листинг 3. Применение объекта ADO Набор записей для вставки строк
Листинг 4. Обработка ошибок ASP и ADO Основы интерактивного WEB-дизайна

Программный продукт ASP, название которого в переводе означает Активные страницы сервера (Active Server Pages), обеспечивает написание сценариев серверной части для информационных WEB-серверов компании Microsoft, IIS (Internet Information Server). Впервые корпорация Microsoft ввела ASP в версии IIS 3.0, и продолжила дальнейшую разработку этого продукта в IIS 4.0. ASP представляет собой гибкое динамичное средство создания WEB-страниц и позволяет применять любой язык написания сценариев, удовлетворяющий стандарту ActiveX. Как правило, ASP использует комбинацию из HTML и встроенного VBScript. IIS включает в себя сервер автоматизации OLE, который исполняет VBScript и посылает результаты реализации сценария в формате HTML клиенту, который может иметь только браузер. Так как сценарии ASP выполняются на сервере, то ASP способен работать с любым WEB-браузером, поскольку браузер получает лишь поток страниц HTML. Понимание того, каким образом объекты ADO работают с ASP, и в особенности того, как лучше применять объекты ADO для поиска и модификации данных, может превратить создание динамических WEB-страниц в легкое и приятное занятие.

Как работает ASP

Рисунок 1. Обзор взаимодействия ASP и HTML
1- WEB-сервер
2- Клиент WEB
3- Активный сценарий
4- пример .ASP

На рисунке 1 изображено, как ASP комбинирует сценарий ActiveX и команды HTML для того, чтобы получить динамическую страницу HTML. Как следует из рисунка, сценарии ASP отличаются от сценариев, базирующихся на браузерах. В традиционных сценариях, основывающихся на браузерах, WEB-сервер посылает страницу HTML, содержащую сценарий ActiveX в браузер клиента, который и отвечает за выполнение сценария. Подход, при котором основной акцент делается на клиентской части приложения, возлагает на нее дополнительный груз обязанностей, что может привести к возникновению проблем, если клиентский браузер не будет в состоянии выполнить сценарий. Напротив, страницы ASP исполняются на WEB-сервере IIS. В ходе исполнения страницы сервер напрямую посылает клиенту команды HTML и все клиентские сценарии, содержащиеся на странице ASP. Но как только сервер доходит до команды серверного сценария ASP, то он исполняет этот сценарий и передает клиенту в форме HTML только полученные в качестве результата выходные данные. Клиент, действия которого сводятся к использованию браузера, не видит разницы между потоком страниц HTML, порождаемым сценарием ASP, и потоком HTML, посылаемым статичными WEB-страницами. Таким образом, написание сценариев для серверной стороны с помощью ASP создает WEB-страницы, которые выступают в качестве исполнителей сценариев. Тот факт, что ASP генерирует только поток страниц HTML, обеспечивает независимость от типа браузера клиента. В силу того, что сервер IIS интерпретирует страницы ASP «на лету», ASP служит идеальным средством для встраивания результатов обработки интерактивных запросов к базе данных в WEB-страницы. Эти возможности обеспечиваются доступом к базе данных SQL Server через ADO непосредственно со страниц ASP.

Будь то доступ из Internet или из местной сети Intranet, клиенты применяют протоколы HTTP и TCP/IP для связи с WEB- сервером IIS. Когда WEB-клиент запрашивает страницу ASP, WEB-сервер IIS сценарии, находящиеся на этой странице. Для того чтобы получить доступ к базе данных SQL Server, сценарий ASP открывает соединение с SQL Server с помощью одного из объектов Соединение, Команда или Набор записей. Затем использует этот объект для передачи в сервер запроса на доступ к данным. SQL Server может размещаться на том же компьютере, что и WEB-сервер IIS. Однако в силу того, что часто SQL Server используется одновременно сразу несколькими различными приложениями, удобнее разместить его на отдельном компьютере, и обеспечить связь с ним через локальную сеть. После того как ядро SQL Server закончит обработку запроса, оно возвращает результаты объекту ADO из сценария ASP. Затем IIS продолжает исполнять сценарий ASP и отсылает поток страниц HTML обратно клиенту. Поэтому обязательно должно существовать сетевое соединение между WEB-сервером IIS и сервером баз данных SQL Server. Кроме того, на WEB-сервере необходимо установить поставщик OLE DB и библиотеки DLL на период прогона ADO.

Использование объектов ADO на страницах ASP

При использовании ADO приложение первым делом пытается применить объекты Соединение, Команда или Набор записей для установления соединения с SQL Server. Объект Соединение следует употреблять для того, чтобы открыть соединение ADO явным образом. Объекты Команда и Набор записей позволяют сделать то же самое динамически. После установления соединения приложение ASP может выполнять команды ADO такого же типа, что и стандартное приложение, написанное на Visual Basic (VB). Эти команды включают исполнение хранимых процедур, открытие и просмотр набора записей, вставку, обновление и удаление данных.

Для подключения страницы ASP к серверу баз данных SQL Server ADO может применять поставщик OLE DB как для ODBC, так и для SQL Server. Поставщик OLE DB для ODBC позволяет использовать структуру объекта ADO с большинством существующих драйверов ODBC. Но поставщик OLE DB для SQL Server дает возможность подключиться только к SQL Server. Однако с объектами ADO Соединение, Команда и Набор записей возможно применять любой из упомянутых поставщиков. Листинг 1 (написанный на языке VBScript) показывает, как применить поставщик OLE DB для ODBC в целях установления соединения с SQL Server.

Первое действие, проводимое в листинге 1, это объявление трех переменных, которые будут содержать имя компьютера, на котором размещен SQL Server, и информации для аутентификации SQL Server. Затем сценарий декларирует переменную cn, которую он в последствии будет использовать для объекта ADO Соединение. После объявления в сценарии рабочих переменных метод Формировать (Form) объекта ASP Запрос (Request) присваивает значения всем этим переменным.

Следующим шагом метод Создать объект (CreateObject) объекта ASP Сервер (Server) создает новый объект ADO Соединение (Connection), который затем присваивается введенной ранее переменной cn. Метод Создать объект (CreateObject) способен порождать экземпляры объектов СОМ. Данный пример иллюстрирует создание экземпляра объекта Соединение ADODB (ADODB.Connection), но его можно аналогичным образом применять и для других структур объектов СОМ, например, для SQL-DMO или Active Directory. (Более подробную информацию об объектах ASP можно найти во врезке «Модель объектов ASP»).

После этого сценарий присваивает значение строки соединения OLE DB свойству Строка соединения (ConnectionString) объекта Соединение, хранящегося в переменной cn. Это позволяет установить соединение без указания имени источника данных, DSN (Data Source Name). В силу того, что спецификация поставщика OLE DB проводилась без ключевого слова PROVIDER, по умолчанию берется поставщик OLE DB для ODBC. Ключевое слово DRIVER идентифицирует тот драйвер, который предполагается применять в дальнейшем. За ключевым словом SERVER указывается имя компьютера, содержащего SQL Server, с которым намереваются установить соединение. За ключевыми словами UID и PWD содержится информация, необходимая для входа в систему. Ключевое слово DATABASE определяет, что в роли базы данных, используемой по умолчанию, будет выступать база данных pubs. После того как будет присвоено значение строки соединения свойству Строка соединения (ConnectionString) объекта Соединение (Connection), его метод Открыть (Open) установит соединение с SQL Server, удовлетворяющее всем значением параметров, заданных в сценарии.

Поиск данных с помощью объекта ADO Набор записей ()

ADO можно применять для поиска данных с помощью объектов Набор записей (Recordset) или Команда (Command). Оба эти объекта способны работать с активным объектом Соединение (Connection), или же создавать новое отдельное соединение. Каждый раз, когда объект Соединение (Connection) или Набор записей (Recordset) устанавливает соединение, начинается новая коммуникационная сессия с SQL Server. Поэтому в том случае, если приложению необходимо выполнить несколько операций, целесообразнее применить объект Соединение (Connection) для открытия связи с SQL Server. Этот объект будет использоваться объектами Команда (Command) или Набор записей (Recordset).

Листинг 2 демонстрирует применение объекта ADO Набор записей (Recordset) на странице ASP. Первая часть сценария во многом напоминает простой пример установления соединения, приведенный в листинге 1. В сценарии сначала декларируются рабочие переменные, а затем им присваиваются значения. После этого по сценарию создается объект Соединение (Connection), и вслед за ним объект ADO Набор записей (Recordset). На следующем шаге сценария строка соединения присваивается объекту ADO Соединение (Connection), и затем для установления связи с SQL Server вызывается метод Открыть (Open). В соответствии со сценарием свойству Активное соединение (ActiveConnection) объекта Набор записей (Recordset), хранящегося в переменной rs, передается значение объекта активного соединения, cn, и выполняется метод Открыть (Open) объекта Набор записей (Recordset). Первый параметр метода Открыть (Open) содержит простой оператор SQL, который выбирает все столбцы и строки из таблицы stores базы данных Pubs.

После того как сценарий возвращает результаты обработки запроса, страница ASP создает таблицу HTML, содержащую шесть столбцов. После этого по сценарию столбцы получают заголовки. Сценарий использует стандарт HTML для построения всех заголовков столбцов. Внутри тела таблицы HTML в соответствии с меткой А листинга 2 программный код VBScript организует цикл Do Until. Этот цикл обрабатывает содержимое объекта Набор записей (Recordset), находящегося в переменной rs. Когда сценарий доходит до конца объекта Набор записей (Recordset), свойство rs.EOF получает значение Истина, и цикл завершается.

Встроенный в страницу ASP сценарий присваивает значения всем столбцам исходя из имени столбца объекта ADO Набор записей (Recordset). В рассматриваемом примере имя столбца, происходящее из таблицы Stores базы данных Pubs идентифицирует каждый пункт коллекции Поля (Fields). Расположенная вслед за этим часть кода VBScript реализует метод MoveNext для перехода к следующей строке в объекте Набор записей (Recordset). Затем оператор Цикл (Loop) возвращает управление в начало цикла Do Until. Когда этот цикл прочитает последнюю строку набора записей, цикл заканчивается и объекты Набор записей (Recordset) и Соединение (Connection), хранившиеся соответственно в переменных rs и cn, закрываются. Результаты работы этой страницы ASP можно видеть на экране 1.

Экран 1. Просмотр простого объекта ADO Набор записей
Изменение данных средствами ADO

ASP и ADO можно применять не только для динамической выдачи WEB-страниц, но и в целях создания WEB-страниц для ввода данных. Такая возможность позволяет создавать основанные на WEB приложения с использованием баз данных, обладающие таким же набором функций работы с базами данных, что и стандартные приложения, разработанные в соответствии с архитектурой клиент-сервер. Объекты ADO Набор записей (Recordset), которые становятся доступными на страницах ASP, предоставляют тот же перечень услуг, что и приложения, написанные на Visual Basic. Как показывает следующий пример, их можно применять для ввода данных. Кроме того, их можно использовать для изменения или удаления данных. Все остальные возможности ADO, такие как способность запускать подготовленные заранее операторы SQL или хранимые процедуры, также имеют место.

В целях внесения изменений в данные возможности, предоставляемые ASP и ADO, можно комбинировать различными способами. К примеру, можно было бы создать страницы ASP, которые будут поддерживать изменяемые объекты ADO Набор записей (Recordset). Они, в свою очередь, смогут применять методы Добавить новый (AddNew), Обновить (Update) и Удалить (Delete) для модификации данных в базах SQL Server. Помимо этого, возможно применять ADO для выполнения как динамических,, так и подготовленных заранее с помощью языка SQL операций модификации данных. Код приведенный на листинге 3, иллюстрирует, каким образом можно было бы добавлять строки в объект Набор записей (Recordset), который создается с использованием курсора Keyset.

Листинг 3 представляет дополнительные технические приемы построения WEB-приложений с помощью ASP. Первая строка является оператором VBScript Option Explicit, который указывает, что все переменные в коде VBScript перед их применением будут явным образом продекларированы. Как и в стандартном Visual Basic, в VBScript предусмотрено автоматическое использование новых переменных, без их предварительного объявления. На первый взгляд это свойство может показаться очень удобным, но в реальности оно служит довольно эффективным способом ввести в разрабатываемое приложение ASP множество трудно находимых коварных ошибок.

Следующим шагом оператором #include вводится файл adovbs.inc. Оператор #include представляет очень удобный путь копирования обычно употребляемых констант на страницы ASP. В данном случае файл adovbs.inc включает все константы, которые обычно содержит структура объекта ADO. Подключение этого файла дает возможность записывать константы в виде adChar и adKeyset, а не в виде значений, представляемых этими константами. Применение констант делает код удобно читаемым и легким в сопровождении. Хотя включение файла является хорошим приемом для средств разработки вообще, но в случае, когда для создания ASP- приложений используется такой инструмент, как Visual InterDev (VID), можно просто добавить в среду разработки VID ссылку на объектную библиотеку ADO. Подобное добавление устраняет необходимость включения файла в ASP- приложения. Чтобы добавить ссылку на ADO в проект VID следует выбрать в меню Проект (Project) и Ссылки проекта (Project References), а затем выбрать в списке доступных ссылок библиотеку Microsoft ActiveX Data Library 2.0.

В соответствии со сценарием VBScript, приведенным на листинге 3, сначала уничтожается, а затем воссоздается заново таблица в базе данных pubs, после чего в эту таблицу вставляются 50 строк и полученное содержимое показывается на WEB-странице. Но прежде чем выполнить все это, в том месте сценария, которое отмечено в листинге 3 буквой А, инициируется обработчик ошибок VBScript. В этом примере оператор On Error применен для того, чтобы обойти любые ошибки, которые могут произойти, к примеру, при попытке удалить несуществующую таблицу из указанной базы данных. В следующем разделе будет более подробно рассмотрено использование обработчика ошибок.

На следующем шаге сценарий ставит в соответствие переменной cn объект ADO Соединение (Connection). Затем метод Исполнить (Execute) объекта Соединение (Connection) выполняет два динамических оператора SQL. Первый уничтожает таблицу Department, а второй создает таблицу Department заново. После создания таблицы Department сценарий устанавливает в свойстве Активное соединение (ActiveConnection) объекта Набор записей (Recordset), указанного в переменной rs, ссылку на этот объект Соединение (Connection). Затем метод Открыть (Open) объекта Набор записей (Recordset) создает обновляемый набор записей. Константа adOpenKeyset определяет, что этот объект будет относиться к обновляемому типу Keyset, а константа adLockOptimistic предписывает использование оптимистического типа блокировки записей.

Цикл For Next вставляет 50 строк в таблицу Department. В этом цикле метод Добавить новый элемент (AddNew) создает буфер для хранения новой строки, после чего цикл присваивает значения объектам ADO Поле (Field). Каждый объект коллекции Поле (Field) идентифицируется по названию столбца. Значение счетчика цикла присваивается столбцу Dep_Id, содержащему идентификатор отдела, а в столбец Dep_Name с названием отдела помещается литерал Department и представленный в виде символьной строки номер отдела, равный значению счетчика цикла. Цикл вставляет новую строку в базовую таблицу в ходе исполнения метода Обновить (Update) объекта Набор записей (Recordset).

После того как сценарий вставит 50 строк в таблицу Department, метод Перейти к первой () перемещает курсор в начало объекта Набор записей (Recordset). Затем содержимое объекта Набор записей (Recordset) представляется в виде таблицы HTML, применяя ту же технику, что и в описанном ранее примере с запросом. На экране 2 показана WEB- страница, которая создается при запуске данной страницы ASP.

Экран 2. Просмотр записей, введенных на страницу ASP
Обработка ошибок ASP и ADO

Очень важно перехватывать ошибки, возникающие во время работы приложения: если вдруг в результате некорректного функционирования WEB-приложения системой будет сгенерировано сообщение об ошибке, то работа WEB- приложения будет немедленно прекращена. Для того чтобы предусмотреть на странице ASP специальную часть сценария VBScript, отвечающую за обработку возникающих ошибок, применяется оператор On Error. К сожалению, оператор On Error не обладает всей полнотой возможностей обработчика ошибок VB, который позволяет перейти в отдельную секцию кода для обработки информации об ошибке. Оператор On Error, входящий в VBScript, предоставляет только следующую альтернативу: либо перейти к следующей операции (Resume Next), либо вообще отключить обработку ошибок. Этот оператор не дает возможности перейти к другим секциям кода. Оператор On Error использует структуру объекта ADO для того, чтобы поместить ошибки, возникающие во время выполнения WEB-приложения на базе страниц ASP, в коллекцию объекта ADO Ошибка (Error). Коллекцию ошибок ADO можно обрабатывать с целью сбора дополнительной информации о том, какие ошибки встречаются при эксплуатации вашего приложения. Фрагмент кода, приведенный на листинге 4, показывает, как использовать обработчик ошибок VBScript и каким образом извлекать информацию из объекта ADO Ошибка (Error).

Обработку ошибок в листинге 4 обеспечивает оператор On Error. Затем для создания локального объекта ADO Соединение (Connection) по сценарию используется объект Соединение (Connection), который хранился в объекте ASP Сессия (Session). После этого в сценарии используется метод Выполнить (Execute) объекта ADO Команда (Command) применительно к заведомо неправильному имени таблицы. Поскольку обработка ошибок разрешена, программа переходит к следующему оператору.

Проверка свойства Счетчик (Count) коллекции объектов Ошибка (Error) позволяет найти ошибки ADO. Если значение счетчика больше нуля, значит, объект ADO столкнулся с какой- либо ошибкой во время исполнения. Извлечь информацию об ошибках ADO можно путем итеративного просмотра коллекции объектов Ошибка (Error). Пример на листинге 4 использует цикл For Each для обработки элементов коллекции ошибок объекта ADO Соединение (Connection). Свойства Номер(), Источник () и Описание () становятся доступными в форме текстов HTML. Экран 3 представляет страницу с результатами обработки ошибок. (Обратите внимание на то, что рассмотренный пример является не более чем демонстрацией подхода. В реальном приложении необходимо обрабатывать условия возникновения ошибок в коде приложения. При этом следует избегать вывода ошибок на браузер конечного пользователя).


Экран 3. Обработка ошибок ASP с помощью ADO

В том случае, когда на WEB-страницу должны выводиться только статичные данные, целесообразно применять Мастер WEB-приложений (), входящий в состав SQL Server. Он поможет легко и быстро преобразовать информацию базы данных SQL Server к виду WEB-страницы формата HTML. Если же необходимо создать по-настоящему интерактивное приложение, способное динамически представлять и обновлять данные, лучше всего применять комбинацию ASP и ADO, что позволит подключить вашу базу данных SQL Server к сети WEB. Использование ADO и ASP дает возможность создавать WEB-приложения, обладающие теми же функциями, что и их предшественники, выполненные в соответствии с традиционной архитектурой клиент-сервер.

В основу этой статьи лег адаптированный материал из книги Майкла Оути и Поля Конте «Руководство по разработке для SQL Server 7.0».

Майк Оути (mikeo@teca.com) работает старшим техническим редактором в журналах SQL Server Magazine и Windows NT и является президентом компании ТЕСА. Эта компания занимается разработкой программного обеспечения и консалтингом; находится в Портленде, штат Орегон.

Модель объектов ASP

Информационный сервер Интернет, IIS (Internet Information Server), разработанный корпорацией Microsoft, вводит Активные серверные страницы, ASP (Active Server Pages), в качестве автоматического сервера OLE, обладающего иерархической структурой объекта. На рисунке А представлена модель объекта ASP. Первичным объектом в программной модели ASP является объект Контекст сценария (ScriptingContext), который обеспечивает взаимодействие с браузером клиента. Поскольку объект Контекст сценария (ScriptingContext) всегда доступен приложениям ASP, то нет необходимости в явном виде делать на него ссылку. Объект Контекст сценария (ScriptingContext) содержит шесть основных объектов ASP: пять встроенных объектов и объект Контекст объекта (ObjectContext). К пяти встроенным объектам относятся: объект Приложение (Application), объект Запрос (Request), объект Сервер (Server), объект Сессия (Session) и объект Отклик (Response).

Все активные WEB-сессии применяют объект Приложение (Application) для того, чтобы все пользователи могли одновременно обращаться к информации приложения ASP. Объект Приложение (Application) включает две коллекции: Содержание (Context) и Статические объекты (StaticObjects). Каждый объект Содержание (Context) соответствует какому- либо пункту, для включения которого в WEB-приложение были использованы команды ActiveX. Коллекция Статические объекты (StaticObjects) содержит все объекты, для включения которых в WEB-приложение применялись ярлыки HTML . Кроме того, объект Приложение (Application) может также содержать определяемые пользователем объекты, которые были созданы этим WEB-приложением и предназначены для коллективного применения.

Объект Запрос (Request) получает запросы от клиентов сети WEB. Объект Запрос (Request) может вместить всю информацию содержащуюся в форме, плюс сведения о текущем пользователе. Этот объект включает несколько коллекций, каждая из которых представляет различные информационные наборы, которые могут возвращаться клиентам WEB в ответ на их запросы. Каждый объект Сертификат клиента (ClientCertificate) в одноименной коллекции представляет поле сертификата, которое возвращает клиент сети WEB и которое в дальнейшем служит его идентификатором. Коллекция (Cookies) состоит из элементов, каждый из которых содержит немного информации о пользователе WEB. Коллекция Формы (Forms) включает набор объектов, каждый из которых представляет какую-нибудь форму HTML. Коллекция Строка запроса (QueryString) содержит набор добавляемых аргументов URL, а коллекция Переменные сервера (ServerVariables) представляет собой набор переменных, описывающих серверное окружение.

Объект Сервер (Server) применяется для создания объектов OLE, которые было бы желательно иметь в WEB-приложении. Например, метод Создать объект (CreateObject) объекта Сервер (Server) генерирует объекты Соединение (Connection) и Набор записей (Recordset), обеспечивающих доступ к базам данных SQL Server.

Объект Сессия (Session) поддерживает информацию, относящуюся к текущей сессии в сети WEB. Объект Сессия (Session) во многом похож на объект Приложение (Application), но имеет отличие от него. В то время как объект Приложение (Application) принадлежит всем пользователям сети WEB, объект Сессия (Session) относится только к текущей сессии. Коллекция объектов Содержание (Context) объекта Сессия (Session) включает все пункты, которые добавлялись в WEB-сессию с помощью команд сценария. Объект Контекст объекта (ObjectContext) обеспечивает доступ к контексту текущего объекта. Как правило, он порождает экземпляры объектов MTS или контролирует транзакции базы данных.

Объект Отклик (Response) записывает информацию в виде потока страниц HTML и отсылает ее в браузер клиента. Объект Отклик (Response) также поддерживает коллекцию, состоящую из объектов, содержащих сведения, которые могут быть записаны в систему клиента. Они в последствии могут быть прочитаны объектом Запрос (Request).

Рисунок А. Модель объектов ASP
1 — Контекст сценария
2 — Приложение
3 — Содержание
4 — Статические объекты
5 — Определяемые пользователем объекты
6 — Контекст объекта
7 — Запрос
8 — Формы
9 — Строка запроса
11 — Сервер
12 — Сессия
13 — Отклик

Клиентские сценарии JavaScript

Язык программирования JavaScript и его предназначение для создания интерактивных HTML-документов. Объектно-ориентированный язык разработки встраиваемых приложений, выполняющихся на стороне клиента и на стороне сервера. Назначение клиентских сценариев.

Рубрика Программирование, компьютеры и кибернетика
Вид реферат
Язык русский
Дата добавления 28.02.2020
Размер файла 18,9 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

АНПОО «Региональный открытый социальный техникум»

по дисциплине «Web-программирование»

на тему: «Клиентские сценарии JavaScript«

Выполнил: Петрухин Н.В.

Преподаватель: Середа Т.В.

Сценариями JavaScript называются программы, работающие с объектами HTML-документа. Параметры элементов документа, заданные с помощью атрибутов соответствующих тегов и таблиц стилей, можно изменить или даже заменить весь загруженный HTML-документ на другой. Сделать это можно с помощью сценариев JavaScript и представляющими их объектами. программирование клиентский интерактивный

Окну браузера соответствует объект window, а HTML-документу, загруженному в окно — объект document. Эти объекты содержат в своем составе другие объекты. Объект document входит в состав объекта window. Элементам HTML-документа соответствуют объекты, которые входят в состав объекта document. Все множество объектов имеет иерархическую структуру, называемою объектной моделью. Объект представляет собой контейнер для хранения информации. Он характеризуется свойствами, методами и событиями, на которые может реагировать.

Понятие языка JavaScript

Язык программирования JavaScript предназначен для создания интерактивных HTML-документов. Это объектно-ориентированный язык разработки встраиваемых приложений, выполняющихся как на стороне клиента, так и на стороне сервера. Синтаксис языка похож на синтаксис языка Java — поэтому его часто называют Java-подобным. Клиентские приложения выполняются браузером просмотра Web-документов на машине пользователя, серверные приложения выполняются на сервере.

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

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

Назначение клиентских сценариев JavaScript

Назначение клиентских сценариев JavaScript:

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

2. Создание динамических HTML-страниц совместно с каскадными таблицами стилей и объектной моделью документа.

3. Взаимодействие с пользователем при решении «локальных» задач, решаемых приложением JavaScript, встроенном в HTML-страницу. В частности, сценарии JavaScript широко применяются для создания различных визуальных эффектов. Например, изменение внешнего вида элементов управления, над которыми установлен курсор мыши, анимация графических изображений, создание звуковых эффектов и т. д. Механизм локальной памяти Cookie позволяет сценариям JavaScript сохранять на компьютере локальную информацию, введенную пользователем. Например, в Cookie может храниться список товаров из Интернет-магазина, отобранных для покупки.

Приложение JavaScript представляет набор операторов языка, последовательно обрабатываемых встроенным в браузер интерпретатором.

Способы включения сценариев JavaScript в HTML-страницу

Встроить сценарий JavaScript в HTML-страницу можно несколькими способами:

1. Задать операторы языка внутри тэга-контейнера языка HTML. Браузеры, не поддерживающие какие-либо тэги HTML, их игнорируют, анализируя содержимое пропускаемых тэгов с точки зрения синтаксиса HTML. Это может приводить к ошибкам при отображении страницы. Поэтому операторы языка JavaScript помещаются в контейнер комментария :

Символы (//) перед закрывающим тэгом комментария являются оператором комментария JavaScript. Он необходим для правильной работы интерпретатора. Документ может содержать несколько тэгов обязательно, независимо от того, заданы или нет операторы внутри тэга. Связываемый внешний файл не должен содержать тэгов HTML и должен иметь расширение.js:

3. Использовать выражения JavaScript в качестве значений параметров тэгов HTML. Эта процедура аналогична процедуре встраивания числовых или символьных примитивов HTML. Элементы JavaScript также располагаются между амперсандом (&) и точкой с запятой (;), но должны заключаться в фигурные скобки < >и использоваться только в качестве значений параметров тэгов HTML. Нельзя использовать элементы JavaScript в тексте HTML. Они интерпретируются только тогда, когда расположены справа от параметра и задают его значение. Пусть определена переменная barwidth, и ей присвоено значение 75. Следующий тэг нарисует горизонтальную линию длиной в 75% от горизонтального размера окна браузера:


4. Определить обработчик событий в тэге HTML. Для совместимости с языками сценариев в некоторые тэги HTML были введены специальные параметры обработки возникающих событий. Значениями этих параметров могут быть операторы языка JavaScript. Обычно в качестве значения задается имя функции, которая вызывается, когда происходит соответствующее событие, определяемое параметром обработки события. Имя параметра начинается с приставки on, за которым следует имя самого события. Например, параметр обработки события click будет иметь имя onClick. События в основном связаны с действиями, производимыми пользователем с элементами форм HTML. Поэтому чаще всего перехват и обработка событий задается в параметрах элементов форм, что позволяет проверить введенную информацию перед ее отправкой на обработку. Функция или процедура это именованная последовательность операторов, которая выполняет определенную задачу и может возвращать некоторое значение. Функция в JavaScript определяется оператором function, имеющем следующий синтаксис:

function имя_функции ([параметры]) <

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

Пример задания функции и ее вызова в процессе формирования документа:

Начинается отображение страницы, в которую внедрен сценарий вычисления функции

Валидация на стороне клиента

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

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

ASP.NET MVC включает поддержку библиотеки JQuery Validate для осуществления валидации на стороне клиента. Еще одна новая особенность MVC – поддержка ненавязчивой валидации на стороне клиента. Она соотносит элементы ввода с атрибутами данных, которые используются в скриптах. В ASP.NET MVC 2 валидация на стороне клиента была навязчивой, то есть специальный скрипт связывался с элементами ввода в процессе рендеринга.

В этом пункте мы изучим новые функции валидации на стороне клиента в ASP.NET MVC. Для начала рассмотрим простой пример, а затем разберем два способа модификации: использование RemoteAttribute и создание пользовательских валидаторов JQuery.

Включение валидации на стороне клиента

Чтобы начать работу с валидацией на стороне клиента, необходимо добавить в наши страницы скрипты jQuery Validate. Добавим их в макет страницы.

Так как каждая новая библиотека JavaScript опирается на другие, важно, чтобы файлы были включены в правильном порядке. Сначала мы регистрируем библиотеку JQuery, затем – плагин Validate и вспомогательные скрипты для ненавязчивой валидации.

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

Методы EnableClientValidation и EnableUnobtrusiveJavaScript просто включают флаги в ViewContext . Чтобы скрипты подключились корректно, они должны быть размещены перед методом BeginForm .

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

Эти метаданные обрабатываются библиотекой JavaScript jquery.unobtrusive и включаются в логику проверки плагина JQuery Validate.

Установив пользовательские валидаторы, проверим валидацию на стороне клиента и отправим форму с пустым полем для названия компании. В результате она не отправляет запрос на сервер, что показано на рисунке 6-4.

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

Рисунок 6-4: Валидация на стороне клиента

Использование RemoteAttribute

В ASP.NET MVC 3 появился новый атрибут валидации — RemoteAttribute . Если включить его в свойство модели, jQuery Validate будет отправлять HTTP-запрос к определенному методу действия для осуществления проверки на стороне сервера. Результат будет пересылаться обратно клиенту, и сообщение об ошибке будет выводиться еще до отправки формы. Это хороший способ обеспечить быструю обратную связь для сценариев, которым необходима обработка на стороне сервера.

Строка 4: Применение RemoteAttribute к свойству модели

Этот атрибут указывает, какой контроллер и какое действие должен вызвать клиентский скрипт, а также содержит сообщение об ошибке. После того, как пользователь изменит значение в элементе ввода, клиентский скрипт отправить имя элемента и значение к методу действия. Имя параметра действия должно совпадать с именем элемента ввода.

Это действие проверяет, является ли число четным и возвращает булево значение в JsonResult . Булево значение указывает на результат валидации — естественно, true означает, что валидация прошла успешно. Этот атрибут можно использовать очень широко – для поиска соответствий допустимых значений в базе данных или выполнения сложных сценариев. Если возможно отправлять несколько HTTP-запросов во время заполнения формы, RemoteAttribute — это отличный способ сделать интерфейс более быстрым и удобным. Если из-за запросов снизится производительность, можно использовать пользовательские валидаторы на стороне клиента.

Создание пользовательских клиентских валидаторов

Когда атрибут валидации поддерживает интерфейс IClientValidatable , DataAnnotationsModelMetadataProvider (и любые производные от него, такие как наш ConventionProvider ) передаст платформе инструкцию генерировать атрибуты данных для связанных HTML-элементов. Используя этот механизм, мы можем настроить валидацию на стороне клиента с помощью собственного JavaScript кода. Он эффективен для отдельных сценариев, когда валидаторов библиотеки JQuery Validate недостаточно.

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

Метод получает в качестве параметра метаданные модели, так что мы можем определить правило для конкретного свойства модели, которое мы проверяем. В этом примере мы включим отформатированное отображаемое имя в сообщение об ошибке. Для максимальной расширяемости, метод возвращает интерфейс IEnumerable , и то, что он возвращает только одно правило, имеет смысл. Таким образом, именно тот атрибут валидации, который выполняет проверку хронологии дат на стороне сервера, будет реализовывать этот интерфейс. Реализация показана в следующем листинге.

Листинг 6-3: Реализация IClientValidatable

Строки 6-7: Составление сообщения об ошибке

Строка 8: Тип валидации соответствует валидатору JQuery

Строки 10-11: Добавление параметра, который будет передан в валидатор

ModelClientValidationRule — это простой класс, который имеет три свойства. ErrorMessage будет отображаться в случае сбоя валидации, ValidationType — это имя валидатора (к которому мы обратимся на следующем этапе), а ValidationParameters представляет собой таблицу IDictionary с параметрами, которые мы можем передавать клиентскому скрипту. В листинге 6-3 мы используем отображаемое имя свойства в сообщении об ошибке (строки 6-7). Тип валидации — » later » — имя JQuery валидатора, который мы запишем следующим (строка 8). Мы также добавляем к списку параметров имя otherDateProperty , с которым будем проводить сравнение (строки 10-11). Звездочка в имени свойства нужна, чтобы мы могли найти правильное свойство в крайнем случае, если этот HTML-элемент будет представлен в иерархической форме, которая выводит список содержащей модели.

С помощью IClientValidatable ASP.NET MVC представит правильные атрибуты для ненавязчивой валидации на стороне клиента, используя JQuery Validate. Теперь осталось два этапа: написать валидатор JQuery Validate и добавить в него атрибуты ненавязчивой валидации.

Мы написали упрощенный код JavaScript для добавления валидатора, который будет проверять, что одна дата более поздняя, чем другая. Чтобы провести сравнение, он использует объект JavaScript Date . Value – это значение элемента ввода, который мы проверяем, а параметр params — другой элемент ввода, который мы определили в атрибуте валидации:

Интересно то, как все элементы взаимосвязаны. Это показано в следующем листинге.

Листинг 6-4: Пользовательский адаптер

Использование AJAX в ASP.NET

История развития web-приложений

Рассматривая ту или иную новую технологию прежде всего необходимо разобраться для чего эта самая технология необходима и что именно она позволяет (или облегчает) делать, что не позволяют делать другие технологии. Чтобы более наглядно понять, какие предпосылки были к появлению AJAX, можно рассмотреть процесс эволюционного развития web-сайтов.


На самой заре развития интернет сайты представляли собой набор простых статических страниц – пользователь запрашивал ресурс у сервера и сервер возвращал статическую страницу. Эта страница представляла собой простой HTML текст и хранилась как текстовый файл на сервере. Данная страница поставлялась пользователю as is и, кроме того, не имела никаких клиентских скриптов.

Первая попытка сделать страницы более динамичными был Common Gateway Interface (CGI). CGI позволял разработчику создавать исполняемые программы, которые генерировали страницу, что позволяло принимать параметры от пользователя. С учетом этих параметров можно было генерировать уникальную страницу. По большому счету, данный подход используется и сейчас в том же ASP.NET, PHP и т.д.

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

Апплеты и Flash

В случае, если запрос к серверу все же необходим и одними клиентскими скриптами не обойтись – разработчики в web-страницах стали использовать т.н. апплеты а также flash.

Апплеты впервые были использованы в 1995 году, когда Sun представила миру на всеобщее обозрение свою новую платформу с новым языком – JAVA. По сути апплеты представляли собой программы, написанные на JAVA и которые могли запускаться в броузере как отдельные приложения. Для того, чтобы эта программа, написанная на неведомом для броузера языке JAVA, могла быть запущена внутри броузера, необходимо было установить JVM (Java Virtual Machine) – среду для выполнения программ JAVA. И хотя данный подход звучит очень заманчиво – он имел множество недостатков, прежде всего это проблемы безопасности (не каждый пользователь, путешествуя по интернет, разрешит запускать на своем компьютере программы непонятного происхождения) и необходимость громозкой VM. Несмотря на то, что помимо общения с сервером апплеты и флеш также позволяли реализовать возможности, недоступные JavaScript (скажем, более высокие требования к графике) – те сложности не дали апплетам прижиться настолько, чтобы окончательно решить проблемы с запросами к серверу.

Dynamic HTML объединил в себе HTML, каскадные таблицы стилей (CSS) и JavaScript. Также ко всему этому набору добавился DOM – объектная модель броузера. Вся эта смесь позволяла (и позволяет) успешно создавать очень красивые, удобные и функциональные страницы «на лету». Но опять же, в случае, если нужно выполнить запрос к серверу – приходится перегружать весь документ.

Решение этой проблемы пришло с появлением новой технологии, которая в 2004 году была названа AJAX (Asynchronous JavaScript + XML). Данная технология построена на принципе выполнения запроса к серверу с использованием JavaScript и получению результата опять же, с помощью JavaScript, что позволяет избежать перегрузки страницы и следовательно имеет несколько неоспоримых преимуществ:

1. На сервер отправляются не все элементы страницы (точнее не их значения), а только те минимальные данные, которые необходимы для выполнения того или иного запроса и в ответ принимается не вся страница, а только необходимые данные, что позволяет уменьшить трафик в десятки (а иногда и в сотни) раз.
2. Не происходит перегрузка страницы в броузере и у пользователя создается впечатление, что все происходит на его компьютере.

Об этой технологии и пойдет дальше речь.
Объектная модель броузера.

Если вы меня спросите на чем основан принцип работы технологии AJAX, то я вам наверное отвечу : «благодаря объектной модели броузера». Что же это за такая объектная модель броузера (DOM)?

Document Object Model (DOM) – это спецификация, стандартизированная W3C комитетом, которая является кроссплатформенной и описывает вызовы и описания, касающиеся действиям с самим документом, его структурой, HTML, XML и стилями. Как следует из названия, основой спецификации DOM являются объекты.

Этот объект появился впервые в Internet Explorer 5.0 и был реализован как ActiveX компонент. Важно заметить, что этот объект не является стандартом W3C, хотя многое из его функциональности описано в спецификации «The DOM Level 3 Load and Save Specification». По этой причине его поведение может немного отличаться в различных броузерах. Но во всех броузерах он выполняет одну и ту же функциональность – он умеет посылать запросы к серверу и получать от него ответы. Как уже говорилось выше, данный объект не стандартизирован и создание его instance может отличаться в различных версиях, поэтому для «надежного» его создания лучше использовать код, который объединяет в себе создание instance в нескольких броузерах подобно коду ниже:

XMLHttpRequest имеет ряд «стандартных» (стандартных в кавычках т.к. как писалось выше, данный объект не стандартизирован для всех броузеров) свойств и методов, которые позволяют данному объекту посылать запрос, проверять состояние запроса и получать результат выполнения запроса от удаленного сервера. Эти свойства и методы мы рассмотрим в следующих двух таблицах.

В таблице 1 представлены «стандартные» свойства XMLHttpRequest

Прерывает текущий запрос

Возвращает все заголовки Response в виде ключ/значение

Возвращает значение определенного заголовка

open(method, url, asynch, username, password)

Устанавливает состояние запроса к серверу. Первый параметр указывает метод запроса – PUT, GET, POST, второй – url запроса, третий (необязательный) – тип запроса (синхронный или асинхронный), четвертый и пятый (также необязательные) – для защищенных страниц

Посылает запрос серверу

Устанавливает значение определенного заголовка. Перед вызовом этого метода необходимо вызвать метод open

Также XMLHttpRequest содержит ряд свойств, которые представлены ниже:

Обработчик события, которое возникает при каждой смене состояния запроса

Состояние запроса. Доступны следующие значения: 0 – запрос неинициализирован, 1 – загрузка, 2 – загрузка окончена, 3 – interactive, 4 — complete

Ответ от сервера в виде строки

Ответ от сервера в XML. Этот объект может быть обработан и проверен как DOM

Код статуса HTML.(например 200 – OK)

Название кода статуса HTML

Бегло проглянув эти методы, несложно понять, какие методы достаточно вызвать, чтобы с помощью JavaScript получить какие-либо с сервера.

Прежде всего напишем серверную часть, которая будет возвращать простую строку. Для этого (чтобы не было «посторонних» данных вроде тегов открытия закрытия html) наиболее рационально будет создать hanlder. Открываем web-проект в Visual Studio 2005 и создаем файл типа Handler. Содержимое будет примерно следующим:

Т.е. при запросе данной страницы этот hanlder возвращает text/plain документ с единственной строчкой “Hello World”. Нас такой handler устраивает как нельзя лучше.

Теперь создадим обычную HTML – страницу, которая будет и выполнять запрос, используя XMLHttpRequest.

Данный код довольно прост. При нажатии на кнопку “Start Asynchronous Request” вызывается клиентская функция startRequest, которая в свою очередь сначала вызывает рассмотренную нами ранее функцию createXMLHttpRequest для создания объекта XMLHttpRequest, после чего цепляет обработчик (клиентскую функцию handleStateChange) на событие ReadyStateChange для этого объекта, открывает и посылает запрос. Если запрашиваемая страница доступна и данные были получены, status меняет свое состояние на 200. Поэтому в функции handleStateChange мы проверяем значение этого свойства. При нужном значении мы с помощью alert выводим полученное значение. Пробуем как это работает:

В данном несложном коде по сути заложена вся фукциональность AJAX – получение данных от сервера без перегрузки страницы. Понимания этого механизма достаточно, чтобы понять суть AJAX, а также успешно использовать его в своих приложениях. Далее только дело техники и далее мы рассмотрим реализацию всего этого, но с использованием ASP.NET J
Использование AJAX в ASP.NET
Обратные вызовы страницы.

Обратные вызовы – это специальный вид возврата формы, т.е. страница проходит свой цикл событий, но данные формы возвращаются клиенту до начала процесса рендеринга формы, т.е. до перерисовки. Как и в любом AJAX исполнении запрос начинается на клиентской стороне в результате возникновения какого-либо события, при этом запускается клиентская встроенная функция под названием WebForm_DoCallback. Эта функция имеет следующий прототип:

pageID – ID страницы, которая выполняет вызов,

argument – строковый аргумент, передаваемый серверу,

returnCallback – клиентская функция или клиентский скрипт, который должен выполниться после того, как серверная сторона вернет управление

context – данные, которые передаются returnCallback.

errorCallback – клиентская функция или клиентский скрипт, выполняемый при возникновении ошибок


useAsync – устанавливает, будет ли запрос синхронным или асинхронным.

Следующий этап – серверная страница должна знать, что она должна поддерживать обратные вызовы (т.е. прежде всего возвращать данные до начала рендеринга страницы). Для этого эта страница должна реализовывать интерфейс System.Web.UI.IcallbackEventHandler.

Данный интерфейс содержит 2 метода:

Выполнение обратного вызова на серверной стороне состоит из 2-х этапов: подготовка и возвращение результата. Метод RaiseCallbackEvent вызывается первым и предназначен для подготовки удаленного выполнения кода. Метод GetCallbackResult выполняется позже, когда результат уже готов к отправке. Данное разделение было введено только в release версии .NET 2.0, в предыдущих версиях эти 2 методы были объединены в один (это было сделано с учетом асинхронной работы). Метод GetCallbackResult возвращает string, поэтому возвращаемые данные должны быть сериализированы тем или иным методом в строку, а на клиенте наоборот, десериализированы.

При запросе страницы с клиентского скрипта сначала выполняется Init, после чего стандартный цикл событий загрузки страницы до события Load, в Load свойство IsCallback устанавливается в true, по завершению Load выполняются методы интерфейса ICallbackEventHandler, после чего как уже говорилось выше выполнение прерывается, не переходя в стадию рендеринга. Прежде всего это говорит о том, что не происходит стадия сохранения ViewState, так что пытаться что-либо сохранить в ViewState стандартным способом бесполезно (оно и понятно, т.к. ViewState страницы не обновляется). Управляет процессом взаимодействия между страницей и сервером т.н. диспетчер обратных вызовов. Диспетчер обратных вызовов имеет в себе библиотеку клиентских сценариев. Эти клиентские сценарии формируют и отправляют запрос, получают и разбирают ответ от сервера и т.д. Посмотрев View Source любой из страниц можно увидеть строки вроде

Скачав файл, который возвращает данный обработчик WebResource.axd с указанными параметрами, можно углубиться в изучения клиентских скриптов, которые отвечают за указанные выше действия J

Написание клиентского метода WebForm_DoCallback не является чем-либо сложным, однако связано с некоторыми трудностями в случае динамического генерирования или передачей параметров. Для этого в класс Page.ClientScript (System.Web.UI.ClientScriptManager) введен специальный метод – GetCallbackEventReference, который получает ряд параметров и, подобно например методу GetPostBackEventReference, генерирует соответствующий клиентский код. Я бы не сказал, что этот метод очень изящный, особенно когда необходимо передать параметры в клиенский скрипт (особенно наличие одинарных и двойных кавычек в контатенирующейся строке портит всю картину), но все поудобнее, чем в лоб писать WebForm_DoCallback.

Данный метод имеет следующий прототип:

target – страница или WebControl, который будет обрабатывать обратный вызов. Соответственно, эта страница или контрол должны реализовать интерфейс ICallbackEventHandler, иначе будет брошено исключение:

System.InvalidOperationException: The target ‘__Page’ for the callback could not be found or did not implement ICallbackEventHandler.

Генерует первый параметр функции WebForm_DoCallback

argument – аргумент, передаваемый клиентской функции или скрипту. Соответствует второму параметру функции WebForm_DoCallback.

returnCallback – клиентская функция или клиентский скрипт, который должен выполниться после того, как серверная сторона вернет управление (3-й параметр WebForm_DoCallback)

context – данные, которые передаются клиентской returnCallback (4-й параметр WebForm_DoCallback).

errorCallback – клиентская функция или клиентский скрипт, выполняемый при возникновении ошибок (5-й параметр WebForm_DoCallback)

useAsync – устанавливает, будет ли запрос синхронным или асинхронным (6-й параметр WebForm_DoCallback).

Теперь мы можем создать нашу первую aspx страницу с использованием ajax. Допустим, довольно частая задача – есть 2 выпадающих списка – в одном из них данные более высокого уровня, нежели во втором. Т.е. при выборе значения в первом списке – второй список перегружается в зависимости от выбранного значения в первом. Например – первый SELECT содержит список производителей машин, второй – модели машин, которые выбранный производитель выпускает. Для решения этой задачи можно конечно загрузить все данные в javascript, а потом скриптом перебиндивать второй select. В нашем случае это в принципе подошло бы, но есть несколько минусов – первый это то, что данных может быть очень много (допустим, 100 производителей и для каждого из них указаны все модели, когда либо выпускавшиеся, т.е. может быть более 100. Итого грузить несколько десятков тысяч итемов в javascript не есть лучший вариант). Кроме того, прийдется писать не такой уж и простой яваскрипт. Плюс может быть ситуация, когда данные должны быть интерактивными.

Попробуем решить это с помощью AJAX.

Для этого создаем обычную ASPX страницу:

После чего реализуем интерфейс ICallbackEventHandler для класса страницы:

Нам необходимо получить eventArgument в методе RaiseCallbackEvent, сделать соответствующие действия и потом передать его в GetCallbackResult для возврата клиенту. Для этого мы вводим переменную evArg.

Далее нам необходимо прицепить клиентский обработчик для первого SELECT. Т.е. при смене значения должна вызываться функция WebForm_DoCallback. Так и пишем J

Теперь напишем 2 метода, первый из которых нужен только один раз – для binding списка производителей, а второй — для списка моделей. Чтобы не мучаться с БД сделаем попроще следующим образом:

И следовательно для того, чтобы заполнить список производителей, необходимо добавить в Page_Load:

Теперь осталось сделать 2 вещи – написать клиентскую функцию, которая будет выполняться после возврата и написать код для функций RaiseCallbackEvent и GetCallbackResult.

Сначала напишем код для этих 2-х функций:

Значение параметра eventArgument функции RaiseCallbackEvent заносим во внутреннюю переменную evArg (это значение выбранного производителя), а в GetCallbackResult перебиндив список моделей в эту же переменную заносим все значения моделей для данного производителя, разделив их например «;» (этакий способ сериализации).

Далее напишем клиентскую функцию CallbackFunction. Данная функция должна очищать SELECT для моделей и, получив строковое значение от GetCallbackResult, десериализировать это значение и заполнить SELECT новыми значениями.

Вот в принципе и всё. Данный пример конечно далеко не совершенен (например, не учтена обработка ошибок), но вполне работоспособен. Вы можете убедиться в этом, открыв данную страницу:

Чтобы облегчить жизнь простому программисту при работе с AJAX и избавить его от необходимости вникать в подробности взаимодействия клиента с сервером – Microsoft разработала библиотеку, содержащую ряд компонентов, использующих AJAX. Для большинства случаев при использовании этих компонентов даже нет необходимости знать принципы работы AJAX. Компоненты ATLAS размещаются на aspx-странице подобно пользовательским компонентам (по сути ими же и являясь), так что программирование с их использованием ничем принципиально не отличается от программирования с использованием пользовательских компонентов. Microsoft постоянно обновляет этот список, поэтому я бы советовал почаще посещать web-сайт http://atlas.asp.net для обновления текущей используемой версии на более новую (кроме того, промежуточные версии новых ATLAS-контролов или более ранних контролов, но с исправленными ошибками можно взять с сайта: … ).

Для того, чтобы добавить в свой проект ATLAS компоненты нужно во-первых убедиться, что ATLAS установлен на вашем компьютере, в противном случае его установить. После чего можно либо создать проект типа “ATLAS” Web Site, либо добавить ссылку на библиотеку. Во втором случае необходимо настроить также web.config на использование ATLAS вручную.

На момент написания статьи ATLAS включал в себя 21 контрол, некоторые из которых используются довольно часто, другие же лично я кроме как в тестовых приложениях нигде не использовал. Контрол CascadingDropDown является ATLAS реализацией того, что мы написали выше J Наиболее широкоиспользуемый и универсальный, на мой взгляд, это контрол UpdatePanel – это панель (на клиенте она преобразуется в div элемент), которую можно перегрузить не перегружая страницу, причем она может содержать другие контролы. UpdatePanel состоит из 2-х частей – ContentTemplate и Triggers. ContentTemplate представляет собой область содержимого ContentTemplate (т.е. как я уже говорил, оно может быть из других ASP.NET контролов, тегов HTML и просто текста). Triggers содержит список триггеров для данной UpdatePanel. Триггер – это как-бы обработчик события, по которому данная UpdatePanel должна обновляться. Триггеры бывают 2-х типов – ControlEventTrigger и ControlValueTrigger. Первый из них реагирует на события контрола (например, контролом является Button и перехватываемым событием событие Click), второй – на изменение свойства (например изменение значения Text для контрола TextBox). Например, следующий код:

Будет обновлять значение Label по нажатию кнопки с использованием AJAX. Обратите внимание, что данный код практически ничем не отличается от «классического» ASP.NET кода. Переместив Label из UpdatePanel – мы получим «классический» вариант : была нажата кнопка – произведен запрос к серверу – страница прошла полный цикл загрузки страницы – обновлено значение элемента Label – страница возвращена клиенту. Это позволяет легко адаптировать под использование ATLAS и наоборот. Однако есть еще одна строчка в коде, на которую вы наверное не обратили внимание – это ScriptManager в заголовке страницы. Данный элемент добавляет в возвращаемую клиенту страницу все необходимые для ATLAS клиентские скрипты и этот элемент является обязательным (и в единственном экземпляре на странице) в случае использования ATLAS. Также хочу предупредить, что в случае использования ControlValueTrigger необходимо на проверяемый контрол AutoPostBack=»true», иначе он просто не будет срабатывать. Для того, чтобы укрепить свои знания и попробовать использование ATLAS на практике -создадим простейший чат. Но в нашем чате будет одна особенность – он будет использовать AJAX технологию и благодаря этому он будет интерактивным. В чатах прежних времен приходилось либо время от времени (например каждые 20 сек) перегружать всю страницу – при этом сразу всплывало несколько крупных недостатков:

1. (и самый большой) если пользователь набирал текст и в этот момент подходило время перегрузки – пользователь терял фокус ввода и соответственно ту часть сообщения, которую он уже набрал
2. перегрузка заставляла пользователя ждать, пока страница будет загружена и соответственно ему приходилось лицезреть на белую страницу с индикатором загрузки внизу
3. перегрузку нельзя было сделать слишком частой, т.к. помимо самого текста приходилось скачивать также все атрибуты страницы – картинки, логотипы, баннеры, разметку HTML

Для борьбы с этим явлением стали использовать фреймы, что позволяло перегружать только один фрейм, при этом пользователь не терял фокус и не приходилось загружать часть страницы, что находится вне данного фрейма. Однако недостатки как перегружаемый фрейм с белым фоном и резметка HTML все равно остались, плюс к ним добавились недостатки использования самих фреймов. Использование AJAX позволяет полностью избавиться от всех этих недостатков – данные передаются только те, которые нужно, а именно только текст (без разметки HTML – разметка устанавливается javascript’ом) и в оптимальном варианте только НОВЫЕ сообщения (при этом старые по мере надобности удаляются также javascript’ом). Таким образом снижение трафика в сотни, а то и тысячи, раз позволяет уменьшить время между запросами вплоть до нескольких секунд. При этом пользователь не видит процесса загрузки – ему кажется, что все происходит на его машине.

Создание такого чата с учетом всех возможностей AJAX я предоставлю читателю, а вот с использованием компонента ATLAS – UpdatePanel – мы создадим сейчас.

В данном примере триггер для UpdatePanel висит на кнопку btn, т.е. UpdatePanel будет обновляться только в случае нажатия на эту кнопку. Нам же необходимо чтобы UpdatePanel обновлялся также через определенные промежутки времени. Нет стандартных способов заставить обновляться UpdatePanel с помощью javascript. Я делаю это следующим образом:

1. На форму добавляю еще одну кнопку и делаю её невидимой.

2. Создаю следующий javascript:

3. В UpdatePanel добавляю триггер для этой кнопки:

Также нужно прописать в — EnableEventVal


4. А также в тег body: onload=»setInterval(‘UpdatingPanel()’, 3000);»

Как это работает – клиентская функция UpdatingPanel грубо говоря имитирует нажатие на кнопку btnUpdate. Т.к. в UpdatePanel есть триггер для этой кнопки – то вызов этой клиенской функции вызовет обновление UpdatePanel. Нам остается только вызывать эту клиентскую функцию через определенные промежутки времени, что мы и делаем в body.

В результате у нас получился следующий код :

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

Клиентская отладка сценариев в ASP.NET.

Каждый из нас хорошо знает проблемы, связанные при отладке кода сценария на стороне клиента. Эта статья рассказывает о различных новых методах и советах по устранению неполадок, которые помогают эффективно сделать отладку кода сценария на стороне клиента в Visual Studio 2005. Сценарий клиентского кода означает, что он может быть VB Script или J # скрипт или Java-скрипт.

Клиентский сценарий вложен в ASPX страницу. HTML-файлы или внутрь . JS файлов. Вообще, сценарий на стороне клиента загружается из клиентского приложения,такого как Internet Explorer, работающего на локальном компьютере.
Есть два способа, в которых можно отлаживать сценарии на стороне клиента в Visual Studio 2005. К ним относятся:
Visual Studio. NET IDE
Microsoft Script Editor
Настройка машины для отладки клиентских сценариев
Прежде чем мы начнём отлаживать код сценария на стороне клиента,нужно сделать некоторые настройки :
Включить клиентскую отладку сценариев в Internet Explorer. Для этого перейдите в меню Сервис -> Свойства обозревателя и на вкладке Дополнительно убедитесь, что отладка сценариев отключена.

Включить отладку сценариев в IE.

Visual Studio. NET IDE
Теперь вы можете сделать отладку кода сценария на стороне клиента непосредственно в среде Visual Studio 2005. Это стало возможным благодаря мощной отладке, которая позволяют отлаживать управляемый код, код сценария, T-SQL код и машинный код. Visual Studio 2005 поддерживает 64-разрядные отладки локально или удаленно. Теперь вы можете сделать отладку сценариев Java размещённых в IE. Отладчик Visual Studio предоставляет расширенные функции, такие как советы по новым данным, визуализаторы, которые позволяют просматривать содержание комплексных переменных и типы данных. Давайте посмотрим, новые возможности на примере проекта Visual Studio 2005.
Мы создаём веб-приложение ASP.NET и используем Java Script для обработки результатов.
Открыть Visual Studio 2005 Окружающая среда и в меню Файл проект с открытым образцом для этого учебника.
Нажмите клавишу F5 (Начать отладку), чтобы начать отладку. В IEXPLORE.EXE прилагается автоматический отладчик. Мы используем IE для загрузки сценариев так как они прилагаются в IEXPLORE.EXE.

Листинг функции JavaScript показывает, включенные в образец страницы ASP.NET. Вы всегда должны включать ключевое слово «Debugger » в качестве первой строки кода сценария Java 5если вы хотите использовать для отладки Visual Studio 2005. Это ключевое слово автоматически вызывает отладчик Visual Studio на стороне клиента.Как только мы запускаем указанный код выше, мы получаем выход смотрите на скриншоте ниже.

Выход листинга приветствия программы.
Вернуться в Visual Studio Чистая окружающая среда и нажмите кнопку Отладка -> Другие окна-> Script Explorer и установите точки останова в желаемом месте.
Снова вернуться к IE. Дайте значения имя и фамилию и нажмите кнопку приветствие. Вы можете увидеть управление возвращается в сценарий Explorer, как показано ниже в листинге. Используйте клавишу F10, чтобы перешагнуть через каждую строку кода. Кроме того, можете использовать клавишу F11, чтобы войти в каждую строку кода. В сценарии Explorer, вы можете установить новые точки останова и использовать местные Окна для проверки значения локальных переменных в сценарии. Immediate Window оценивает значения переменных.
Чтобы вызвать немедленно окно нажмите Debug-> Windows-> Интерпретация. Аналогично окна вызываются через кнопку Отладка-> Windows-> Локальные

Сценарий Explorer в действии.
Вы можете также использовать команду Window для выполнения команды сценария кода переменных, таких как команда Debug.Print. Чтобы вызвать окно команды нажмите кнопку-> Вид-> Other Windows-> Окно «Команда». Также доступен ряд других функций, таких как строение окна, окна стека вызова. Вы можете наблюдать в окне команд ниже в листинге.

Microsoft Script Editor.

Microsoft Script Editor (MSE) является мощным инструментом, который предназначен для отладки Java-скриптов, используя Internet Explorer в качестве сервера сценариев. Он поставляется как бесплатный компонент Office XP и Office 2003. Это привлекательный вариант, когда всё, что вам нужно, для отладки Java-скриптов для IE и у вас нет Visual Studio. NET установленного на вашей машине.Это Вы можете проверить на МФБ на вашей машине, нажав кнопку Просмотр опции IE и посмотреть, можете ли Вы найти вариант отладчика сценария.
Давайте использовать тот же пример, чтобы продемонстрировать отладку кода скрипта на стороне клиента используя MSE.
Переход на том же примере, откройте страницу в Internet Explorer и нажмите кнопку Открыть, как показано ниже в листинге.

IE с MSE .

После нажатия кнопки Open можно увидеть диалоговое окно Just-In-Time Debugger.

Нажмите Да для использования МФБ и вы можете увидеть ниже перечисленные диалоговые окна.

Нажмите кнопку ОК и вы можете видеть окружающую среду Microsoft Script Editor который открывает MSE и предлагает почти такой же вариант, как IDE Visual studio.Net и другие аналогичные характеристики, как местные окна и окно команд. Вы можете использовать те же клавиши F10, чтобы перешагнуть через код.

Microsoft Script Editor IDE.

Кроме того, вы также можете использовать положение линии, как это сделано в сценарии Java. Debugger, отладчика ключевого слова,который будет создавать точки останова. Когда этот рубеж запущен, ваш МФБ начнёт выполнять коамнду и вы увидите сообщение об ошибке «необработанное исключение» в сценарии Сценарий Breakpoint .

Just-In-Time Debugger.

Выберите Да и остальные действия такие же, как описано в первом методе работы с ММП. Управление передается Script Editor IDE.

Microsoft Script Editor IDE.

В итоге вы получаете после успешной отладки это сообщение в качестве вывода.

Когда вы закончили отладку убедитесь, что браузер не ждёт отладку. Просто нажмите F5, чтобы продолжить или же явно закрыть отладчик. Нажмите кнопку «Да», когда он предлагает закрыть отладчик. Таким образом, вы можете пердотвратить компьютер от зависания. (Это случилось со мной!) При использовании MSE.
Встроенный отладчик Visual Studio 2005 является очень мощным и богатым возможностями. Теперь вы можете сделать отладку кода сценария на стороне клиента с той же гибкостью, которую вы использовали отладку кода на стороне сервера. Вы можете сказать до свидания неуклюжим оповещениям , занятых в отладке сценариев Java. Microsoft Script Editor является еще одним привлекательным вариантом для отладки,имеющим не меньше возможностей по сравнению с отладчиком Visual Studio 2005.

Применение AJAX в веб-приложениях с помощью ScriptManager (исходники)

Cегодня посетитель веб-сайта может участвовать в пополнении его контента и в выборе направленности и даже разделять успех с владельцем. Сайты социальных сетей, блоги, фотогалереи в Интернете и вики-страницы — вот лишь несколько примеров веб-сайтов нового стиля, число которых растет с каждым днем; и все это только начало. Сайт может предлагать лучший контент, но, если препятствовать участию пользователей в его развитии, он быстро станет бесполезным.

Обязанность разработчика заключается в применении имеющихся средств для удовлетворения потребностей среднестатистического потребителя. Начинать работы по повышению притягательности сайта логично с самого веб-браузера как части сайта, ближайшей к потребителю. Увы, эффективно задействовать многочисленные функции, предоставляемые современными веб-браузерами, не всегда легко. Написание кода, взаимодействующего с браузером, требует значительных усилий, так как уйма возможных комбинаций браузеров и операционных систем сильно осложняет реализацию. Единая платформа для параллельного создания функциональных клиентских и веб-приложений могла бы помочь этому, устраняя необходимость дублирования усилий в каждой комбинации «ОС-браузер».

Microsoft выпустила ASP.NET AJAX как ответ на потребность в такой платформе при разработке веб-приложений. Задачей данной статьи является расширение знаний читателей об элементе управления ScriptManager — центральном компоненте ASP.NET AJAX — и демонстрация способов его применения для профессионального программирования. ScriptManager — серверный элемент управления, расположенный на веб-форме и обеспечивающую базовую функциональность ASP.NET AJAX. Его основная задача — управление остальными элементами ASP.NET AJAX в веб-форме и добавление нужных библиотек сценариев в веб-браузер для поддержки клиентской части ASP.NET AJAX. ScriptManager часто используется для регистрации прочих элементов управления, веб-сервисов и клиентских сценариев.

ScriptManager (как серверный элемент управления) реагирует на события в жизненном цикле страницы ASP.NET и использует эти события для координации работы всех элементов управления, параметров и кода ASP.NET AJAX. ScriptManager подключается к конкретному событию, получает уведомление, когда происходит это событие, и настраивает ряд параметров в зависимости от среды; этот процесс повторяется несколько раз на протяжении цикла рендеринга страницы ASP.NET.

Сначала я перечислю некоторые из основных средств ASP.NET AJAX, доступных через ScriptManager, после чего перейду к исследованию жизненного цикла этого элемента управления на сервере. Понимание внутренних механизмов ScriptManager позволит оценить по достоинству предоставляемые им возможности для разработки веб-приложений и научиться использовать их в полной мере.

Начнем со сценариев как центральной части ASP.NET AJAX. По сути, вся функциональность ASP.NET AJAX зависит от соответствующих библиотек сценариев. Затем я опишу некоторые средства поддержки AJAX, способы взаимодействия с веб-сервисами и, наконец, кратко расскажу об аутентификации. При обсуждении каждой темы я покажу, как изменять параметры через ScriptManager.

Написание сценариев с помощью ScriptManager

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

  1. Зарегистрировать пространство имен в ASP.NET AJAX.
  2. Создать метод-конструктор.
  3. Создать прототип класса.
  4. Зарегистрировать класс в ASP.NET AJAX.
  5. Уведомить клиентский сценарий, добавленный ScriptManager, о конце определения типа (вызвать Sys.Application.notifyScriptLoaded).

Листинг 1. Определение класса в ASP.NET AJAX

Данный класс предоставляет свою функциональность только клиенту. Однако с помощью элемента управления ScriptManager можно использовать гораздо более интересные возможности создания сценариев в ASP.NET AJAX, позволяющие предоставлять функции созданного класса как JavaScript-сценарию на клиентской стороне, так и коду Microsoft .NET Framework на сервере. Например, если потребитель вашего элемента управления установит свойство экземпляра следующим образом:

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

Заметьте: я использую одно и то же имя MyCustomButton как ссылку на элемент управления и на сервере, и на клиенте; я также работаю со свойством AlertMessage, как если бы его значение без проблем пересекало границу между сервером и клиентом. Это кажется естественным, но до появления ASP.NET AJAX единая модель программирования сервера и клиента была труднодоступна и потребовала бы написания изрядного объема кода. Теперь эта унифицированная парадигма «сервер-клиент» интегрирована и полностью поддерживается в ASP.NET AJAX.

Тесная интеграция сервера и клиента обеспечивается двумя новыми интерфейсами: IScriptControl и IExtenderControl. Для использования этих интерфейсов унаследуйте ваш веб-элемент управления ASP.NET от них, примените требуемые методы интерфейса и зарегистрируйте элемент управления при помощи элемента управления ScriptManager страницы. Например, следующий каркас кода серверного элемента управления использует методы IScriptControl:


Взгляните на код сценария. Он выполняет несколько действий. Во-первых, регистрируется на событие pageLoading через клиентский класс PageRequestManager. Во-вторых, реализует для этого события обработчик PageLoadingHandler. В-третьих, получает набор элементов данных «имя-значение» из второго параметра (args). Наконец, извлекает нужное вам значение, передавая предоставленное имя элемента управления в качестве первого аргумента метода RegisterDataItem на сервере.

Веб-сервисы и ScriptManager

Легкость, с которой теперь можно асинхронно взаимодействовать с веб-сервисами из сценария в ASP.NET AJAX и обрабатывать ответы (включая ошибки), открывает широкие возможности в создании полезных и уникальных страниц. В каждой точке — от браузера до сервера — ASP.NET AJAX позволяет использовать новейшие технологии современного Интернета интуитивно понятными способами.

Элемент управления ScriptManager играет роль своего рода глобального регистратора всех сервисов, необходимых вам в приложении ASP.NET AJAX. На рис. 4 показано меню свойств для ScriptManager в том виде, в каком оно отображается в Visual Studio.

Рис. 4. Свойства ScriptManager

Вероятно, вы заметили, что я выделил подсветкой набор Scripts; под ним находится набор Services (веб-сервисы). Любые сервисы, которые должны взаимодействовать с вашим клиентским кодом, нужно зарегистрировать через ScriptManager. Чтобы добавить ссылку на сервис в элемент управления ScriptManager, просто разверните набор Services и добавьте ссылку, как показано на рис. 5 .

Рис. 5. Добавление ссылки на веб-сервис

Что именно при этом происходит? Все подробности скоро будут изложены, но при просмотре исходного кода для страницы, ссылающейся на сервис через ScriptManager, можно заметить нечто подобное приведенному ниже:

Эта внешняя ссылка была добавлена ScriptManager в вывод страницы, поскольку с ее помощью зарегистрирован веб-сервис. Заметьте, что к имени веб-сервиса добавлен префикс /jsdebug; если бы это была рабочая сборка, к имени был бы добавлен лишь префикс /js. Когда конвейер ASP.NET AJAX видит запрос к данному сервису с добавленным /js, он возвращает класс сценария, обертывающий методы веб-сервиса (это называется прокси-сценарием). Тело каждого метода в этом классе прокси-сценария выполняет асинхронный вызов соответствующего метода веб-сервиса. Следовательно, для вызова методов веб-сервиса достаточно вызвать соответствующий метод в классе сценария, созданном для вас инфраструктурой веб-сервисов в ASP.NET AJAX. Это действительно настолько просто.

Например, если сервис с именем WebService предоставляет метод Add примерно так:

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

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

Запрос к веб-сервису отправляется и результат принимается асинхронно, так что конечный результат аналогичен использованию элемента управления UpdatePanels. Содержимое можно обновить с помощью данных, полученных от веб-сервиса, не вызывая при этом полной обратной передачи. В приведенном ранее примере кода я асинхронно обновил Label1, используя результаты вызова веб-сервиса, направленного веб-методу Add. Конечный результат может выглядеть примерно так, как показано на рис. 6 . При этом полной обратной передачи не произойдет.

Рис. 6. Обновленная метка

Аутентификация и персонализация

Дополнительные возможности ASP.NET AJAX вроде аутентификации и персонализации также используют веб-сервисы. Служба аутентификации ASP.NET AJAX реализует два метода: один для входа пользователя в систему и второй для выхода пользователя из системы:

ASP.NET AJAX использует аутентификацию на основе форм, т. е. пользователю разрешается вход, когда веб-сервер передает браузеру допустимый cookie аутентификации на основе форм. Способ вставки данных из cookie в сеанс в ASP.NET AJAX идентичен полной обратной передаче, так что физически между этими механизмами нет разницы. После того как cookie включен в сеанс браузера, клиент проходит аутентификацию на сервере и может просматривать страницы и контент с ограниченным доступом.

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

Операции, необходимые для включения аутентификации в приложениях AJAX, хорошо документированы (см. ajax.asp.net), так что нет нужды рассказывать о них здесь. Но, как несложно заметить, после включения аутентификация на основе форм легко реализуется через сценарий.

Если стандартная служба аутентификации ASP.NET вас не устраивает, вы можете создать собственную и зарегистрировать ее с помощью элемента управления ScriptManager. Методы, требуемые веб-сервисом, который реализует функциональность аутентификации, показаны ниже:

Реализовав этот код, вы должны зарегистрировать новую службу аутентификации через ScriptManager. После регистрации любой код, ранее взаимодействовавший на клиенте с используемой по умолчанию службой аутентификации ASP.NET AJAX, начнет использовать новую службу вместо нее. Следовательно, со стороны клиентского сценария не потребуется изменений для работы с новым веб-сервисом аутентификации.

Ниже приведен пример декларативной регистрации службы аутентификации с помощью ScriptManager:

Не углубляясь пока в детали реализации, вы можете при работе с ASP.NET AJAX использовать преимущества собственных служб профилей. Службу профилей можно зарегистрировать через ScriptManager точно так же, как и службу аутентификации. Службы профилей позволяют подстроить веб-сайт под конкретного пользователя. Поскольку это делается из клиентского сценария, результаты будут интуитивно понятны пользователю и не вызовут затруднений. Примеры см. по ссылке ajax.asp.net.

Как все это работает

Жизненный цикл элемента управления ScriptManager делится на два основных этапа. На первом происходит проверка среды на предмет способности поддерживать все богатые возможности ASP.NET AJAX и установка любых компонентов, необходимых для такой поддержки. На втором этапе элемент управления осуществляет асинхронное взаимодействие с кодом на клиентском компьютере, позволяя сценарию выполнить необходимые обновления страницы. Поскольку этот элемент управления находится на серверной стороне, а веб-программирование в ASP.NET основано на событиях, главная функциональность ScriptManager — регистрация на события и реакция на них. Схема событий, на которые реагирует этот элемент, показана на рис. 7 .

Рис. 7. Основные события ScriptManager

Регистрация объектов с помощью ScriptManager

С помощью ScriptManager можно декларативно добавлять ссылки на сценарии и сервисы. То же самое можно делать и программным способом, через свойства Services и Scripts в элементе управления ScriptManager. Кроме того, можно посылать специальные данные клиенту и создавать элементы управления для работы с ScriptManager в качестве особых элементов управления «сценарии» (script controls). Все эти средства требуют ссылки на объект с помощью ScriptManager.

Что именно ScriptManager делает со всеми этими ссылками? Когда страница, на которой размещены элемент управления ScriptManager и функциональность ASP.NET AJAX, впервые запрашивается браузером, на стадии инициализации дочерних элементов управления этой страницы запускается принадлежащий ScriptManager метод OnInit. Он выполняет ряд важных действий, в том числе проверяет, находится ли на странице только один элемент управления ScriptManager и не выполняет ли страница в данный момент частичную обратную передачу. Однако наиболее важная операция в OnInit — регистрация на серию событий, создаваемых страницей, таких как InitComplete, PreRenderComplete и PreRender. Элементу управления ScriptManager нужно знать, когда эти события происходят на родительской странице, поскольку ASP.NET AJAX работает, используя такие события страницы.

Наиболее важным для загрузки сценариев и ссылок на сервисы в браузер является событие PreRenderComplete. Обработчик этого события называется OnPagePreRenderComplete ( лист. 4 ) и является методом самого элемента управления ScriptManager.

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

На данном этапе регистрируются все ваши сценарии и сервисы, но что это означает на практике? Как регистрация сценария или ссылки отражается на странице?

Помните, что пока происходит только обработка первого запроса страницы, так что беспокоиться о частичных обратных передачах не приходится. В силу этого можно по-прежнему использовать ClientScriptManager для регистрации сценариев. RegisterScripts, например, перебирает все сценарии, которые были зарегистрированы с помощью ScriptManager, и передает их экземпляру ClientScriptManager, отведенному для этой страницы по умолчанию. После обработки страницы будет вызван ClientScriptManager, и ссылки на сценарии будут добавлены к выводу страницы точно так же, как это делалось до появления ASP.NET AJAX.

RegisterScripts будет вызван и в ходе асинхронной обратной передачи (из-за раздела else, показанного на лист. 4 ). Этот метод по-прежнему обращается к ClientScriptManager, но, поскольку тот не умеет работать с асинхронной обратной передачей, при этом ничего не произойдет. Вместо этого RegisterScripts вызовет внутренний метод RegisterScriptIncludeInternal, который сохранит ссылку на сценарий во внутреннем массиве для последующего использования.

Листинг 4. Обработчик OnPagePreRenderComplete в ScriptManager

А как насчет ссылок на веб-сервисы? Следует вспомнить, что при добавлении ссылки на веб-сервис к элементу управления ScriptManager в сценарий добавляется ссылка. Эта ссылка заставит браузер сделать запрос по указанному URL. Инфраструктура ASP.NET AJAX проверит класс, применяющий вышеупомянутый веб-сервис, и вернет класс прокси-сценария, который можно использовать из клиентского кода. Браузер загрузит этот автоматически созданный класс прокси, который и станет ссылкой на веб-сервис.

Чтобы создать ссылку в сценарии на автоматически создаваемый класс прокси, RegisterScripts перебирает все имеющиеся ссылки на веб-сервисы и в конечном счете вызывает следующий метод:

Ссылка в сценарии, созданная GetProxyPath, будет добавлена на страницу точно так же, как и обычные ссылки — использованием ClientScriptManager для первого запроса страницы и сохранения ссылки в некоем внутреннем массиве.

Что представляет собой этот внутренний массив? На самом деле это несколько массивов. Вспомним, что при первом запросе страницы ScriptManager полагается на традиционное добавление ссылок в класс ClientScriptManager для данной страницы. Но ClientScriptManager не работает при частичной обратной передаче. Вместо этого метода ScriptManager должен переключиться на какой-то другой, и внутренние массивы предназначены как раз для этого. Ответ на частичную обратную передачу, как можно видеть, представляет собой синтаксически правильный, легко анализируемый блок данных, который проверяется и используется клиентской инфраструктурой. Вызывается событие Render элемента управления ScriptManager, что в свою очередь приводит к вызову метода ProcessScriptRegistration класса PageRequestManager ( лист. 5 ).

Листинг 5. Метод ProcessScriptRegistration класса PageRequestManager

Именно на этом этапе ссылка сценария будет преобразована в вывод страницы для ASP.NET AJAX. Каждый метод получает HtmlTextWriter, переданный ему для этапа рендеринга, и записывает в него необходимый контент. И каждый метод (например, RenderActiveScripts) будет ссылаться на соответствующий ему внутренний массив, заполненный ранее.


AJAX в ASP.NET

При помощи прокси отладчика Fiddler HTTP (fiddlertool.com/fiddler) можно отследить весь веб-трафик, проходящий через браузер Internet Explorer на вашем компьютере. Откройте примеры AJAX на ajax.asp.net и посмотрите в Fiddler, что происходит; вы увидите, что при каждом событии частичной обратной передачи выдается HTTP POST. Данный HTTP POST содержит обычные HTTP-заголовки, но включает и один заголовок, известный далеко не всем:

Этот заголовок является ключом. После того как ScriptManager распознает этот заголовок, вместо пассивной вставки ссылок в вывод страницы, он анализирует данные, переданные в виде POST, и возвращает ответ клиенту в формате, понятном клиентскому сценарию.

Помимо записи ссылок на сервисы и ссылок сценариев в первоначальный вывод страницы, элемент управления ScriptManager также может инициализировать клиентскую функциональность. При первой обработке ScriptManager обеспечивает регистрацию двух стартовых сценариев в ClientScriptManager. Один из сценариев вызывает метод, инициализирующий исполняющую среду на клиентской стороне. Другой инициализирует клиентскую версию класса PageRequestManager, о которой я уже говорил. Для понимания AJAX наиболее важен второй сценарий — тот, который инициализирует PageRequestManager.

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

Заметьте, что в страницу записываются идентификаторы UpdatePanels, PostBackControl и AsyncPostBackControl; все это элементы управления, которые должны участвовать в работе ASP.NET AJAX. Клиентский PageRequestManager отвечает за отслеживание всех событий, созданных элементами управления, зарегистрированными с помощью ScriptManager; метод RenderPageRequestManagerScript инициализирует PageRequestManager, работающий на клиенте с теми элементами управления, за которыми он должен наблюдать.

Когда на клиенте запускается событие обратной передачи, PageRequestManager проверяет, было ли оно вызвано одним из элементов управления, идентифицируемых сценарием, записанным в RenderPageRequestManagerScript. Если да, PageRequestManager отменяет событие обратной передачи и заново упаковывает его данные. Эти данные события обратной передачи будут потом переданы на сервер через клиентский класс Sys.Net.WebRequest (открытый класс, который можно использовать из клиентского кода). В запросе POST, отправляемом на сервер через Sys.Net.WebRequest, будет установлен заголовок x-microsoftajax: Delta=true.

На серверной стороне теперь создан и загружен в дерево элементов управления страницы экземпляр элемента управления ScriptManager. Как серверный элемент управления, ScriptManager будет уведомляться о данных в форме POST через LoadPostData — ASP.NET-метод, позволяющий отдельным элементам управления выбирать из формы POST относящиеся к ним данные. (Это стандартное событие, не уникальное для ASP.NET AJAX.) Диаграмма событий на рис. 10 показывает, что событие LoadPostData происходит сразу после InitComplete на странице. Внутри обработчика LoadPostData элемент управления ScriptManager определяет элементы управления, породившие форму POST (включая UpdatePanel, в котором находится элемент управления, если таковой есть). Идентификатор элемента управления, вызвавшего событие обратной передачи, сохраняется для последующего использования.

К этому моменту ScriptManager обнаруживает, что происходит частичная обратная передача, и определяет вызвавшие ее элементы управления. Теперь можно создать ответ клиенту. ScriptManager полностью переписывает метод Render, используемый по умолчанию страницей, на которой размещен этот элемент управления, беря на себя рендеринг страницы ASP.NET. Следует отметить, что до сих пор ScriptManager использовался как простое средство для изменения различных параметров в приложении ASP.NET AJAX. Теперь вы наконец можете убедиться, что ScriptManager фактически становится новым классом страницы со своим форматом рендеринга элементов управления в поток вывода страницы.

К этому моменту ScriptManager обнаруживает, что происходит частичная обратная передача, и определяет вызвавшие ее элементы управления. Теперь можно создать ответ клиенту. ScriptManager полностью переписывает метод Render, используемый по умолчанию страницей, на которой размещен этот элемент управления, беря на себя рендеринг страницы ASP.NET. Следует отметить, что до сих пор ScriptManager использовался как простое средство для изменения различных параметров в приложении ASP.NET AJAX. Теперь вы наконец можете убедиться, что ScriptManager фактически становится новым классом страницы со своим форматом рендеринга элементов управления в поток вывода страницы.

Также стоит отметить, что в переопределении рендеринга объектов Form элемент ScriptManager обрабатывает и отправляет клиенту все дополнительные данные, зарегистрированные вами в этом элементе вызовом RegisterDataItem. Поэтому важно быть готовым отправить эти данные клиенту к моменту, когда от объекта Form потребуется рендеринг на клиенте. Данные, предназначенные для отсылки клиенту, будут закодированы в неструктурированном формате или в формате JSON (JavaScript Object Notation).

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

Следуйте сценарию

ASP.NET AJAX — технология с большими возможностями. Как демонстрирует данная статья, чтобы задействовать всю функциональность ASP.NET AJAX в ваших веб-приложениях, нужно пользоваться элементом управления ScriptManager.

ScriptManager обрабатывает за вас многие детали реализации ASP.NET AJAX. Надеюсь, мне удалось показать, что присутствие ScriptManager часто требуется там, где действия, выполняемые по умолчанию элементом управления, скажем UpdatePanel, не вполне отвечают текущей задаче. В дополнение к средствам создания сценариев и AJAX элемент управления ScriptManager поддерживает и такие функции, как аутентификация и персонализация.

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

Доступ к клиентскому сценарию из ASP

14.12.2008, 16:52

С какой БД работать клиентскому приложению?
Здравствуйте! Есть клиентское приложение (C#), которое получает данные с сервера. Эти данные нужно.

Подключение БД к клиентскому приложению с механизмом ADO
Господа,какую нужно сделать базу данных для делфи? Смотрел видео и там нужно было подключить базу.

Доступ к данным по ip на ASP
Подскажите пожалуйста. Как сделать на ASP, чтобы проверив IP-адрес клиента народ из внутренней сети.

доступ к БД из ASP кода
Как получить доступ к БД (SQL Server) из ASP кода? Например, код обычного VB риложения для этого.

Доступ из ASP приложения к БД Oracle
Господа, я пытаюсь из приложения подключиться к Oracle DB. Мне велено использовать.

On-line игры: взаимодействие с сервером (на примере игры MOBL от компании K-D LAB).

(2game || !2game) ? doGame() : playGame()

Краткое предисловие

или небольшое неформальное введение в тему.

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

Из всего множества современных игр мы выделим и подвергнем небольшому анализу on-line игры. Если быть еще более точными, то мы с Вами разберем общие вопросы взаимодействия между однопользовательским игровым клиентом и игровым сервером. В качестве наглядного примера рассмотрим реализацию подобного общения в «симуляторе жизни» MOBL (официальная страница продукта) компании K-D LAB. MOBL представляет собой WEB приложение, в котором серверная часть реализована на JSP, а клиентом выступает апплет.

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

Оn-line игры, их типы. Функциональность сервера

Для начала давайте определимся с терминологией и дадим несколько общих определений для таких понятий как игровой клиент, сервер и взаимодействие с ним.

Под on-line игрой мы будем понимать небольшую (порядка нескольких сотен килобайт) игровую программу, которая загружается с WWW-сервера, и требующая наличия соединения (возможно, непостоянного) со своим игровым сервером. Понятно, что чем меньше размер нашей игры, тем лучше, так как это позволяет увеличить количество наших потенциальных игроков за счет тех пользователей, которые являются «счастливыми» обладателями достаточно медленных каналов связи. Игра может быть реализована в виде апплета (Java) или при помощи Flash (Macromedia). Никаких ограничений на жанровую принадлежность не накладывается — наша игра может быть как небольшой обычной аркадой, так и стильной мозгодробильной головоломкой. On-line игры делятся на однопользовательские (игрок может играть только самостоятельно) и многопользовательские (игрок играет совместно с другими пользователями или против других игроков). Обращаю Ваше внимание на то, что подобное разделение игр, в общем случае, никак не влияет на количество одновременно играющих пользователей на одном игровом сервере.

Игровым сервером назовём [url=#webapp]WEB-приложение[/url], которое является программной реализацией следующей функциональности:

1. первичная регистрация пользователя- игрока в системе;
2. проведение проверок регистрационных данных при подключении зарегистрированных игроков;
3. взаимодействие с игровым клиентом (в основном, обмен требуемой для игры информацией, в соответствии с заданным внутренним протоколом);
4. хранение всей необходимой для игроков и игр информации в некоторой БД и предоставление доступа к ней.

На «плечи» сервера могут быть возложены и другие задачи. Реализация сервера, понятное дело, может быть выполнена на любом известном вам языке программирования и с дополнительным применением полезных технологий и будет представлять собою набор серверных сценариев (JSP, ASP, etc.)

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

Программирование взаимодействия с сервером

Приступим же к рассмотрению вопросов реализации (здесь и далее будет использоваться Java/JSP). В общем случае происходит следующее:

1. пользователь регистрируется на сервере;
2. зарегистрированный пользователь авторизуется на специальной страничке доступа к игре;
3. сервер подготавливает клиента-игру для сеанса;
4. игра, с компьютера клиента, время от времени ведет информационный обмен с сервером.

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


Наш MOBL-сервер является обычным WEB-приложением. Было решено сделать регистрацию игроков и проверку регистрационных данных (при открытии пользователем игровой сессии) независимой от самого игрового клиента. Пользователю нужно заполнить регистрационную форму (см. Листинг 1; также см. формы HTML). Проверка корректности вводимых данных осуществляется на клиенте при помощи javascript-a. Такая же проверка осуществляется и при получении данных формы серверным сценарием регистрации. Отмечу, что приводимый в листинге код сильно упрощен и сокращен. Сделано это было для того, чтобы не загромождать изложение деталями JSP-реализации. Серверный сценарий регистрации, в случае корректности полученных регистрационных данных, осуществляет добавление нового игрока в свою базу данных. Кстати, применение СУБД и, как следствие, использование SQL для работы с информацией в БД, не только упрощает процесс разработки, но и повышает переносимость кода.

ЛИСТИНГ 1.
Регистрационная форма игрока

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

Взаимодействие клиента и сервера. Определение протокола.

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

Начав разработку WEB реализации, было бы логичным рассмотреть взаимодействие между клиентом и сервером, основываясь на применении HTTP-протокола (RFC2616). Это позволяет не задумываться о всевозможных сетевых программно-аппаратных конфигурациях, через которые могут наши пакеты. В результате мы получаем возможность играть с любой машины, на которой есть установленный и нормально настроенный для WEB-сёрфинга браузер.

Исходя из вышесказанного, получаем: (*)
· запросы от игровых клиентов обрабатываются серверными сценариями;
· вся требуемая информация передается сценариям через набор параметров. В частности, т.к. HTTP-протокол является пассивным, каждое обращение нашего игрового клиента должно передавать на сервер данные о текущем игроке;
· серверные ответы формируются в plain-тексте (в заранее определенном нами формате), и разбираются на клиенте. Сервер и клиент «знают» о требуемом формате сообщений и в каждом конкретном случае способны корректно обработать их.

MOBL-клиент является Java-апплетом, требующим для нормального функционирования игры периодического подключения к серверу для загрузки/сохранения игровой информации. Апплет должен знать о своем текущем игроке. Следовательно, сервер должен каким-то образом предоставить данную информацию апплету (желательно побеспокоиться о том, чтобы пароль не в открытом виде, в противном случае велика вероятность того, что Вам чего-то да ). К счастью, нам не нужно в данном вопросе изобретать велосипед и воспользуемся стандартным решением — передача параметров в апплет (см. Листинг 2). Кстати, использование элемента APPLET уже устарело, вместо него рекомендуется использовать элемент OBJECT.

Имеем следующее: после удачной регистрации, сервер генерирует HTML-страничку, в которой есть информация о самой игре (апплет), и данные текущего игрока, переданные в апплет в качестве параметров. Так как во время создания второй версии MOBL-а была включена поддержка русского языка (первая версия была исключительно английской), в апплет также передается информация о выбранном пользователем языке.

ЛИСТИНГ 2.
Передача регистрационных данных в апплет

Также нам на сервере нужны сценарии для взаимодействия с клиентскими апплетами, а именно:
· получение исходных данных для начала новой игры;
· сохранение на сервере результатов игры;
· загрузка игровых данных для просмотра сохраненной игры.

Реализация взаимодействия: серверная часть.

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

Кратко рассмотрим функциональность этих сценариев, на примере кода сценария создания новой игры и генерации стартовых параметров (см. Листинг 3). В начале каждый сценарий должен осуществить проверку правильности переданных ему регистрационных данных (отмечено на листинге при помощи reg-check). Если регистрационные данные корректны, сценарий начинает выполнение запрошенной функциональности, в нашем примере — простая генерация стартовых параметров для новой игры (create). Затем сценарий формирует ответ для клиента (answer). Отметим, что из-за использования HTTP, каждый ответ игрового сервера (выдаваемый обычным plain-текстом) будет дополняться со стороны WEB-контейнера стандартным HTTP-заголовком. Поэтому, для облегчения разбора серверного ответа на клиентской стороне, начало вывода серверного ответа предваряется `init`-тэгом, обозначающим место окончания HTTP-заголовка (init).

Реализация функциональности серверных сценариев для сохранения/загрузки выполняется аналогично рассмотренному выше материалу.

ЛИСТИНГ 3.
Создание новой игры и генерация стартовых параметров

Реализация взаимодействия: игровой клиент

Взаимодействие игрового клиента с сервером, в нашем случае, можно разделить на несколько небольших задач:

1. перед началом любой игры нужно попросить сервер сгенерировать нам стартовые параметры игры;
2. в случае удачного окончания игры, её конфигурация передается на сервер для сохранения;
3. игровой клиент также должен уметь загружать с сервера сохраненные игры (страница «лучшие игры»).

Определимся же с тем, КАК мы будет общаться с игровым сервером. Исходя из спецификации Java Security (для желающих — небольшой FAQ), следует, что мы можем установить соединение из апплета только с тем сервером, с которого был вытянут этот самый апплет. Будем использовать JDK 1.х, потому как в браузерах по умолчанию поддерживается именно она, поддержка же более свежих версий появляется после установки дополнительных плагинов. В пакете java.net есть всё, что нам может понадобиться для связи с сервером, а именно: достаточно полезный класс URL, с не менее полезным методом openConnection(). На основании этого класса сделаем свою небольшую обертку для HTTP-соединения (см. Листинг 4).

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

ЛИСТИНГ 4.
Класс-обертка для установления соединения с определенным хостом,
передачи параметров методом POST и получением результирующего потока-ответа

Оставшаяся работа — сущие пустяки. Продемонстрируем это на примере загрузки с сервера начальных параметров для новой игры (см. Листинг 5). Для начала нам нужно сформировать строку адреса, для подключения к соответствующему серверному сценарию (address). Метод getCodeBase() возвращает реальный базовый путь к апплету, что позволяет нам не задумываться над сохранением адреса сервера в игровом апплете. Нам важно лишь знать имя и параметры нужного нам server-side script (хранится в константах класса AppSettings, в частности, skstrScriptInitURL — имя сценария для создания новой игры на сервере и получения её стартовых параметров). После этого воспользуемся функциональностью класса из Листинга 4 и пошлем запрос серверу и пробуем получить поток с ответом сервера.

Если ошибок в предыдущих наших действиях не было, начнем получать ответ (receive). Сразу после этого проведем отсечение ненужного нам HTTP-заголовка (skip-header), а заодно и проверку полученного ответа (checks), в соответствии с определенными до этого протоколом и допустимыми ответами со стороны сервера.

Дальнейшее же действо — простая загрузка полученных данных и инициализация внутренних переменных игрового энжина (loading).

ЛИСТИНГ 5.
Загрузка с сервера начальных параметров для новой игры

Заключение

Из вышесказанного видно, что проектирование протокола взаимодействия между клиентом и сервером, а также соответствующая реализация, не является очень сложным занятием. Резюмируя, повторю основные идеи, изложенные в статье:
· выделите задачи, функциональность которых будет реализована в рамках разрабатываемого сервера; определитесь с нужными клиенту данными для работы с сервером;
· определите протокол взаимодействия между клиентом и сервером как минимально необходимое множество сообщений и ответов на них, а также формат сообщений (используйте для этого информацию, полученную в результате выполнения предыдущего пункта);
· проведите анализ доступных технологий, которые могут быть использованы (не обязательно в полной мере) в проекте. Начинайте разрабатывать что-либо своё «с нуля» только в том случае, если Вы действительно не можете воспользоваться уже существующими разработками;
· приступайте к реализации :) Будьте бдительны — велика вероятность того, что Вы не смогли с самого начала предусмотреть и учесть все возможные нюансы Вашего проекта. Помните, что чем раньше Вы начнете вносить изменения в систему, а не ставить временные закладки, надеясь на будущий «авось!», — тем лучше!

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

Но это уже совсем другая история.

Приложение А: кратко о проекте MOBL

Чтобы не повторяться, просто приведу эту ссылку, для интересующихся историей MOBL-а. Здесь же я просто сообщу несколько фактов:

· первоначальная реализация была сделана на С++;
· первая on-line версия была сделана на Java (игровой апплет) и C++ (CGI-scripts, Win32 platform);
· текущая (вторая по счету) версия является полностью переписанной первой версией, портированной на Java. В частности, сервер был реализован на JSP. Также, во время портирования, были сделаны многие дополнительные изменения и улучшения.

Приложение B. Глоссарий.

Java Server Pages (JSP) — независимая от платформы технология, предлагаемая в SUN’s J2EE. Альтернативная методика разработки приложений, динамически генерирующих ответ по запросам клиента

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

SQL — структурированный язык запросов. Используется для работы с БД

WEB-контейнер — программная среда, обеспечивающая поддержку полного жизненного цикла WEB-приложений и их компонент.

WEB-приложение — приложение, построенное для работы в сети Internet. Представляет собой набор взаимосвязанных скриптов (сценариев), работающих под управлением WEB-контейнера.

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

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


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

СУБД — Система Управления Базами Данных. Например, Oracle.

Переходим от VBScript к ASP и ASP.NET. Безопасность и синтаксис

Архив номеров / 2006 / Выпуск №1 (38) / Переходим от VBScript к ASP и ASP.NET. Безопасность и синтаксис

Переходим от VBScript к ASP и ASP.NET

Безопасность и синтаксис

Многие программисты используют VBScript для создания сценариев, предназначенных для управления серверами. Некоторые скрипты настолько усложняются, что их трудно использовать без графического интерфейса. Оптимальным решением этой задачи является создание вебприложения на ASP, ASP.NET.

Создавая сценарии на VBScript для обслуживания серверов, таким образом автоматизируя работу системного администратора и службы технической поддержки, сводя до минимума влияние человеческого фактора, программисты приходят к выводу, что некоторые из их скриптов стали неудобными и им необходим графический интерфейс. Например, веб-интерфейс, выбор которого объясняется соображениями безопасности и удобством эксплуатации. Для решения этой задачи рекомендуется ASP, а лучше всего – ASP.NET, который позволяет на порядок повысить безопасность работы приложения.

От VBScript к ASP

У вас может возникнуть вопрос: «Зачем мне переходить на ASP, когда я просто могу использовать DHTML с VBS вставками?» Использовать DHTML или HTA для этих целей не получится, поскольку они основаны на HTML, который действительно позволяет делать вставки на VBScript, однако не поддерживают работу с OLE-объектами. Для программиста, создающего приложения для обслуживания серверов, поддержка OLE-объектов используемой им средой – основное требование, поскольку формирование отчетов, доступ к Active Directory и др. базируется на их использовании.

ASP представляет собой решение, которое поддерживает HTML, OLE-объекты и позволяет делать вставки на различных скриптовых языках: VBScript, JScript.

Переход от VBScript к ASP достаточно прост и безболезнен: исходный код на VBScript остается практически без изменений.

ASP-страницы – это сценарии, программный код которых выполняется при их запросе. Результатом действия скрипта является DHTML-страница, которая формируется на сервере, а затем отображается в браузере клиента. Структура документа на ASP проста: в первой строке всегда указывается язык, с помощью которого созданы скриптовые вставки ASP-страницы. Первая строка любого из сценариев на ASP выглядит следующим образом:

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

Листинг типовой ASP-страницы выглядит следующим образом:

‘ отображение на экране содержимого переменной

После обработки интерпретатором IIS программного кода и преобразования результатов его работы в HTML/DHTML необходимо дать команду на отображение страницы в браузере клиента. Такой командой является «Response.Write q», где q – имя переменной, содержащей фрагмент HTML-кода.

Необходимо отметить, что ASP имеет свою, хотя и скромную объектную модель, описание которой можно найти практически в любой книге, посвященной программированию на ASP в разделе «Приложения».

Настройка IIS для ASP

При создании веб-приложений на основе ASP необходимо учитывать некоторые особенности этого языка.

Первая особенность: поскольку код ASP-страниц исполняется на сервере и только результат в виде HTML-страницы пересылается на клиентскую машину, то для успешного запуска приложения на сервере пользователь должен обладать соответствующими правами. IE, IIS и запускаемые им сервисы представляют собой трехзвенную систему (см. рис. 1).

Рисунок 1. Трехзвенная система

Пусть IIS имеет настройки по умолчанию. В этом случае при загрузке любой ASP-страницы она стартует от имени встроенного пользователя (см. рис. 2). Если страница работает с некими базами данных, например с Active Directory, то пользователь, запускающий данную страницу, должен обладать соответствующими правами системного администратора.

Рисунок 2. Настройка безопасности IIS

Существует несколько способов соблюсти эти условия. Первый – учетную запись встроенного пользователя заменить учетной записью администратора сети. При таком раскладе любой пользователь в сети сможет посетить данную страницу, т.к. она будет запускаться от имени системного администратора. Этот способ предоставляет всем доступ к данной странице, что, согласитесь, неправильно: резко снижается безопасность всей системы. В случае ошибок на странице злоумышленник может легко запустить вредоносный код с правами администратора.

Поэтому разумно использовать другой способ, с помощью которого можно ограничить доступ к ресурсам. В настройках IIS необходимо сбросить флажок (см. рис. 2) с Enable anonymous access и установить его напротив Basic Authentication. Также следует изменить права на файловую структуру используемого сайта, исключив оттуда группу Everyone и добавив соответствующие группы безопасности и назначить им соответствующие права. При такой настройке IIS только системные администраторы получат доступ к данной странице. При попытке любого пользователя, не являющегося администратором сети, получить доступ к странице, IIS будут запрошены имя и пароль пользователя.

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

Только что мы рассмотрели механизм взаимодействия первого и второго звена в трехзвенной системе. Первым звеном является рабочая станция пользователя, вторым –сервер, на котором установлен IIS. Взаимосвязь этих звеньев осуществляется с помощью одного пользователя. Между вторым и третьим звеном (сервер iis-процессы, порождаемые из asp-процесса) взаимодействие осуществляется с помощью другого пользователя.

Рассмотрим взаимодействие второго и третьего звена подробнее.

При запуске из кода ASP-страницей какого-либо приложения осуществляется взаимодействие между вторым и третьим звеном. IIS порождает процесс, запускаемый от имени другого встроенного пользователя. Поскольку ASP-страница выполняется на сервере, то для запуска приложения необходимы соответствующие права. Управление этой учетной записью пользователя осуществляется в Application Tools (см. рис. 3).

Рисунок 3. Настройка безопасности IIS

Переход от VBScript и ASP к ASP.NET

Теперь, когда мы знакомы c ASP и разобрались с настройкой IIS для ASP-проектов, подведем промежуточный итог, а он не утешителен! Дело в том, что в построенной системе большая брешь в безопасности; поскольку для доступа к АD в ASP-файле в явном виде надо указать имя и пароль системного администратора, еще одним недостатком является указание пароля в разделе «Аnonymous Аccess» вместо встроенной учетной записи указать имя и пароль системного администратора. Конечно, системный администратор постарается защитить файловую систему соответствующим распределением прав, однако принятых мер недостаточно. Необходимо сделать так, чтобы система сама определяла и подставляла имя и пароль пользователя между вторым и третьим звеном, т.е. запускала сервисы от имени пользователя, который вошел на сайт. Поставленная задача успешно решается переходом с помощью ASP.NET и включением режима имперсонализации.

Установка Visual Studio

Перед установкой Visual Studio .NET должен быть предварительно установлен пакет программ, необходимых для ее установки:

  • Microsoft IIS 5/6
  • Microsoft .NET Framework 1.1/2.0
  • Microsoft FrontPage Server Extensions 2000/2002
  • Microsoft Visual J# .Net Redistributable Package 1.1/2
  • Microsoft Windows Installer 2/3(.1)

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

Таблица 1. Необходимые компоненты для установки Visual Studio

Microsoft IIS 5

Входит в состав Windows 2000 – ver 5.0, XP – ver 5.1

Илон Маск рекомендует:  file_exists - Проверить наличие указанного файла или каталога
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
Рубрика: Программирование / Веб-программирование