ASP – Скрипт Active Server Page
Расширение ASP
Чем открыть файл ASP
В Windows: Любым браузером, любым текстовым редактором, Internet Explorer, FireFox, Opera, Chrome, Microsoft IIS, Adobe Dreamweaver CS5, Adobe Fireworks CS5, Microsoft Visual Studio 2010, Microsoft Visual Web Developer, ES-Computing EditPlus.
В Mac OS: Любым браузером, любым текстовым редактором, Adobe Dreamweaver CS5, Adobe Fireworks CS5.
Описание расширения ASP
Популярность:
Разработчик: Microsoft
Тип файла ASP связан прежде всего с «Active Server Pages». Active Server Pages – это язык программирования от Microsoft для динамических веб-страниц, созданных с помощью Visual Basic или JScript. Страницы, написанные с помощью этого языка имеют расширение .asp и похожи на CGI скрипты, которые генерируют код на лету. ASP страницы могут комбинировать HTML, скрипты и компоненты ActiveX сервера.
Примечание: Этот тип файла может быть заражен вирусами и должен быть тщательно проверен, если кто-то посылает вам файл с таким расширением.
Программирование | ASP (Active Server Pages)
ASP (англ. Active Server Pages — «активные серверные страницы») — технология, предложенная компанией Microsoft в 1996 году для создания Web-приложений. Эта технология основана на внедрении в обыкновенные веб-страницы специальных элементов управления, допускающих программное управление.
По своей сути, ASP — это технология динамического создания страниц на стороне сервера, приблизившая проектирование и реализацию Web-приложений к той модели, по которой проектируются и реализуются обычные приложения.
Для реализации приложений ASP используются языки сценариев (VBScript или JScript). Также допускается применение COM-компонентов.
Технология ASP разработана для операционных систем из семейства Windows NT и функционирует под управлением веб-сервера Microsoft IIS.
Технология ASP получила своё развитие в виде ASP.NET — технологии создания веб-приложений, основанной уже на платформе Microsoft .NET.
ASP в своём развитии прошёл через несколько версий:
ASP 1.0 (распространяется с IIS 3.0) в декабре 1996 года.
ASP 2.0 (распространяется с IIS 4.0) в сентябре 1997 года.
ASP 3.0 (распространяется с IIS 5.0) в ноябре 2000 года.
ASP.NET MVC — это инфраструктура для разработки веб-приложений от Microsoft, которая сочетает в себе эффективность и аккуратность архитектуры «модель-представление-контроллер» (model-view-controller — MVC), новейшие идеи и приемы гибкой разработки, а также все лучшее из существующей платформы ASP.NET. Она представляет собой полномасштабную альтернативу традиционной технологии ASP.NET Web Forms, предоставляя преимущества для всех проектов веб-разработки, кроме самых тривиальных.
На момент своего появления в 2002 г. платформа ASP.NET оказалась огромным шагом вперед. На рисунке ниже показано, как выглядел на то время стек технологий Microsoft.
В Web Forms разработчики из Microsoft попытались сокрыть как протокол HTTP (с присущим ему отсутствием состояния), так и язык HTML (который на тот момент был незнаком многим разработчикам) за счет моделирования пользовательского интерфейса в виде иерархии объектов, представляющих серверные элементы управления. Каждый элемент управления отслеживает собственное состояние между запросами (с помощью средства View State (состояние представления) ), по мере необходимости визуализируя себя в виде HTML-разметки, и автоматически соединяя события клиентской стороны (например, щелчки на кнопках) с соответствующим кодом их обработки на стороне сервера.
Фактически Web Forms — это гигантский уровень абстракции, спроектированный для предоставления классического управляемого событиями графического пользовательского интерфейса через веб-среду. Идея заключалась в том, чтобы веб-разработка выглядела подобно разработке с применением Windows Forms. Разработчики больше не должны были иметь дело с последовательностями независимых запросов и ответов HTTP. Они могли мыслить терминами пользовательского интерфейса, поддерживающего состояние, и в Microsoft появилась возможность переместить армию разработчиков настольных Windows-приложений в новый мир веб-приложений.
Источники:
professorweb.ru
ru.wikipedia.org
Программирование | ASP (Active Server Pages)
[header]
ASP-страница читает и обрабатывает нужный шаблон, а затем посылает результат клиенту одной командой Response.Write().
Этот подход лучше предыдущего, поскольку позволяет полностью разделить ASP и HTML, причем HTML-файлы остаются удобными для редактирования дизайнером. Однако неспособность выводить таблицы с неизвестным заранее числом строк делает этот подход малоприменимым (ASP+, судя по имеющимся сведениям, имеет встроенные решения этой проблемы).
2.2 Вынесение цельной HTML-страницы в отдельный файл
Учитывая недостатки вышеперечисленных способов, можно предложить следующее решение. Разделим ASP-файл на 2 файла. Первый будет содержать только ASP-код и никаких посылок результатов клиенту. В этом файле должно полностью отсутствовать HTML-форматирование. Файл будет включать в себя (SSI) второй файл, который будет цельной HTML-страницей с минимальным количеством четко выделенного ASP-кода. Второй файл, по сути, будет тем же HTML-шаблоном, только вместо, например «[header]» будет написано » «, что не затруднит работу дизайнера. Но в нем также будет возможность выводить более сложные программные структуры. Идея в том, чтобы код во втором файле (где HTML) был действительно минимален и четко выделен. Т.е. все крупные куски кода инкапсулируются в функции и объекты, которые создаются в первом файле (чистый ASP-скрипт). Второй файл (HTML) лишь запускает эти функции и методы объектов. В этом плане JavaScript дает несомненные преимущества. Не пожалейте часа-двух, и изучите разные способы создания объектов в JavaScript — это позволит вам создавать удивительно красивые по своей простоте и логике архитектурные конструкции.
Общая схема разделения ASP/HTML | |
file1.asp | file2.htm.asp |
Business Logic Level: Чтение/Обработка данных. Создание объектов (например объекта objExample), которые будет использовать Файл #2 (file2.htm.asp). | .
. |
Presentation Level: | |
Finalization Level: Закрытие DB-connections, etc. |
Отметим также, что в случае перехода на JSP, такой HTML-шаблон можно совсем не менять.
Сформулируем основные принципы вышеописанного подхода:
- ASP-страница состоит из 2х файлов
- 1й файл содержит чистый серверный скрипт, и в нужном месте включает 2й файл, (например через SSI)
- 1й файл не посылает информацию клиенту
- 1й файл не содержит команд HTML
- 1й файл инкапсулирует весь код в функции и/или методы объектов, которые затем могут быть вызваны из 2-го файла
- 2й файл содержит полную HTML-страницу, от до
- 2й файл содержит минимально возможный ASP-код. любой код бизнес-логики сокрыт в методах и/или функциях первого файла, и вызывается нужный метод или функция
- 1й и 2й файлы не содержат команд Response.Write() (по причинам, описанным ниже)
- 1й файл имеет расширение .asp, т.к. это чистый ASP-файл
- 2-му файлу можно дать расширение .htm.asp, чтобы подчеркнуть, что это все-таки HTML по содержанию. Имя 2-го файла может быть то же что у 1-го, или с каким нибудь префиксом, для удобства поиска. Например: shopinfo.asp и _t_shopinfo.htm.asp .
К побочным эффектам подобного разделения можно отнести достаточно простую возможность поддержки генерации не-HTML страниц. Например — WAP или XML. Для этого надо только написать другой файл шаблона (файл #2). Файл с серверным скриптом (#1) останется тем же.
Теперь остановимся еще на двух часто встречающихся деталях.
2.3 Чего желательно избегать: Response.Write(); HTML-форма и ее ASP-обработчик в одном файле
Response.Write() — проклятие для дизайнера
Мы можем записать команду генерации динамического HTML в ASP двумя способами:
Работают они, с внутренней точки зрения, одинаково. Однако они записываются с несколько различным синтаксисом. Сравните два варианта записи:
Первый вариант еще выглядит как HTML и доступен для осмысления дизайнером-непрограммистом. Второй вариант, из-за обилия кавычек, конкатенаций и бэкслешей, обычно осмыслению не поддается никак. Более того, при достижении определенного уровня сложности, его не могут осмыслить даже авторы через неделю после написания. Поэтому — не стоит использовать Response.Write(. ), если это не критично.
HTML-форма и ее ASP-обработчик в одном файле
Очень хочется развенчать совершенно кошмарный пример, который обычно приводят в туториалах по ASP. Это — объединение HTML-формы и обрабатывающего ее кода в одной ASP-странице. Поначалу это смотрится круто, и кажется что снижение количества файлов проекта дает прекрасный упрощающий эффект. Поверьте — карма человека, придумавшего этот пример из туториала, запятнана навсегда. А ведь все могло быть так просто — форма в обычном HTML-файле, а обработчик — в ASP. И дизайнер и программист были бы счастливы. Если бы не этот пример из туториала.
3. Выносим SQL из ASP (простой вариант уровня бизнес-логики)
3.1 Независимость ASP кода от источника данных, снятие нагрузки с IIS, упрощение ASP кода.
Мы уже рассмотрели, как вынести HTML в отдельный файл и отдать его дизайнеру. Но остался еще один кандидат на то, чтобы убрать его из ASP. Это — SQL. Он усложняет ASP-код, жестко связывает его с конкретным сервером базы данных, загружает IIS излишними вычислениями, снижает возможность масштабирования. Проще говоря — он превращает 3-х уровневое приложение в 2-х уровневое (клиент-сервер).
Рассмотрим архитектуру 3-х уровневого web-приложения, применительно к IIS, ASP и COM
Где на данной схеме расположить ASP c ADODB? Поскольку используется прямая запись SQL и однозначное обращение к конкретной базе данных, то можно утверждать, что ASP обращается непосредственно к 3rd tier, а ADODB является сервисом доступа к данным, и принадлежит 3rd tier. В 3-х уровневой архитектуре прямая связь 1st tier c 3rd tier недопустима. Говоря об SQL, можно утверждать, что он однозначно связывает код с выбранным типом сервера базы данных (будь то Oracle, MSSQL или что либо еще). То, что можно писать только на ANSI SQL, который будет работать везде, скорее всего миф. В любом случае это очень сложно реализовать.
Посмотрим, что можно предложить.
3.2 Формированию уровня бизнес-логики
Объекты 2nd tier принято разделять на две группы — представляющие клиента и его действия (Session Beans в EJB), и представляющие сущности источника данных (Entity Beans в EJB). Cущности источника данных (в частности — БД) выявляются и формулируются на фазе планирования / разработки логической структуры проекта. К сожалению во многих проектах эти фазы отсутствуют как класс и правит тенденция к стихийному развитию структуры БД. Если вам достался подобный проект, то придется заново тщательно проработать структуру базы данных, выявлять основные сущности и распределить все таблицы к конкретным сущностям.
Объекты, представляющие клиента на 2nd tier, реализуют возможные действия клиента. Эти действия осуществляются только через объекты — сущности (и не через прямой доступ к DB). Поскольку хардкодить все, даже самые незначительные, операции в компилируемых объектах возьмется далеко не любая компания, можно предложить писать эти объекты на ASP в страницах, не содержащих HTML (см. главу о вынесении HTML из ASP). Тогда получается такое изменение схемы распределенной архитектуры для IIS/ASP/COM:
Мы можем выделить ASP-код, представляющий клиента, исключительно с бизнес-логикой, без HTML-форматирования и взаимодействия с пользователем. Как и в ситуации с хранимыми процедурами, такой отход от правила может быть, иногда, оправдан. Требования к нему просты: код бизнес-логики нужно организовать в независимую, от остального 1st tier, структуру объектов, которая не занимается делами 1st tier (т.е. никак не взаимодействует с пользователем напрямую). Этот код лучше хранить в отдельных файлах. А в обычном коде 1st tier использовать одинаковый интерфейс, способ создания и удаления таких встроенных ASP-объектов и настоящих 2nd tier объектов. В этом помогут, описанные ранее, Project ASP API и ObjectFactory. Тогда не возникнет «размазывания» кода бизнес-логики по интерфейсу пользователя, а, при необходимости, его легко можно будет вынести в настоящий 2nd tier объект.
Объекты, представляющие сущности на 2nd tier, реализуют следующие услуги:
- вернуть атрибуты сущности по уникальному ключу;
- искать сущность по условию;
- искать группы сущностей по условию или работать как итератор;
- изменить атрибуты сущности;
- создать новую сущность;
- удалить сущность;
Можно предложить написать унифицированный объект для работы с сущностями. Рассмотрим один из вариантов подобного подхода, основанный на SQL-шаблонах.
3.3 Перемещаем SQL из ASP-файлов в SQL-шаблоны
Одним из главных достоинств ASP является его скриптовость. Т.е. файл и исходным кодом является одновременно и исполняемым файлом. Без необходимости компиляции, связывания и т.д. Выигрыш в скорости у компилируемых объектов обычно бывает менее важен, чем простота скриптов на фазе поддержки проекта. Ничто не сравнится с ощущением молниеносного всевластия над ошибками в приложении, когда можно что-либо подправить в непосредственно работающем сайте прямо по время презентации, зайдя на сервер по FTP (что, конечно же, мы делать не будем, т.к. нарушим структуру версионного контроля).
И, если слишком многое хардкодить в компилируемых объектах 2nd tier, то скриптовость ASP мы утратим. Здесь уместно предложить разумный компромисс. Сложные операции клиента мы согласимся хардкодить в объекты 2nd tier. А вот со всеми SELECT и с единичными INSERT,UPDATE,DELETE (не требующих участия в сложных транзакциях) поступим проще. Вынесем их во внешние файлы, называемые SQL-шаблонами. С ними будет работать один унифицированный объект 2nd tier.
SQL-шаблоны могут иметь любую структуру — XML, INI, etc. Они, теоретически, могут храниться как угодно, и не обязательно в файлах. Главный принцип в том, что каждому SQL-выражению задается сущность, тип (SELECT, UPDATE, INSERT, DELETE) и присваивается имя. И основной код 1st tier обращается к уникальному SQL по комбинации: сущность+тип+имя шаблона. Затем передаются входящие параметры и (в случае SELECT) получаются исходящие. Т.е., основной код 1st tier и клиентских Session-объектов с SQL больше никак не связан.
По сути SQL-шаблоны — это очень простой способ реализовать все объекты сущностей (Entity Beans) быстро и унифицированно.
3.4 Пример структуры SQL-шаблонов
Рассмотрим один из вариантов организации структуры SQL-шаблонов в виде каталогов и файлов.
Допустим, корневой каталог структуры называется просто «entities» («сущности»). В этом каталоге находятся подкаталоги, соответствующие сущностям базы данных. На рисунке их четыре: Agent, Customer, Goods, Shop. (имена сущностей принято записывать в единственном числе). В каждом каталоге сущности находятся 4 подкаталога, соответствующих типам DML SQL-выражений: SELECT, UPDATE, INSERT, DELETE. В каталогах DML-типов находятся сами SQL-шаблоны. Это просто файлы, у которых имя соответствует назначению SQL-шаблона, а расширение, например, определяет тип DB сервера под который они написаны. (т.е. можно иметь несколько одинаковых SQL-шаблонов оптимизированных под разные типы SQL-серверов: Oracle, MSSQL, MySQL, etc.). Дополнительно, в корневом каталоге «entities» может находиться общий конфигурационный файл доступа к DB. А в каталогах сущностей — опциональные конфигурационные файлы доступа к DB для каждой сущности. Таким образом, мы можем обеспечить инфраструктуру для хранения различных сущностей на различных DB-серверах. Приведем пример файла SQL-шаблона в *.INI-подобном формате (исключительно для простоты, т.к. XML-формат файла в данном случае гораздо удобнее). Это шаблон сущности Customer, типа SELECT, который производит выборку имен и фамилий всех клиентов, зарегистрировавшихся в промежутке между двумя заданными датами
Критериями выбора скрипта разработки для ASP могут стать:
В свете вышеописанных критериев, можно порекомендовать выбор в пользу JScript. Общая объектно-ориентированная библиотека: Project ASP API Для упрощения использования любой новой технологии (и для описанных выше конвертаций ASP проекта в проект JSP/PHP) жизненно необходимо абстрагировать системные средства ASP в библиотеку общего пользования. Эту библиотеку можно специально приспособить под конкретный проект, для значительного упрощения ее применения. Рассмотрим типичных кандидатов на помещение в общую, объектно-ориентированную, библиотеку. Config — это объект, который хранит все настройки, общие для сайта в целом. Реально, они будут записываться при старте сайта в ASP коллекцию Application(), например из конфигурационного XML или INI-файла или просто из global.asa. Но весь остальной ASP-код работает с конфигурационными параметрами исключительно через этот объект и к способу хранения/чтения этих параметров никак не привязан. Параметры конфигурации могут быть представлены, в объекте Config, как атрибуты объекта и/или как методы getStr(«Section»,»Entry»,»Default»), getInt(. ), getBool(. ), и т.д. ConfigUser — этот объект хранит переменные текущей сессии пользователя. Абстрагируя переменные сессии в этот объект, мы получаем независимость от способа хранения переменных сессии. Мы можем как угодно менять и комбинировать способы хранения этих переменных: коллекция Session(), Cookies, Database, поля HTML формы — что угодно. При этом основной код будет оставаться неизменным. Доступ к переменным можно организовать аналогично объекту Config, но уже с возможностью модификации этих переменных — getStr(. )/setStr(. ), и т.д. Тут возникает весьма неоднозначный вопрос — об именовании объектов. Как в ASP, так и в сервлетах/JSP общую конфигурацию рекомендуется записывать в коллекцию Application (application), а пользовательскую — в Session (session). Проблема в том, что концепции коллекций Application и Session подразумевают то, что туда можно записать все, что угодно и время жизни этих коллекций ограничено. Они универсальны, и не приспособлены специально для хранения конфигураций. Поэтому назвать наши конфигурационные объекты надо как-то по-другому (не application и session). Например: ConfigApp/ConfigUser, AppProperties/UserProperties, GlobalProperties/SessionProperties и т.п. Еще один фактор — это сокращения в названиях. Это не очень хороший стиль, поскольку многие сокращения могут оказаться непрозрачны для некоторых разработчиков. Вопрос о поиске хороших наименований является очень тяжелым и субъективным. Автор будет весьма признателен, если кто-то предложит удачные короткие названия для двух вышеприведенных объектов, которые встречаются почти во всех проектах. ObjectFactory — если задуматься о будущем, то запись Server.CreateObject(. ) в основном ASP коде покажется весьма ограничивающим фактором. Если понадобится использовать J2EE CAS COM Bridge (мост от Sun для использования EJB и обычных Java-классов через COM), то процесс создание объекта уже будет отличатся, и запишется так (JScript): _factory = Server.CreateObject(«J2EECAS.Java );objJavaStr = _class.New(); И основной ASP код придется переписывать. Для мостов CORBA придется использовать другую запись. Нет, конечно, может быть не все так плохо, и возможно для данного конкретного проекта никогда не понадобится связь ни с EJB, ни с CORBA. Но кто знает. Если вы все же решились абстрагировать и эту сторону проектной реальности, то ObjectFactory, минимально должен предоставлять 2 метода — создание и удаление объекта. Не важно, что обычно удалением объектов занимался сборщик мусора. Пусть даже наш метод удаления объекта на самом деле ничего не делает — это не важно. Пусть он будет и пусть он вызывается когда нужно — будущее нас рассудит. У каждого объекта 2-nd tier должен быть псевдоним для его идентификации при обращении к ObjectFactory. Например, в основном коде будет запись ObjectFactory.CreateObject(«MailSender»). И только ObjectFactory на самом деле будет знать, что это COM объект с AppId «com.sa.soft.utils.SendMail005». Параллельно ObjectFactory можно нагрузить мелкими функциями — контролем всяческих пулов и кэшей, проверкой валидности объекта и т.д. И, чтобы уж совсем по-модному, доступ к вышеописанным объектам должен осуществляться через единственный объект-ядро: Core — этот объект должен присутствовать во всех ASP страницах основного кода в единственном экземпляре (синглетонами также должны быть объекты Config, ConfigUser и ObjectFactory. а вот DB-объекты — необязательно). Главная задача объекта Core — создавать и возвращать все описанные выше объекты написанной вами библиотеки, гордо именуемой Project ASP API. Например, Core.getConfigApp() создаст объект ConfigApp и вернет на него ссылку. Повторный вызов не будет создавать объект повторно, а вернет ту же ссылку (чтобы гарантировать, что ConfigApp останется синглетоном). Помимо того, что основной ASP-код станет более понятным, мы получим весьма полезный эффект. Core может запоминать ссылки на все созданные им объекты. И вызвав в конце ASP-страницы метод, например, Core.close(), мы получим гарантированное закрытие всех объектов, даже если мы забыли закрыть их в основном коде. Для объектов работы с базой данных это особенно критично. Конечно, стандартным должен быть и объект для работы с источником данных, но о нем позднее. Дополнительную информацию Вы можете получить в компании Interface Ltd. Способы организации активных web-серверовISAPIЕсли Web- сервер создан на базе Microsoft Internet Information Server , вместо программ CGI можно использовать приложения ISAPI , реализованные в виде библиотек динамической загрузки DLL , что позволяет повысить производительность и масштабируемость . Приложения ISAPI условно делятся на расширения ISAPI и фильтры ISAPI . Расширения ISAPIРасширения ISAPI выполняют те же функции, что и программы CGI : обычно они применяются для обработки клиентских запросов и возвращения ответа в формате HTML. Каждый раз, когда удаленный пользователь обращается к расширению CGI , на сервере Web запускается программа, которая выполняется как отдельный процесс, причем в собственном адресном пространстве. На запуск процесса требуется время, и если ваш сервер пользуется популярностью, то программы CGI могут полностью его загрузить. В результате увеличится время реакции сервера, что может оттолкнуть от него пользователей. Для повышения производительности в некоторых Web-серверах (в частности, Microsoft Internet Information Server) используется другой способ создания расширений. Расширение создается как библиотека динамической загрузки DLL с использованием программного интерфейса ISAPI ( Internet Server API). Когда такое расширение активизируется в первый раз, оно загружается в адресное пространство процесса Web-сервера и начинает свою работу. В памяти всегда находится только одна копия соответствующей библиотеки DLL, поэтому при одновременном обращении к расширению ISAPI нескольких пользователей системные ресурсы расходуются более экономно, и, кроме того, не тратится время на дополнительные загрузки расширения. Программирование приложений ISAPI представляет собой более сложную задачу, нежели создание программ CGI . Поскольку такие приложения всегда работают в мультизадачном режиме, необходимо обеспечить синхронизацию доступа к критичным ресурсам. Ошибки в приложениях ISAPI могут привести к аварийной остановке сервера Web, а вот при использовании программ CGI это маловероятно. ISAPI -расширения явно указываются в URL-адресе, отправляемом на IIS-сервер: Например: http://localhost/sayhelloisapi/sayhelloisapi.dll ISAPI -расширение можно вызывать с параметрами, которые позволят одному компоненту выполнять разные задачи. Сервер IIS версии 4.0 и старше позволяет загружать программы ISAPI в отдельное адресное пространство . Эта возможность, замедляющая работу сервера, обычно используется для отладки новых программ. Аварийное завершение программы ISAPI , загруженной в отдельное адресное пространство не приводит к полной остановке Web-сервера. В результате расширения ISAPI работают быстрее по сравнению с программами CGI , поскольку для программ CGI для каждого пользователя приходится запускать отдельный процесс. Однако приложения ISAPI приходится отлаживать намного тщательнее, чем программы CGI . Так как приложение ISAPI работает в адресном пространстве Web-сервера, ошибка в приложении ISAPI способна вызвать аварийное завершение работы Web-сервера. Фильтры ISAPIФильтры ISAPI , так же как и расширения ISAPI , реализованы в виде библиотек динамической загрузки DLL и способны контролировать весь поток данных между браузером и Web-сервером на уровне протокола HTTP. ISAPI -фильтры никогда не вызываются явно — IIS-сервер обращается к ним в ответ на определенные события в процессе выполнения запроса:
Благодаря этому их можно применять для решения таких задач, как динамическая перекодировка и шифрование данных , создание дополнительных процедур аутентификации пользователей , сбор статистической информации об использовании ресурсов сервера и т. д. ISAPI -расширения часто создаются с использованием ISAPI -классов библиотеки MFC (Microsoft Foundation Class Library ). Это значительно упрощает разработку ISAPI -расширений. Активные страницы ASPActive Server Pages ( ASP ) — это серверная среда для разработки и выполнения динамических интерактивных веб-приложений . Технология ASP предполагает интенсивное использование серверных сценариев и объектов СОМ для создания активных Web-серверов. Языки программирования, используются для создания больших и сложных программных комплексов. Языки написания сценариев используются для создания программ ограниченных возможностей, называемых сценариями, которые выполняют функции web-узла на web-сервере или в браузере. В отличие от сложных языков программирования, языки написания сценариев интерпретируются: инструкции последовательно выполняются промежуточной программой, называемой интерпретатором команд . Хотя интерпретация уменьшает эффективность выполнения, языки написания сценариев просты для изучения и обеспечивают большие возможности. Сценарии могут быть встроены в HTML -страницы для форматирования содержимого или могут реализовывать компоненты COM , заключающие в себе бизнес-логику. Файл Active Server Pages ( ASP ) представляет собой текстовый файл с расширением «. asp «. Этот файл может содержать текстовые данные, тэги языка HTML и серверные сценарии. Обработка этого файла происходит последовательно, от начала и до конца, при этом выполняются все содержащиеся в нем команды сценария, после чего файл отправляется на обозреватель в виде веб-страницы. Когда пользователь обращается к странице ASP , Web- сервер вызывает веб-сервер расширение ASP для обработки указанного в запросе файла, которое интерпретирует расположенный в ней сценарий . При этом анализируются параметры, переданные этой странице. Далее страница модифицируется (или создается заново), а затем отправляется обратно пользователю. В ASP отсутствует ориентация на конкретный язык программирования , поэтому знакомства с любым языком сценариев ( VBScript , JScript или PERL) будет достаточно для того, чтобы работать с Active Server Pages. Более того, на страницах ASP допускается использование любого языка сценариев, для которого был установлен COM -совместимый обработчик сценариев. Обработчик сценариев — это программа , которая обрабатывает команды, записанные на определенном языке. В состав ASP входят обработчики сценариев VBScript и JScript , но имеется дополнительная возможность установки обработчиков для языков PERL, REXX и Python , которые могут быть получены от независимых разработчиков. Обработчик сценариев представляет собой расширение ISAPI , которое физически является динамически подключаемой библиотекой ASP.DLL . ASP.DLL просматривает файлы .asp на предмет наличия тэгов, обозначающих внедренный код для выполнения на сервере. ASP.DLL передает код сценария в Windows Script Host (WSH). WSH выполняет этот код и возвращает ответ файлу ASP.DLL , который, в свою очередь , передает IIS результат выполнения сценария и содержимое самого файла ASP . IIS возвращает ответ программному обеспечению, от которого поступил запрос . Средствами технологии ASP можно создавать интерактивные Web-страницы, не используя расширения CGI или ISAPI , что позволяет в ряде случаев полностью избежать или максимально сократить программирование на C++ или Perl. Активные страницы ASP выполняют обработку данных, введенных пользователями при помощи форм, обращаясь при необходимости к базам данных или другим активным объектам . Пользователь не может каким-либо образом получить содержимое страницы ASP , так как Web- сервер отправляет ему не саму страницу, а результат ее интерпретации. Таким образом, логика работы страницы скрыта от пользователей. ASP поддерживает технологию работы со сценариями Windows Script Components. Она позволяет поместить все сценарные процедуры, выполняющие бизнес-логику, в COM -компоненты. Эти компоненты допускают повторное использование, и могут работать как в web-приложениях, так и в других программах, построенных по технологии COM . ASP поддерживает новую служебную программу шифрования сценариев, поставляемую с MicrosoftVisual Basic Scripting Edition ( VBScript ) и Microsoft® JScript 5.0. Имеется возможность шифровать как клиентские, так и серверные сценарии, в результате чего тексты сценариев будут отображаться бессмысленной последовательностью ASCII-символов. Зашифрованные сценарии расшифровываются обработчиком сценариев во время их выполнения, поэтому нет необходимости в использовании отдельной программы расшифровки. Несмотря на то, что это не является полностью безопасным решением, технология не позволяет большинству обычных пользователей скопировать или просмотреть сценарий . Серверный сценарий , встроенный в страницу ASP , способен обращаться к базам данных через вызов методов интерфейса ActiveX Data Objects ( ADO ) — простую и понятную процедуру. Если возникнет необходимость реализовать собственную бизнес-логику, имеется возможность создания новых объектов СОМ или использования объектов СОМ сторонних разработчиков. Образовательный блог — всё для учебы1) Общие сведения об ASP 2) Встроенные объекты 3) Особенности ASP В отличие от CGI, ASP-сценарий выполняется как внутренний процесс сервера, кроме того, он многопоточен и оптимизирован для работы с большим количеством пользователей. ASP-сценарий начинает выполняться после того, как браузер запросит файл с расширением *.Asp с Web-сервера. Web-сервер посылает вызов встроенному в IIS ASP-механизму обработки (..\System\InetSrv\Asp.Dll), который считывает сценарий и выполняет все встретившиеся команды. В результате генерируется HTML-страница, которая посылается браузеру. Для того, чтобы с помощью ASP сделать что-либо серьезное на Web-сервере, необходимо создать COM-объекты и использовать их службы (методы). Компоненты ASP Должны использовать модель потоков STA – каждый объект выполняется в контексте собственного потока и защищен от конкурирующих потоков. 4) Доступ к встроенным объектам 5) Недостатки ASP 6) Пример реализации ASP — Структура программы доступа к БД HTML-заголовок: Демонстрация ASP Подключение к БДПодключение к БД: HTML-подвал: |
Цикл считывания данных:
Тип |
---|
Последняя версия |
ASP (англ. Active Server Pages — «активные серверные страницы») — технология, предложенная компанией Microsoft в 1996 году для создания Web-приложений. Эта технология основана на внедрении в обыкновенные веб-страницы специальных элементов управления, допускающих программное управление.
По своей сути, ASP — это технология динамического создания страниц на стороне сервера, приблизившая проектирование и реализацию Web-приложений к той модели, по которой проектируются и реализуются обычные приложения.
Для реализации приложений ASP используются языки сценариев (VBScript или JScript). Также допускается применение COM-компонентов.
Технология ASP разработана для операционных систем из семейства Windows NT и функционирует под управлением веб-сервера Microsoft IIS.
Технология ASP получила своё развитие в виде ASP.NET — технологии создания веб-приложений, основанной уже на платформе Microsoft .NET.
Содержание
Синтаксис [ править ]
Страница на ASP — это обычная страница HTML, со вставками, обозначенными ограничителями и %> :
То что находится внутри ограничителей — это текст программы, интерпретируемый при запросе страницы. VBScript является языком по умолчанию, хотя возможно использование и JScript [источник не указан 2893 дня] (или любого другого языка, если установлен соответствующий интерпретатор):
Версии [ править ]
ASP в своём развитии прошёл через несколько версий:
- ASP 1.0 (распространяется с IIS 3.0) в декабре 1996 года.
- ASP 2.0 (распространяется с IIS 4.0) в сентябре 1997 года.
- ASP 3.0 (распространяется с IIS 5.0) в ноябре 2000 года.
Apache::ASP [ править ]
- Apache::ASP (англ.) предоставляет функциональность ASP на основе веб-сервера Apache, со скриптами на основе Perl.
ASP в Sambar Server [ править ]
Сервер Sambar Server имеет собственную реализацию ASP, которая использует язык CScript в качестве языка программных вставок. [1]
Примерные аналоги [ править ]
mod_php и mod_perl
Достоинства и недостатки [ править ]
Язык VBScript, обычно используемый в ASP, имеет менее удобный синтаксис чем другие языки, например язык PHP. JScript лишен этого недостатка, но имеет другой, более серьёзный — неприятную обработку типов данных OLE Automation, что приводит к скрытым, трудным в обнаружении ошибкам.
Однако ASP может использовать очень хороший набор классов для работы с SQL базами данных — ADO, который примерно аналогичен Perl DBI и куда лучше, чем вызовы mysql_xxx в PHP.
Производительность интерпретатора VBScript значительно выше, чем PHP.
Кроме того, ASP поддерживает объекты Session и Application, с которыми в PHP/Apache традиционно есть огромные сложности, связанные с архитектурой процессов Apache 1.x (а она восходит к нелюбви к потокам в мире UNIX и использованию fork() вместо них везде, где возможно).
Тем не менее, объект Session ныне считается с трудом удовлетворяющим требованиям безопасности, и зачастую вместо него все его содержимое помещают в один огромный cookie, и передают туда-обратно между клиентом и сервером. Такое легко реализуемо в PHP, этим пользуются, например, phpBB и его коммерческий дериватив vBulletin