Опубликован: 10.12.2007 | Доступ: свободный | Студентов: 822 / 20 | Оценка: 5.00 / 5.00 | Длительность: 58:33:00
Лекция 3:

Статическое содержимое

3.1. Сравнение XUL и HTML

Зачем вообще кому-то понадобился XUL? Разве HTML недостаточно хорош? Разве им нельзя пользоваться для создания разметки? Наверняка таблицы HTML и стили CSS 2 - все, что нам нужно? Что ж, одного HTML уже недостаточно. На рисунке 3.1 показано сообщение общедоступного коммерческого web-приложения на основе HTML, в данном случае это крупный сайт туристической фирмы, занимающейся электронной коммерцией.

Проблемы пользовательского интерфейса, созданного на HTML

Рис. 3.1. Проблемы пользовательского интерфейса, созданного на HTML

Если взглянуть на это приложение с точки зрения проектирования пользовательских интерфейсов, то похвастаться здесь нечем. Прежде всего, это, кажется, третий раз, когда пользователю приходится подтверждать транзакцию. Кроме того, здесь очень легко что-нибудь испортить: любое случайное движение пользователя может прервать нормальную работу приложения. Наконец, пользователь не видит никакой обратной реакции. Как же ему догадаться, что операция завершилась? Да и вообще, это сообщение выглядит странно и сбивает с толку. Такое всплывающее окно - всего лишь извинения за неудачный пользовательский интерфейс. HTML мало подходит для создания приложений из-за того, что в каждом окне браузера уже существует набор определенных элементов управления, и пользователь может обратиться к ним в любой момент. К тому же из тегов HTML сложно создать надежную систему навигации.

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

Может показаться, что XUL по сравнению с HTML - второстепенная технология. Но это будет большим заблуждением. Каждое окно классического браузера (и всех остальных браузеров на основе Mozilla) - приложение, написанное на XUL; даже окошки, всплывающие по вызову alert() - такие приложения. Некоторые окна браузера, например, окно Навигатора, могут содержать большие области, заполняемые содержимым других типов (например, HTML-страницами), но каждое окно - прежде всего, XUL-приложение. Эти окна взаимодействуют с помощью общих DTD-файлов и скриптов с использованием взаимно доступных компонентов. Все, что мы видим, когда смотрим на браузер Mozilla, "обернуто" в XUL. Даже несмотря на то, что HTML хорошо известен, в платформе Mozilla это пассажир второго класса по сравнению с XUL.

Чтобы понять, как работает XUL в готовом приложении, представим себе сначала типичные случаи использования HTML. На web-страницах, написанных на HTML, есть формы, которые можно заполнять и отправлять, ссылки и динамический HTML. Собственно отправка данных формы, переход по ссылкам и объекты HTML предоставляются браузером. Они не существуют в HTML-документе, хотя некоторые HTML-теги тесно с ними связаны. HTML-документы предполагают, что браузер предоставит все эти необходимые сервисы. Для HTML почти все они определяются стандартами DOM.

Рассмотрим случай XUL. XUL-документ описывает все элементы графического интерфейса. Предполагается, что эти элементы для чего-то нужны. Технология XPCOM в Mozilla предоставляет компоненты, с которыми упомянутые выше графические элементы могут работать. Как и в случае HTML, содержимое документа и сервисы, предоставляемые браузером, используются вместе. XPCOM-компоненты обычно более эффективны, чем DOM-интерфейсы. Но если это необходимо, в XUL можно использовать и DOM-объекты.

Хотя и XUL, и HTML могут идентифицироваться строками с указанием пространства имен, между ними есть одно ключевое различие. Для XUL не существует DTD. Теги, составляющие словарь языка, происходят из разных источников внутри платформы Mozilla. Единой авторитетной спецификации нет.

То есть на самом деле нет точного или обязательного для выполнения соглашения о том, какие XUL-теги существуют. Это делает язык несколько аморфным. Так происходит, потому что каждая из технологий привносит свои теги, и в любой момент могут быть добавлены еще теги. Следовательно, "корректного" XUL-документа просто не существует. Тогда встает другой вопрос: все ли теги в этом документе делают что-то полезное?

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