Статья посвящена в основном старой кляче Classic ASP — слабо используемой, а временами и забытой технологии от Microsoft, впервые выпущенной в 1996 году. Чтобы не нагнетать интригу, сразу замечу, что тестовое приложение будет с Twitter Bootstrap, mustache.js, JQuery на клиенте и JavaScript Classic ASP + MVC на сервере.
Не буду врать, в 1996 году я не пробовал писать JavaScript-приложения для этой серверной платформы. Поскольку в клиентской части одностраничного JavaScript приложения нет никакой интриги в наши дни, далее будет описание только серверной части приложения.
Итак, к делу: Classic ASP в основном ассоциируется с VBScript. Но, как оказалось, JavaScript поддерживается в диапазонах, достаточных для построения простого многоуровнего приложения.
Традиционное Classic ASP приложение — это множество файлов с расширением ASP, в которых густо намешан HTML, CSS, клиентский JavaScript и серверный VBScript с MS SQL запросами. Хорошее, зрелое Classic ASP приложение обычно работает достаточно быстро и «не нуждается в обфускации» .
Однако мы пойдём другим путём. Раскидаем логику приложения по папкам:
Наше приложение будет иметь единственную точку входа — файл Router.asp. Идея заключается в том, чтобы сначала все запросы направить в Router.asp, а оттуда передавать управление в запрашиваемый модуль/функцию (Controller/Action в терминологии MVC). Для этого нужно установить 404 error handler в настройках IIS для нашего приложения (эта процедура автоматизирована в паре скриптов для IIS6/7, прилагаемых к тестовому проекту).
Идея проста до безобразия: если в ответ на запрос клиента IIS нашел статический ресурс (каталог/файл) — он будет обработан (код на сервере) и отдан. Если же ресурс не был найден – запрос завернется на Router.asp, который уже будет парсить запрос по правилам MVC.
Остальное просто — серверные контроллеры принимают параметры, производят операции над моделью (в тестовом приложении это просто операции над записями в базе данных MS SQL) и возвращают JSON результат на клиент.
Клиент объединяет результат и шаблон отображения (это View в нотации MVC) и обновляет документ.
Самое веселое здесь — это то, что MVC приложения очень удобно генерировать с помощью шаблонов. Решение, подобное тестовому приложению или даже в 10 раз больше, занимает от 5 до 25 минут от создания до запуска на тестовом сервере. Конечно, позже такое г-приложение всё равно нужно перепиливать, но это уже совсем другая история.
Я не вижу каких-то особых преимуществ технологии Classic ASP перед Node.js, сделавшим, наконец, JavaScript на сервере популярным, кроме, пожалуй, того факта, что кому-то вроде меня проще возиться со старым знакомым технологическим стеком, который здесь уже 19 лет.
Тестовое приложение, сгенерированное по модели, находится здесь: https://github.com/hardsome/helpdesk
Предупреждение для тех, кто будет пробовать запускать тестовое приложение у себя: самым большим затруднением при установке тестового приложения почему-то является строка подключения к базе данных. Я мало чем могу помочь — нужно уметь настраивать ODBC. Остальные настройки, связанные с установкой страниц по умолчанию и роутера, я упаковал в настроечные скрипты приложения. Тестовое приложение более или менее обкатано на Windows32 платформе, но может работать и на Windows64 при определенных умениях настраивающего.
Другие серверные JavaScript решения: http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaScript_solutions
Не буду врать, в 1996 году я не пробовал писать JavaScript-приложения для этой серверной платформы. Поскольку в клиентской части одностраничного JavaScript приложения нет никакой интриги в наши дни, далее будет описание только серверной части приложения.
Итак, к делу: Classic ASP в основном ассоциируется с VBScript. Но, как оказалось, JavaScript поддерживается в диапазонах, достаточных для построения простого многоуровнего приложения.
Традиционное Classic ASP приложение — это множество файлов с расширением ASP, в которых густо намешан HTML, CSS, клиентский JavaScript и серверный VBScript с MS SQL запросами. Хорошее, зрелое Classic ASP приложение обычно работает достаточно быстро и «не нуждается в обфускации» .
Однако мы пойдём другим путём. Раскидаем логику приложения по папкам:
- \Server\Controllers
- \Server\Models
- \Server\Views
Наше приложение будет иметь единственную точку входа — файл Router.asp. Идея заключается в том, чтобы сначала все запросы направить в Router.asp, а оттуда передавать управление в запрашиваемый модуль/функцию (Controller/Action в терминологии MVC). Для этого нужно установить 404 error handler в настройках IIS для нашего приложения (эта процедура автоматизирована в паре скриптов для IIS6/7, прилагаемых к тестовому проекту).
Идея проста до безобразия: если в ответ на запрос клиента IIS нашел статический ресурс (каталог/файл) — он будет обработан (код на сервере) и отдан. Если же ресурс не был найден – запрос завернется на Router.asp, который уже будет парсить запрос по правилам MVC.
Остальное просто — серверные контроллеры принимают параметры, производят операции над моделью (в тестовом приложении это просто операции над записями в базе данных MS SQL) и возвращают JSON результат на клиент.
Клиент объединяет результат и шаблон отображения (это View в нотации MVC) и обновляет документ.
Самое веселое здесь — это то, что MVC приложения очень удобно генерировать с помощью шаблонов. Решение, подобное тестовому приложению или даже в 10 раз больше, занимает от 5 до 25 минут от создания до запуска на тестовом сервере. Конечно, позже такое г-приложение всё равно нужно перепиливать, но это уже совсем другая история.
Я не вижу каких-то особых преимуществ технологии Classic ASP перед Node.js, сделавшим, наконец, JavaScript на сервере популярным, кроме, пожалуй, того факта, что кому-то вроде меня проще возиться со старым знакомым технологическим стеком, который здесь уже 19 лет.
Тестовое приложение, сгенерированное по модели, находится здесь: https://github.com/hardsome/helpdesk
Предупреждение для тех, кто будет пробовать запускать тестовое приложение у себя: самым большим затруднением при установке тестового приложения почему-то является строка подключения к базе данных. Я мало чем могу помочь — нужно уметь настраивать ODBC. Остальные настройки, связанные с установкой страниц по умолчанию и роутера, я упаковал в настроечные скрипты приложения. Тестовое приложение более или менее обкатано на Windows32 платформе, но может работать и на Windows64 при определенных умениях настраивающего.
Другие серверные JavaScript решения: http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaScript_solutions
