Объекты XPCOM
16.4. Web-скрипты
Web-браузеры функционируют в среде, которая отличается от среды выполнения традиционных программ. В WWW нет таких сущностей как файл или имя файла. Вместо них имеются указатели ресурсов (URL), а также документы, представляющие эти ресурсы. Часто такие документы имеют сложную структуру и основаны на языке XML. Такая среда требует иного подхода к написанию скриптов, нежели описанный в разделах "Файлы и папки" и "Потоки".
Кроме того, браузеры работают с формирующимся стеком Web-протоколов, который можно условно назвать стеком XML. В основе этого стека лежит протокол HTTP, поверх которого реализуются различные прикладные протоколы. Стек протоколов XML позволяет организовывать транзакции, ориентированные на работу с данными, а не просто запрашивать и получать отдельные документы, как это делается при просмотре Web-страниц.
Этот еще не вполне устоявшийся стек протоколов определяется рядом стандартов и проектов стандартов. Ниже перечислены важнейшие из них, начиная с самого низкого уровня.
- XML и XML Schema. Эти стандарты определяют синтаксис, лежащий в основе всех прочих стандартов стека (за исключением протокола HTTP). Mozilla широко использует XML и поддерживает некоторые элементы XML Schema.
- HTTP. Этот протокол используется для установления транспортных соединений, по которым передаются сообщения протоколов более высокого уровня. Mozilla поддерживает HTTP.
- SOAP и XML-RPC. SOAP представляет собой формат для сообщений, основанный на XML. К синтаксису простого XML SOAP добавляет семантику, связанную со временем, именами, упаковкой данных, а также передачей сообщений. SOAP является механизмом, аналогичным традиционному RPC (удаленный вызов процедуры), применяемому в языках низкого уровня. Спецификация SOAP, принятая Консорциумом WWW, определяет два формата сообщений. Первый из них эффективно отображается на традиционный RPC, а второй основан на "чистом XML" и типах XML Schema. Первый формат иногда называют XML-RPC. Mozilla поддерживает оба стандарта.
- WSDL. Этот язык, тесно связанный с SOAP, предназначен для описания модулей (Web-сервисов). С его помощью клиентское ПО может анализировать и использовать сервисы SOAP, предоставляемые серверами. Mozilla поддерживает WSDL начиная с версии 1.4.
- UDDI. Это протокол, обеспечивающий службу имен для Web-сервисов подобно тому, как DNS является службой имен для TCP/IP. С помощью UDDI клиентское ПО способно динамически находить ранее неизвестные Web-сервисы. Mozilla не поддерживает UDDI, однако, поскольку этот протокол реализован поверх SOAP, разработчик может реализовать такую поддержку самостоятельно ценой некоторых усилий.
- ebXML (XML для электронного бизнеса). Этот стандарт, разработанный организацией OASIS (http://www.oasis-open.org) и ООН, добавляет уровень транзакций и идентификации бизнес-приложений поверх SOAP. Mozilla не поддерживает ebXML.
- Стандарты моделирования бизнес-процессов. Эти стандарты высокого уровня представляют собой попытки решить как общие, так и частные проблемы, возникающие при взаимодействии корпоративных приложений. В качестве примеров организаций, разрабатывающих подобные стандарты, можно назвать Коалицию управления документооборотом (Workflow Management Coalition) и Группу по открытым приложениям (Open Application Group). Mozilla не поддерживает подобных стандартов.
Вряд ли полномасштабная поддержка всех перечисленных стандартов будет когда-либо реализована в рамках платформы Mozilla, поскольку некоторые из них ориентированы на взаимодействие между корпоративными приложениями, а не между приложением и пользователем. Область применения стека Web-протоколов выходит далеко за рамки обычных задач клиентского ПО, например просмотра Web-страниц или получения электронной почты. Вместо каналов, которые являются стандартным средством работы с URL на платформе Mozilla, при работе с этими протоколами используются специализированные интерфейсы.
Приложение на платформе Mozilla может вообще не иметь собственного графического интерфейса. Например, оно может быть основано на инструменте xpcshell. Однако и в этом случае приложение может использовать развитые средства для работы с XML, входящие в состав платформы. Таким образом можно создавать серверы, реализующие некоторые идеи протоколов для бизнес-процессов. Например, такой сервер может перенаправлять получаемые документы XML в зависимости от их содержания.
16.4.1. URI, URL и URN
Формат URI и его специализированных разновидностей – URL и URN – определен документом RFC 2396. Предполагается, что это переносимые идентификаторы ресурсов, свободные от проблем, характерных для путей и имен файлов. В то же время URI (особенно URL) часто бывают громоздкими, что приводит к ошибкам пользователей при их наборе, а также частому использованию сокращенных форм URL.
Платформа Mozilla позволяет представить URI в виде простой строки JavaScript без потери переносимости. Однако для использования с интерфейсами XPIDL эта строка должна быть преобразована в объект. Наиболее общему объекту соответствует следующая пара XPCOM:
@mozilla.org/network/simple-uri;1 nsIURI
Для URL существует специализированный объект, который поддерживает типичные схемы URL, например http: and ftp:. Соответствующая пара XPCOM широко применяется при разработке на платформе Mozilla:
@mozilla.org/network/standard-url;1 nsIURL
Этот компонент также поддерживает nsIURI. Вообще, большинство компонентов, идентификатор контракта которых содержит подстроку uri или url, поддерживают оба этих интерфейса или один из них.
Часто требуется проверять корректность URL, введенного пользователем. В рамках платформы предусмотрено несколько инструментов проверки и исправления синтаксиса. Следующая пара XPCOM может использоваться при попытке исправить некорректный URL, введенный пользователем:
@mozilla.org/docshell/urifixup;1 nsIURIFixup
Этот интерфейс содержит метод createFixupURI(), который может применяться для работы с ключевыми словами, введенными в строку адреса браузера, а также сокращенными формами URL, например www.test.com или даже test.com вместо http://www.test.com. Соответствующий компонент docshell доступен как элемент объектной модели приложения в окне браузера Mozilla (подробнее об этом рассказано в разделе "<iframe>" "Окна и панели" "Окна и панели").
Второй способ исправления синтаксиса URL связан с использованием следующей пары XPCOM:
@mozilla.org/network/url-parser;1?auth=maybe nsIURLParser
Этот интерфейс позволяет выполнить разбор URL в соответствии с RFC 2396, причем в процессе могут быть исправлены многие типы характерных ошибок. Параметру, определяющему конкретный тип компонента, могут быть присвоены значения yes и no. Результатом будет использование другого, несколько отличающегося алгоритма разбора URL.
Наконец, можно задействовать метод resolve() базового интерфейса nsIURI. Если передать этому методу сокращенный (относительный) URI, будет возвращен полный (абсолютный) вариант, основанный на текущем URI самого объекта.
В любом случае, окончательной проверкой правильности URL является то, удается ли получить с его помощью нужный ресурс.
Специализированного объекта XPCOM, предназначенного для URN, не существует.
16.4.2. Загрузка файлов
Чтобы загрузить с удаленного сервера файл или документ, можно создать канал для нужного URI, а затем использовать полученный поток. Этот подход описан в разделе "Обработка содержимого: основные концепции". Однако существует и более простой способ загрузки – использование следующей пары XPCOM:
@mozilla.org/embedding/browser/nsWebBrowserPersist;1 nsIWebBrowserPersist
В качестве параметров этот интерфейс принимает URI или интерфейс Document DOM 1, а также объект nsILocalFile. С его помощью можно загрузить документ и сохранить его в виде файла при помощи единственного вызова метода.
Чтобы организовать асинхронную загрузку, во время которой могут выполняться другие задачи, нужно создать объект – слушатель или наблюдатель содержимого – на чистом JavaScript. В документации к большинству интерфейсов, например nsIChannel, описано, какие слушатели и наблюдатели поддерживаются данным интерфейсом. При загрузке очередной порции документа, которая будет передана слушателю или наблюдателю, можно обработать ее, сохранить или просто проигнорировать.
Наиболее распространенный способ создания объекта для обработки содержимого по частям – реализовать интерфейс nsIWebProgressListener. Любой объект, поддерживающий интерфейс nsIWebProgress, может зарегистрировать один или несколько таких слушателей, а многие другие интерфейсы принимают такой объект-слушатель в качестве аргумента инициализации. Существуют готовые объекты XPCOM, поддерживающие этот интерфейс, поэтому во многих случаях реализовывать его самостоятельно не понадобится.
Отслеживать состояние процесса асинхронной загрузки можно по- разному. В принципе, обработка поступающего содержимого и получение информации о состоянии процесса представляют собой две независимые задачи.
Наиболее простой способ отслеживать состояние загрузки – доработать обычный слушатель содержимого так, чтобы он при получении очередной порции данных определял, какая часть содержимого уже загружена. Такой слушатель не получает событий, связанных с завершением загрузки, и других управляющих событий; он лишь отслеживает состояние процесса загрузки.
Более удобный способ – с помощью чистого JavaScript создать объект, поддерживающий интерфейс nsIProgressEventSink, и передать его объекту, ответственному за загрузку. Такой объект-приемник (слушатель событий) получает информацию обо всех изменениях в состоянии процесса загрузки. Еще один вариант – создать на чистом JavaScript объект с интерфейсом nsIRequestObserver, и передать его объекту канала или транспорта. Такой наблюдатель получает только уведомления о начале и окончании загрузки, но не о ее промежуточном состоянии, приостановке или прерывании.
Более сложный способ отслеживания процесса загрузки предполагает использование объектов XPCOM, связанных с Менеджером загрузок Mozilla. Эти объекты могут применяться независимо от диалогового окна менеджера загрузок или вместе с ним. В последнем случае разработчик должен самостоятельно обеспечить взаимодействие объектов XPCOM с диалоговым окном. Независимо от использования диалогового окна этот способ может применяться лишь при загрузке файлов для последующего сохранения на диске. Отправной точкой для использования этого способа является следующая пара XPCOM:
@mozilla.org/download-manager;1 nsIDownloadManager
Единственный объект, созданный таким образом, одновременно управляет всеми текущими загрузками. Метод addDownload() этого объекта используется для создания нового объекта, поддерживающего интерфейс nsIDownload, для каждой загрузки.
Каждый такой объект, соответствующий отдельной загрузке, содержит всю конфигурационную информацию о ней и уведомляет Менеджер загрузок о ходе процесса. Конфигурационная информация передается объекту в момент его создания в виде аргументов метода addDownload(). В частности, последний аргумент, имеющий интерфейс nsIWebBrowserPersist, содержит информацию о том, каким образом должен быть сохранен полученный файл. Если этот аргумент существует, объект загрузки автоматически уведомляет Менеджер загрузок о состоянии процесса, а в случае отмены или прерывания загрузки Менеджер загрузок самостоятельно выполняет очистку памяти. Если же последнего аргумента не существует, приложение должно выполнить очистку памяти самостоятельно. Чтобы своевременно узнать о необходимости очистки, можно создать наблюдатели для каждого объекта загрузки.
Mozilla также поддерживает группы загрузки. Это вариант интерфейса nsIRequest, который позволяет одновременно работать с несколькими URL. Группы загрузки могут использоваться, если необходимо получать информацию о процессе загрузки нескольких файлов.
16.4.3. Файлы и типы MIME
Тип MIME для файла, ресурса с указанным URI или расширения файла может быть получен с помощью следующей пары XPCOM, представляющей сервисный объект-синглетон:
@mozilla.org/mime;1 nsIMIMEService
Прежде всего, этот объект обращается к информации о типах MIME, хранящейся в составе профиля пользователя. Если нужная информация не может быть получена таким образом, используются данные операционной системы или рабочей среды. В системах UNIX используются настройки среды GNOME, а не утилита file(1).
Метод launch() интерфейса nsILocalFile позволяет запустить исполняемый файл или открыть файл данных при помощи соответствующего приложения. Для вызова метода launch() нет необходимости знать что-либо о типе файла.
16.4.4. Отправка форм и загрузка файлов на сервер
Для отправки форм можно использовать объект AOM (объектной модели приложения) XMLHttpRequest. Работа с ним описана в разделе "Отправка форм" "Формы и меню" "Формы и меню". Он основан на следующей паре XPCOM:
@mozilla.org/xmlextras/xmlhttprequest;1 nsIJSXMLHttpRequest
Загрузка документов на сервер столь же проста. Следуйте рекомендациям раздела "Каналы" этой лекции и укажите адрес для загрузки, используя интерфейс nsIIOService. В качестве адреса для загрузки может быть указана программа, выполняемая на стороне сервера, в случае применения запроса HTTP POST или каталог FTP в случае использования протокола FTP. Создав канал, следует получить интерфейс nsIUploadChannel при помощи метода QueryInterface(), а затем передать этому интерфейсу поток ввода с содержимым файла, который должен быть загружен. Чтобы отправить содержимое, нужно снова получить интерфейс nsIChannel, и вызвать метод open() или asyncOpen(), как и при работе с любым объектом канала.