Microsoft представила новую технологию создания
В 1997 году, с появлением Internet Explorer 4.0, Microsoft представила новую технологию создания COM компонент получившую название скриплет-технология. Эта технология позволяет создавать COM компоненты средствами простых в использовании языков сценариев. Такие COM компоненты именуются скриплетами. Изначально скриплеты были ориентирован на создание компонент пользовательского интерфейса для Web страниц. Если вы знаете HTML и JavaScript, то вы легко освоите эту технологию.
При описании скриплета используются DHTML (расширение HTML) и любой язык сценариев поддерживающий ActiveX Scripting interface. Т. к. скриплет базируется на DHTML и используется в HTML документах, то он получил название DHTML скриплет. DHTML скриплеты поддерживаются браузерами Internet Explorer начиная с 4.0 на любых платформах (Win, Mac, Unix), т. к. в открытой архитектуре скриплета нет ничего ограничивающего его в пределах Win32.
Скриплет-технология получила развитие и позднее появился серверный скриплет, но в этой статье мы остановимся на рассмотрении DHTML скриплета и для экономии места будем его называть просто скриплетом.
Пакет INN, автором которого является Рич Солц (Rich Salz), представляет полнофункциональный пакет программ для построения сервера новостей. Для взаимодействия с другими машинами используется стандартный протокол NNTP. Как и любой сервер новостей, система INN предполагает наличие по крайней мере одного поставщика новостей, а также наличие хостов, которым новости отсылаются (NNTP соседей называют newsfeeders). Кроме того, у сервера имеются клиенты, которые через "читалку новостей" обращаются к серверу для чтения и/или публикации новостей.
Статьи (articles) в Usenet классифицируются по телеконференциям, которые подобно каталогам файловой системы имеют иерархическую структуру. Новости хранятся на сервере в дереве каталогов, имена которых формируются путем замены точек слэшами ("/"). Например, статьи из группы relcom.fido.ru.unix хранятся в каталоге /var/news/spool/articles/relcom/fido/ru/unix.
Начнем с простого примера: вы заполняет форму в HTML странице. Если некоторые поля заполнены неверно, то после отправки формы, сервер, скорее всего, предложит исправить неверные значения. После исправления вы повторно отправляете форму и так до тех пор, пока все данные не будут заполнены правильно.
Или предположим, что при перезагрузке страницы необходимо сохранить состояние переключателей в HTML странице или значения глобальных переменных в скрипте. Для этого приходится идти на манипуляции с HTML (например, hidden поля в форме для передачи дополнительных данных) или создавать сложный скрипт взаимодействия.
В общем случае, верным будет следующее утверждение: для обеспечения интерактивного взаимодействия с сервером необходимо часто перегружать страницу.
Как нетрудно догадаться Remote Scripting решает описанные выше проблемы. Так что же такое Remote Scripting.
Со времени опубликования в 1982 г., стандарт RFC 822 определил и полностью или частично внедрил формат текстовых писем в почтовой системе Internet. Но с расширением его использования, обнаружился ряд ограничений, заметно ограничивающих удовлетворение пользовательских потребностей. В частности, возможность пересылки нетекстовых данных, например, аудио и графики, посто не была упомянута в RFC822, описывавшем лишь формат текстовых сообщеий. И даже в случае текста, RFC 822 обошел вниманием нужды пользователей, использующих расширенный набор символов, что характерно для азиатских и большинства европейских языков. Итак, требовалась дополнительная спецификация. Основное ограничение RFC822 - относительно короткие строки и 7-битная символьная таблица. Пользователям дляотправки нетекстовых данных приходилось конвертировать тело своего письма в 7-битную форму с помощью UUENCODE, BINHEX и др.
Более очевидными стали ограничения RFC 822 при разработке почтовых шлюзов между хостами, использующими стандарт RFC822 и хостами, использующими стандарт X.400. X.400 имеет механизмы для включения нетекстовых данных в тело письма. В настоящее время стандарты для перевода почтовых сообщений из X.400 в RFC822 предполагают, что нетекстовые части тела письма должны быть сконвертированы (но не закодированы) в ASCII формат, либо должны быть "выброшены" из письма с уведомлением об этом получателя. А потеря информации крайне не желательна для пользователя.
MIME разработан как расширяемый механизм с расчетом на то, что набор пар content-type/subtype будет расти со временем. Некоторые другие поля заголовка MIMЕ, включая имена наборов символов, также , вероятно, получат большее число возможных значений. С этой целью MIME определяет процесс регистрации через Internet Assigned Numbers Authority (IANA), как центр регистрации этих значений. Описание процесса регистрации можно найти в приложении E RFC 1521.
Скриплет - это новая технология позволяющая создавать COM компоненты средствами простых в использования языков сценариев, для этого подходит любой язык сценариев поддерживающий MS ActiveX Scripting интерфейс. Скриплет появился в 1997 году с выходом в свет Internet Explorer 4.0 и изначально был ориентирован на создание UI (user-interface) компонент многократного использования для Web страниц. Все что необходимо было знать для создания скриплета - это DHTML и какой-нибудь язык сценариев (JScript, VBScript). Т. к. этот скриплет базировался на DHTML и использовался в HTML документах, то он получил название DHTML скриплет. DHTML скриплет обладает богатыми возможностями для создания компонент пользовательского интерфейса, но не обеспечивает многоцелевого назначения компонентной архитектуры вне браузера. Для снятия этого ограничения был разработан серверный скриплет, далее именуемый просто скриплетом.
В результате мы имеем два варианта:
- DHTML скриплет, базирующийся на DHTML и используемый для создания UI компонент.
- Скриплет основанный на XML и языке сценариев, являющийся полноценной COM компонентой, о котором и пойдет речь в данном обзоре.
