Стоит сказать, что это может быть связано не только с тем, что от верстальщиков требуют зачастую не то, что изначально входило (или, по крайней мере, должно было входить) в его обязанности, но и с тем, что часто люди данной профессии обладают некоторыми качествами, которые находятся на стыке других специальностей. Именно поэтому часто происходит искажение предназначения профессии и смещение целей и задач в некую иную область знаний.

Верстальщик в себе

Чем же занимается верстальщик? Нетрудно предположить, что он размечает текст с помощью особого формата разметки оного, который называется HTML. Вместе с этим, он сразу же определённым образом преобразует внешний вид написанной разметки из внешнего вида по умолчанию в какой-либо заданный (задание, идея, визуальный пример, сопоставление, копирование и другие методы). Почему именно текст?

Изначально HTML применялся именно для представления текста в определённом визуальном стиле. Это было неким искажением, деформацией сути HTML, который должен представлять не стилистическое, но смысловое содержание текста. Обычный текст состоит из языковых символов, символов пунктуации, слов, предложений, а также параграфов, подразделов, разделов и глав в более крупном представлении. HTML является прямой надстройкой над текстом. Он не заменяет текст, не пытается его мимикрировать. HTML расширяет возможности текста. Разумеется, в определённой степени этот язык разметки в смысловом отношении деформирован тем, что он применяется именно в информационных технологиях. Этим обусловлена его угловатая структура и подобный же внешний вид.

С помощью HTML можно делить текст на блоки и оперировать последними как индивидуальными сущностями; отчётливо задавать границы параграфов, отдельных участков текста, расставлять лексические акценты в определённых местах, обозначать заголовки, а также различную внешнюю информацию относительно размеченного текста. Именно этим и занимается верстальщик: обычный текст в его руках становится пригодным для машинной обработки. Машине будет понятно, что хочет человек сказать данным текстом. Разумеется, если другой человек так же владеет данным форматом разметки хотя бы на уровне чтения, то он точно таким же образом сможет извлечь из размеченного с помощью HTML текста гораздо больше информации, нежели из аналогичного же текста, но без разметки. Верстальщик-писатель и верстальщик-читатель поймут друг друга чуточку лучше, чем писатель и читатель. Это обусловлено и тем, что HTML, как надстройка, несёт дополнительную информационную начинку, и тем, что HTML более строг, нежели любой естественный язык, на котором происходит общение людей.

Верстальщик должен не просто разметить текст. Он должен сделать это как можно более правильно, избегая двусмысленностей и неправильного применения правил разметки. Если правила разметки нарушаются, то нарушается и диалог верстальщик-машина и верстальщик-верстальщик. От этого диалога зависит многое, в частности, успех совместной деятельности как первой пары существ, так и второй (что, в сущности, выражается такими действиями, как парсинг и ручное чтение). К сожалению, правила разметки зачастую сами бывают противоречивыми, либо неполными, дающими возможность по-разному трактовать определённые элементы процесса. Этот недостаток всегда будет присутствовать, потому что составитель-человек подобных правил может лишь асимптотически приближаться к максимально однозначному варианту набора правил.

Подобными правилами для людей, преобразующих обычный текст в текст, снабжённый надинформацией, являются спецификации. Как уже упоминалось выше, они не могут являться полными, поэтому находятся в состоянии постоянного движения, совершенствования. Спецификации определённым образом похожи на организм, который постоянно развивается. Точнее сказать, проходит через ряд мутаций. Мутации бывают как положительными, так и отрицательными. Это значит, что процесс развития спецификации может быть как поступательным, так и деструктивным. История знает случаи, когда HTML переживал не лучшие времена в результате недопонимания его основного предназначения (либо в результате подмены смысла языка разметки на какой-то иной, выгодный определённой стороне). Какие-то части спецификации выживают после ряда мутаций, другие уходят в небытие, закрываются, перестают развиваться. Что произойдёт с той или иной частью спецификации (или спецификацией в целом) решает определённый круг доверенных людей, который заинтересован в развитии первой. Что движет отдельными людьми, входящими в данный круг, — это отдельный, третий вопрос.

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

Отсюда следует, что верстальщик должен не только правильно применять правила, но и максимально корректно их интерпретировать с учётом предыдущего опыта, здравого взгляда на систему с высоты птичьего полёта. Это требует от верстальщика пространственного мышления в контексте разложения какой-то большой системы на отдельные простые сущности (декомпозиция), распознавание в этих сущностях необходимых паттернов, необходимых для текущей задачи, с отсеиванием ложных ответвлений (анализ), а также правильное применение полученных паттернов.

Это значит, что с минимальным набором усилий из максимального набора известных правил верстальщик извлекает нужное и применяет его к текущему компоненту (текущей задаче). Если всё сделано правильно, на выходе получается корректный и правильно оформленный HTML-документ, который чётко отражает какую-то идею. Настоящий HTML-документ является самодостаточным. Настоящий верстальщик создаёт самодостаточные, простые, гибкие документы, которые можно читать, не используя для этого специальные средства.

Верстальщик как программист

Определённые эмоции вызывает тот факт, что верстальщики сейчас занимаются не только разметкой текста, но и его стилизацией. Для этого используется CSS. Максимально правильным историческим решением было решение о переносе различных стилистических визуальных функций и средств разметки HTML в отдельный язык. Чаще всего CSS сосуществует с HTML, является его постоянным партнёром, который сопровождает его на всех светских мероприятиях и выходах в свет.

CSS позволяет вмешиваться в линейное течение текста, изменять его положение, оперировать блоками текста, графикой, шрифтами, цветом, эффектами. Это вмешательство позволяет делать текст более презентабельным, представлять его в каком-либо ином (например, ранее заданном) визуальном виде. Чтобы достичь подобных результатов, сам CSS представляется как набор отдельных свойств, которые воздействуют на определённые элементы по ключевым параметрам (имя элемента, класс элемента, его идентификатор). CSS обладает возможность дифференцировать элементы ещё и по их расположению в иерархии. С помощью этих двух ключевых свойств и создаётся визуально-стилистическое представление страницы.

Ключевой функцией здесь является опять же декомпозиция: необходимо правильно заметить повторяющиеся и уникальные элементы на странице (1), определить где именно они могут находиться в документе (или других документах) в иерархии всех элементов (2). В результате (1) необходимо выбрать соответствующие классы, а по (2) строится каскад свойств.

Очень важно здесь правильно наметить, на каких элементах необходимо делать CSS-классы, чтобы подобные элементы (HTML и CSS, относящийся к этому элементы) являлись переносимыми на другие страницы без влияния каких-то иных элементов. Верстальщик должен максимально инкапсулировать и абстрагировать то, что он стилизует. Элемент+стиль в связке должны образовывать прочную пару и выдерживать сторонние эффекты. Такая пара должна быть самодостаточной в рамках одного или нескольких документов, Любое изменение стилей вне данной пары по возможности не должно оставлять след на отображении пары. В этом состоит основная задача верстальщика как программиста: определить независимые участки разметки и написать для них независимые (возможно, взаимозаменяемые) CSS-свойства, которые будут представлять из себя обработчики разметки.

Если верстальщик неправильно выделит ключевые элементы (кейфреймы) для стилизации на странице, то любое изменение стилей повлечёт за собой деградацию внешнего вида страницы: CSS не будет стабильным. Нужно максимально правильно извлечь информацию о задаче, разделить задачу на максимально мелкие независимые друг от друга блоки, после этого реализовывать отдельные такие блоки, обеспечивая отсутствие прямых связей с другими (кроме исключительных случаев). В этом случае всё очень сильно походит на работу обычного разработчика, который преобразует задачу в набор независимых участков кода, используя определённую парадигму написания кода.

К слову, в вёрстке тоже можно проследить определённый набор паттернов, которые используются теми или иными людьми. Паттерны — это не какие-то техники, которые применимы к любым документам и связкам HTML+CSS, а полноценный стиль написания отдельных блоков кода. В этом случае верстальщик при взгляде на исходную задачу сразу способен увидеть соответствующую ему разметку. При этом исходный материал разбивается на блоки, следуя определённому паттерну, определённой системе, в которой работает данный верстальщик-разработчик.

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

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

У каждого человека есть свои приёмы и методы работы с идеями. Художники рисуют наброски на полях в любых тетрадях, прозаики самые тонкие свои мысли записывают себе в блокнот, учёные оставляют след мелом на доске. Большинство приёмов созданы для того, чтобы обеспечить последующую наглядность идеи, материализовать её и помочь себе не забыть о ней в будущем, если придётся отложить эту идею в долгий ящик. Сегодня мы рассмотрим ещё один подобный приём, с помощью которого будет гораздо проще запоминать и структуризировать идеи, заключающиеся в создании сайтов или наборов связных страниц в интернете.

Суть метода

Данный приём стоит назвать не иначе, как проектирование интерфейса методом дерева. Есть и название чуть большее по длине: метод составления карты сайта для прототипизации процесса его разработки. Конечно, можно придумать сколь угодно много названий, суть от этого меняться не будет. Каждое название лишь отражает суть приёма с той или иной стороны, дополняя и поясняя предыдущие.

Метод дерева применяется на самых ранних этапах воплощения сайта или набора страниц. Это, пожалуй, самое начало проектирования интерфейса. К тому же, он является очень простым: для него не нужно никаких специальных утилит (однако они могут быть полезны для ещё большей степени визуализации дерева): достаточно обычной бумаги, блокнота или, например, одной Writeboard в вашем Basecamp.

Для того, чтобы хорошо ориентироваться в иерархичных связях документов, читатель должен хорошо себе представлять дерево. Посмотрим на пример такого дерева и на его основные элементы:

Каждое дерево имеет один корень, а все остальные элементы (узлы) уже являются его потомками, прямыми или косвенными. Если элементы находятся на одном уровне относительно своего родительского узла, говорят, что они обладают одним и тем же уровнем (подразумевается уровень вложенности, уровень удалённости от родительского элемента). В примере выше два выделенных курсивом элемента находятся на одном уровне; они равноправны между собой в смысле иерархии.

Иерархия и связи между страницами

Проектирование интерфейса в подобной текстовой форме даёт самое примитивное представление об иерархии будущего сайта, позволяет упорядочить мысли проектировщика и облегчить ему работу в командном режиме. Проще всего на прототипе карты сайта (по сути, это она и есть) выявлять иерархию страниц и разделять их по степени значимости и дистанцирования относительно самых главных страниц, которые доступны по одному щелчку мышки после попадания на сайт. Таким образом, в самом простом случае каждый следующий уровень в дереве страниц — это один дополнительный щелчок мышки, чтобы на него попасть. Исходя из этой информации составленную ранее карту можно легко оптимизировать и перестроить таким образом, чтобы вынести самые важные элементы на уровни выше, а необязательные элементы поместить вниз.

С помощью ручной сортировки страниц сайта можно получить довольно неплохую структуру будущей навигации на сайте с точки зрения значимости страниц и их дальности относительно точки входа на сайт (таковой может служить, к примеру, главная страница).

Стоит понимать, что дерево страниц показывает только структурные и последовательные взаимоотношения между страницами, которые находятся в прямой зависимости друг от друга. В конечном итоге между двумя любыми произвольными страницами может быть установлена связь (обычно в качестве такой связи выступают ссылки), которая не будет укладываться в рамки иерархии. Такая связь необходима для соотнесения между собой разрозненных страниц или страниц, которые в дереве удалены друг от друга на несколько уровней.

Составление дерева страниц

Рассмотрим составление карты усреднённого блога. В начале наше дерево будет состоять лишь из корня:

У каждого блога есть определённый постоянный набор страниц, который мы сразу же можем отобразить на карте:

Разумеется, данные страницы являются основными, к ним должен быть предоставлен непосредственный доступ, чтобы пользователю не приходилось совершать лишние щелчки мышкой в поисках самого главного. Кроме этого, очевидным является факт некоторой соотносимости архива публикаций и списка публикаций. По сути, это одно и то же, правда с разной степенью настраиваемости навигации и, возможно, в разных визуальных представлениях. Из этого следует, что можно эти разделы объединить.

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

Можно обходиться и без виртуальных страниц, указывая в скобках к существующим всю необходимую информацию.

Вдруг мы передумали и решили всё-таки вернуть страницу архивов. Как быть? Если мы сделаем её на том же уровне, что и список всех публикаций, то получится дублирование информации. Однако если мы сделаем вложение первого во второе, тогда мы обеспечим как быстрый доступ, так и цельность навигации. Можно пойти ещё дальше и разбить список публикаций на две сущности, одновременно указывая страницу с постраничной навигацией как страницу списка публикаций по умолчанию.

После этого мы можем уточнить списки публикаций, чтобы ориентироваться было в них удобнее:

Теперь можно заметить, что список публикаций, по сути, является своего рода ориентиром по всем публикациям в блоге. Функция поиска также является ориентиром: она помогает искать по тексту оставленных записей, поэтому стоит её объединить со всем списком.

А если мы хотим добавить административный центр для управления записями? Деревья страниц нужно стараться делать минимальными по своему размеру, лучше всего их дробить по важным, ключевым частям сайта, которые отличаются как по своей репрезентации и преследуемым целям, так и по своей реализации. Именно поэтому вместо полного отражения административного центра в карте выше, мы сделаем ссылку на другое дерево. Ссылки обычно помечаются звёздочкой.

Попробуйте самостоятельно реализовать карту административного центра для усреднённого блога с собственными мыслями и идеями, а ниже будет приведена его минимальная карта:

У подобных текстовых карт существует одно досадное упущение: на них трудно проследить связи между разнесёнными на несколько уровней страницами или иные неявные связи. Для восполнения этого недостатка следует воспользоваться более мощными инструментами, нежели простыми текстовыми записями. Вот так, например, может выглядеть дерево страниц для данного блога:

Данные карты рисуются уже в свободном режиме и правила текстовых деревьев страниц на них уже не распространяются.

Представление отдельных страниц деревом

Помимо рисования сайтов, с помощью дерева можно представлять и отдельные страницы. Подобный способ подойдёт для обеспечения наглядного представления имеющейся информации на определённой странице.

Попробуем реализовать главную страницу блога. Начнём с тех элементов, которые обычно присутствуют всегда:

Обычно именно такие блоки присутствуют на большинстве сайтов. Теперь добавим логотип и навигацию к шапке страницы, продублируем навигацию в подвале, добавив туда информацию о защите прав:

После того, как стандартные элементы интерфейса добавлены, можно перейти к элементам содержимого, которое в нашем случае состоит из списка публикаций и постраничной навигации:

После построения подобного дерева элементов сразу видно, что нужно переместить, что добавить, а что и вовсе убрать. Попробуем реализовать дерево для отдельной публикации (благо в дереве выше оно вынесено в отдельное дерево с помощью звёздочки):

Подобный способ представления сразу же даёт подсказку верстальщикам: видно, на какие блоки следует разделить страницу и какими именами можно их назвать, причём такие названия всегда будут семантически верными.

Если использовать инструменты для визуального составления деревьев, то может получиться что-то подобное:

Практическая реализация карт

На практике реализация подобной навигации может представлять из себя всё, что угодно. Это могут быть как отдельные страницы на сайте, связанные между собой ссылками, так и динамически изменяемая с помощью JavaScript одна страница, объединяющая в себе и поиск, и архив публикаций по датам.

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

1. Страница обязательно должна содержать ссылки на своих потомков первого уровня;
2. Страницы первого уровня относительно корня дерева составляют костяк навигации, поэтому к ним должен быть обеспечен повсеместный доступ со всех страниц на сайте. Исключениями могут являться служебные страницы (страницы ошибок и иных системных сообщений);
3. Страницы одного уровня следует связать либо с помощью сквозной навигации (это страницы первого уровня относительно родительской страницы), либо с помощью неявных ссылок.

При соблюдении этих простых правил, у пользователя будет много меньше шансов потеряться.

Навигация на сайте — это один из самых ключевых элементов при его реализации. Не следует продумывать навигацию в самый последний момент проектирования, а тем более разработки сайта. Навигация на сайте — это как сюжетная линия в книжках, которая красной нитью проходит по всему рассказу. Интереснее ведь читать рассказ, где эта нить не разорвана в некоторых местах, не завязана узлами и является довольно прочной, чтобы за неё зацепиться. Правда?

Идея напрямую связана с CSS-селекторами. Все привыкли, что селекторы помогают нам выбирать объекты. Это логично, потому они так и называются. Селекторы — это один из способов упрощения навигации по дереву элементов в документе. Однако они могут быть полезны не только в качестве гидов, но и в качестве направляющих при создании новых элементов в документе.

Селекторы добавления элементов

Когда мы с помощью JavaScript создаём элементы в документе, мы используем функцию document.createElement. Данная функция в качестве аргумента принимает имя элемента, который следует создать. После этого мы можем вручную установить необходимые параметры элемента: CSS-класс, уникальный идентификатор и другие. Позже, если понадобится, мы создаём новые элементы и вкладываем в уже созданный, выстраивая себе таким образом локальное дерево элементов.

Такая процедура зачастую утомительна, отнимает множество времени и заставляет писать десяток однотипных строк кода. Сегодня мы постараемся автоматизировать процесс создания локального дерева элементов, а использовать для этого мы будем селекторы.

Конечно, все CSS-селекторы нам ни к чему, поэтому мы оставим только контрольные: по CSS-классу, по уникальному идентификатору элемента и по его имени, конечно. В итоге наш селектор будет иметь такой общий вид (части в квадратных скобках не являются обязательными):

имя[#идентификатор][.класс]

К тому же, можно описывать несколько селекторов через пробел для создания вложенных друг в друга элементов с необходимыми именами классов и идентификаторами.

Как определять селекторы

Перед тем, как реализовывать нашу основную функцию, потренируемся на поиске селекторов в строке. Создадим простую функцию, с помощью которой строка в вышеприведённой нотации будет преобразована в массив селекторов.

//Мы продолжаем в комментариях к этому коду.
//Выясним, как работает эта функция.
function parse_selector(raw_selector)
{
	//Для начала создадим массив всех селекторов.
	//Их количество может быть разным и всех их мы будем хранить здесь.
	var selector = [];
	//Получаем все встречающиеся в строке важные части.
	//Они будут последовательно расположены в массиве raw_selector.
	raw_selector = raw_selector.match(/(?:#|\.)?\w+/g);
	//Проходимся по вновь собранным данным.
	for (var i = 0, j = -1, n = raw_selector.length; i < n; i++)
	{
		//Извлекаем из строки первый символ (он для нас контрольный),
		//а также остальную часть строки (контрольный символ не входит в значение конструкции).
		var type = raw_selector[i].substring(0, 1), content = raw_selector[i].substring(1);
		//Для каждого типа заполняем соответствующее поле в массиве.
		switch(type)
		{
			//Идентификатор элемента
			case "#":
				selector[j]["id"] = content;
			break;

			//CSS-класс элемента
			case ".":
				selector[j]["class"] = content;
			break;

			//Имя элемента
			default:
				//Начинаем новый элемент прямо здесь
				selector[++j] = {};
				selector[j]["element"] = raw_selector[i];
			break;
		}
	}

	//Пользователь получает такой массив на выходе:
	// [{"element" : имя, "class" : класс, "id" : идентификатор},
	//	{"element" : имя, "class" : класс, "id" : идентификатор}...]
	//Последовательность элементов совпадает с их вложенностью в друг друга. 
	return selector;
}

Данная функция — это базис для того, чтобы работать с простыми селекторами. Разумеется, она поддаётся расширению (например, добавлению новых типов контрольных точек в селекторах или даже использованию псевдоселекторов), но мы на данный момент рассматриваем концептуальную, самую простейшую из всех возможных реализаций.

Попробуем теперь рассмотреть, как должна работать функция создания локального дерева элементов по селектору.

Функция локального дерева

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

Рассмотрим на примере. Пусть нам дан следующий селектор:

div#element div.inner em#deep.class

В результате выполнения нашей функции, мы должны получить следующее локальное дерево:

<div id="element">
	<div class="inner">
		<em id="deep" class="class"></em>
	</div>
</div>

В соответствии с выясненными нами требованиями, функция должна возвратить такой объект, который бы дал нам доступ к каждому из элементов. Как такое сделать? Довольно просто: функция будет возвращать ассоциативный массив, ключами в котором будут частичные селекторы от общего, переданного в функцию. Для нашего примера частичный селектор самого первого элемента div будет равен div#element, а вложенного в него — div#element div.inner. Таким образом можно обеспечить доступ ко всему построенному дереву.

Более того, мы создадим в возвращаемом функцией массиве ещё два ключа для быстрого доступа к корневому и наиболее вложенному созданным элементам — root и last.

Мы знаем всё что нужно для реализации функции.

//Функция принимает два аргумента на входе.
//Первый — это селектор в виде обычной строки.
//Второй — это корневой элемент по умолчанию.
//Второй аргумент не обязателен, но если он задан,
//то всё дерево будет являться вложенным в заданный элемент.
function create_element_by_selector(selector, current)
{
	//Создаём массив для хранения элементов и строку частичного селектора.
	var elements = {}, active = "";
	//Если текущий элемент задан (аргумент current), то используем его как корневой.
	if (current != null)
	{
		elements["root"] = current;
	}
	//Как и в первом блоке кода, выделяем ключевые части.
	selector = selector.match(/(?:#|\.)?\w+/g);
	//Проходимся по собранным элементам
	for (var i = 0, j = -1, n = selector.length; i < n; i++)
	{
		//Извлекаем из строки первый символ (он для нас контрольный),
		//а также остальную часть строки (контрольный символ не входит в значение конструкции).
		var type = selector[i].substring(0, 1), content = selector[i].substring(1);
		//Создаём своеобразный автомат.
		switch(type)
		{
			//Добавляем текущему элементу идентификатор
			case "#":
				current.setAttribute("id", content);
			break;

			//Добавляем текущему элементу CSS-класс
			case ".":
				current.className = content;
			break;

			default:
				if (current == null)
				{
					//Если текущий элемент не задан, создаём его и определяем как корень.
					current = document.createElement(selector[i]);
					elements["root"] = current;
				}
				else
				{
					//Если задан, создаём вложенность.
					active += " " //Пробел необходим для обособления элемента в селекторе.
					elements[active] = current; 
					current = current.appendChild(document.createElement(selector[i]));
				}
			break;
		}
		//Добавляем к частичному селектору содержимое обработанной строки.
		active += selector[i];
	}

	//Так как последний элемент остался необработанным,
	//добавляем указатель на него после цикла.
	elements[active] = current;
	//Не забываем добавить указатель на самый вложенный элемент.
	elements["last"] = current;

	//Возвращяем всё на радость пользователю.
	return elements;
}

Функция готова. Давайте попробуем её в действии на примере. Положим, имеем следующий элемент:

<div id="element"></div>

Используем нашу функцию и создадим в нём необходимую вложенность:

var local_tree = create_element_by_selector("div span.inner a#new", document.getElementById("element"));

В итоге получим следующее локальное дерево:

<div id="element">
	<div>
		<span class="inner">
			<a id="new"></a>
		</span>
	</div>
</div>

Мы создали переменную local_tree, с помощью которой можем обращаться к элементам дерева. Установим вложенному элементу span какой-нибудь CSS-класс, а ссылке зададим направление и содержимое:

//Добавляем CSS-класс нужному элементу
//Обратите внимание, что частичный селектор должен содержать все ключевые конструкции.
local_tree["div span.inner"].className += " deep";

//Управляем ссылкой (она самая-самая вложенная в нашем дереве)
local_tree["last"].href = "http://enumerate.ru/";
local_tree["last"].innerHTML = "Я — ссылка, а ты нет";

Заключение

Данное исследование являлось прикладным по отношению к разрабатываемому сейчас CTS. Автор считает, что подобные исследования, хоть порой и не являются новаторскими, однако позволяют по-новому взглянуть на привычные вещи и даже переосмыслить их. Даже если и существуют альтернативные способы решения проблемы, это не значит, что данный способ не имеет право на существование: любое исследование — это и есть основа существования многогранных решений повседневных проблем. Постарайтесь подойти к этому с философской точки зрения.

В 105 выпуске уже был обозначен факт, что человеку свойственно всё упорядочивать и систематизировать. Сегодня пришло время упомянуть ещё одно важное человеческое качество: стремление к унификации, созданию единого образа окружающего нас мира. Однако унификация не заканчивается на живой природе, она переносится и на творения человека. Что бы мы не создали, мы не хотим создавать вновь что-то, пусть даже слабо похожее на уже сотворённое, — гораздо мудрым выбором будет для нас использование или приспособление уже созданного.

Сегодняшний разговор в очередной раз пойдёт о CSS, а точнее об одном из его нераскрытых возможностей, которое способно вывести CSS на серверную, тёмную для него сторону силы.

Лирическое преступление

Отходя от шока после прочтения столь необычного внетематического введения, перейдём непосредственно к сути теоретических изысканий. Сегодня мы будем применять CSS на сервере, а не на клиенте. Что же это значит? CSS будет выступать для нас не в роли Каскадных Таблиц Стилей, а в роли… Чего-то иного. Давайте разбираться вместе, чего же.

Для разборок нам потребуется самый обычный XHTML-документ, над которым мы будем экспериментировать все следующие часы.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="ru" xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<title>Экспериментальный блог</title>
		<link rel="stylesheet" type="text/css" href="stylesheet/screen.css" media="screen" />
	</head>
	<body>
		<h1>Экспериментальный блог</h1>
		<!-- Начало статьи -->
		<div id="article">
			<h2>Название статьи</h2>
			<p>Первый параграф статьи.</p>
			<p>Второй параграф статьи.</p>
			<h3>Подраздел статьи</h3>
			<p>Первый параграф раздела.</p>
			<div class="tags">
				Метки:
				<ul id="tags">
					<li>метка</li>
					<li>метка</li>
					<li>метка</li>
				</ul>
			</div>
		</div>
		<!-- Окончание статьи -->
	</body>
</html>

Перед нами самый обычный документ, который мы создали для наших экспериментов. Мы видим, что он чудесным образом был уже стилизован, так как мы разглядели подключение CSS-файла. Такой документ можно прямо сейчас открыть в браузере и увидеть его во всей красе. Просто чудеса.

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

Ранее в записи уже упоминался серверный CSS. Пришло время окончательно раскрыть это понятие. Прямо сейчас мы теоретически создадим и оформим новый формат на основе CSS. Наш формат позаимствует у своего предшественника структуру и душевную составляющую, а остальное мы добавим ему самостоятельно. Серверный CSS давайте лучше будем называть Каскадными Таблицами Трансформации — CTS. Далее вы поймёте, почему мы их так назвали.

CTS и будет нашим шаблонизатором. Его главная задача — связывать динамические данные со статической структурой XHTML-документа. Посмотрим, как CTS будут справляться с ней.

Осуществление связывания

CSS нам одолжил свою структуру, поэтому синтаксис CTS-файлов будет полностью совпадать с синтаксисом CSS-файлов. Но почему же мы назвали CTS именно CTS? Всё очень логично: он будет заниматься трансформацией исходной структуры документа, её преобразованием и даже искажением. Исходный XHTML-документ после применения CTS не будет похож сам на себя до этой операции. Уже слышны нарастающие крики: «Документ уже не тот!» Подождите, пока ещё тот.

Давайте вспомним, как мы осуществляем стилизацию документа посредством CSS. Для этого нам доступны так называемые селекторы, с помощью которых мы можем попасть в любой уголок нашего документа. Это наш GPS-навигатор по документу. CSS-селекторы можно создавать на основе трёх контрольных структур: имя элемента в документе, уникальный идентификатор элемента и CSS-класс документа. Подробнее с селекторами вы можете познакомиться в соответствующей рекомендации W3C, а мы посмотрим самые простые примеры различных селекторов:

/* Выбор элементов по названию */
div { }
/* Выборка по уникальному идентификатору */
#content { }
/* Выбор элементов по установленному CSS-классу */
.article { }

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

/* Изменяем стиль отображения элемента в браузере */
.article
{
	margin: 1em 0;

	background: #efefef;
	color: #222;

	font-size: 1.2em;
}

Селектор и набор свойств вместе составляют CSS-правило, которых в документе можно записать сколько душе угодно (но лучше не злоупотреблять).

Теперь представим, что вместо браузера у нас другая программа — шаблонизатор CTS, а вместо визуального представления — структура документа. Таким образом, мы приходим к определению CTS: он предназначен для управления структурой документа на стороне сервера с помощью заданного набора свойств.

В CSS мы имеем предопределённый набор свойств, с помощью которых мы управляем визуальной составляющей документа. В CTS мы должны создать точно такой же набор свойств, который должен реализовывать по меньшей мере следующий набор операций:

• Управление содержимым элементов: добавление текста к концу элемента, установка текста в начало элемента или на указанное в текст местоположение (ключевая точка);
• Манипуляции с атрибутами: добавление новых атрибутов, возможность изменения и удаления существующих;
• Управление элементами: сокрытие (удаление из дерева) элементов при определённых условиях, добавление новых элементов в дерево при определённых условиях или без них;
• Работа с CSS-классами: специальные свойства для изменения содержимого атрибута class;
• Поддержка операций цикла и дополнительных селекторов для управления цикла, например: :last-loop-element — это последний элемент, который будет создан в цикле, и с помощью этого селектора можно будет управлять его параметрами.

Это базовые группы свойств, которые следует реализовать в первую очередь.

В CTS мы добавим единственный новый синтаксический элемент: подстановочные переменные и переменные, созданные внутри CTS-объявлений. Подстановочные переменные должны начинаться со знака %, а внутренние подстановочные переменные — со знака %%. Например, на серверной стороне нам доступна переменная с именем page.title, тогда, чтобы подставить её в CTS-файле, мы используем следующую конструкцию: %page.title. Внутренние переменные используются, в основном, в циклах, для того, чтобы не было перекрещивающихся определений переменных, так как их имена должны быть уникальными в пределах документа.

Сейчас важно понять одну большую разницу между CSS и CTS, которая поможет нам в дальнейшем создавать правильные имена для свойств: если CSS оперирует существительными, то в CTS используются глаголы. CTS — это язык действий, где каждое свойство определённого правила производит операцию над элементом, который указан в селекторе (или над группой элементов).

Ключевая особенность CTS заключается в использовании существующего дерева элементов и связанных с ними атрибутов. Селекторы помогают нам по уже определённым классам и идентификаторам, а также по предопределённым в XHTML именам элементов, добираться до нужных и применять к ним необходимые действия.

Давайте посмотрим на пример правила, с помощью которого можно установить заголовок страницы из динамической переменной:

title
{
	append: %page.title;
}

О предопределённых свойствах, в данном случае об append, мы поговорим чуть позже. Следует только знать, что оно добавляет к содержимому элемента по селектору новое (если у элемента не было содержимого до этой операции, то весь элемент будет содержать лишь то, что мы добавим через CTS). Главное здесь — не забыть установить %page.title, чтобы эта переменная успешно была добавлена к содержимому заголовка страницы.

Функции подстановки значений

В CSS мы можем использовать следующую конструкцию для установки фона элемента:

#element
{
	background: url(/path/to/image.png);
}

В данном случае мы видим ключевое слово url и круглые скобки после него, в которых заключено непосредственное значение (аргумент). Такую конструкцию мы будем называть функцией CTS. Результат выполнения функции подставляется вместо неё и передаётся свойству.

В CTS определено две ключевых функции. Первая — это selector, с помощью которой можно находить элементы в документе для подстановки в качестве значения данного свойства. Вторая — это expression, который является логическим выражением.

Функция selector обладает следующим синтаксисом:

#element
{
	replace-element: div selector(#another-element);
}

Функция expression обладает следующим синтаксисом:

#element
{
	add-attribute: class "active" expression(%page.is_active is true); 
}

Аргументом данной функции является логическое выражение, которое возвращает true или false. Выражение состоит из двух частей, каждая из которых определяется либо собственным значением, либо переменной, либо значением элемента или атрибута, полученного по селектору. Если выражение в скобках истинно, то указанное действие по свойству будет выполнено, иначе этого не произойдёт. Данную функцию можно применять абсолютно к любому свойству, просто приписывая её в конец как ещё один аргумент.

При реализации CTS-шаблонизатора, можно встраивать дополнительные функции, которые будут доступны для вызова точно таким же образом. Можно реализовать абсолютно любой набор таких функций.

Предопределённые операции

В дальнейшем нам понадобится следующая памятка. Если вы запутаетесь при чтении записи, где селекторы, где свойства и значения, то смотрите на неё:

селектор
{
	/* комментарий */
	свойство: значение;
	свойство: значение;
	свойство: функция(аргумент);
}

Ранее мы разбивали набор предопределённых свойств (операций) по группам. Пришло время разобрать какие именно свойства мы должны определить.

Управление содержимым элемента

• append — присоединение содержимого переменной или строки в конец содержимого элемента;
• prepend — присоединение содержимого переменной или строки в начало содержимого элемента;
• replace — замена содержимого элемента указанным содержимым;
• clear — удаление содержимого из элемента;
• store — помещение содержимого элемента во внутреннюю переменную, например: store: %%new.variable. В данном коде мы помещаем содержимое элемента во внутреннюю переменную %new.variable. В дальнейшем мы можем использовать эту переменную по всему CTS-документу, например, для вставки в другие места;
• substitute — замена указанной строки другой строкой. Позволяет подставлять необходимое содержимое в нужное место в содержимом элемента. Например, если у нас есть строка Hello, My name is ###. I'm glad to see you there!, то мы можем заменить ### на нужную нам строку следующим образом: substitute: «» %page.name для замены на содержимое переменной или substitute: "###" "Din" для замены на статичную строку;

Рассмотрим пример применения каждого из этих атрибутов (мы будем совершать все операции на одном элементе, чтобы сохранить минимальный объём кода). Для примера мы представим, что у нас есть такой XHTML-элемент:

<div id="element">Моя страница</div>

Теперь произведём примерную его модификацию:

#element
{
	/* Присоединяем необходимое содержимое к элементу 
	   Результат: Моя страница → "содержимое %my.variable"
	*/
	append: " →";
	append: %my.variable;

	/* Добавляем содержимое перед существующим 
	   Результат: Заголовок страницы: Моя страница → "содержимое %my.variable"
	*/
	prepend: "Заголовок страницы: ";

	/* Заменяем всё содержимое нужным 
	   Результат: "содержимое %my.variable"
	*/
	replace: %my.variable;

	/* Сохраняем содержимое элемента */
	store: %%my.another.variable;

	/* Очищаем содержимое элементов. 
	   Если свойство не принимает никаких значений (после знака «:»), то его значение должно совпадать с его именем. 
	   Результат: элемент не содержит содержимого
	*/
	clear: clear;

	/* Вновь добавляем новый текст */
	append: "Заголовок страницы: ###. Привет!";

	/* Заменяем искомую подстроку ### на содержимое переменной %my.variable */
	substitute: "###" %my.variable;
}

Манипуляции с атрибутами

• add-attribute — создание нового атрибута данного элемента. Необходимо передать в качестве свойств имя нового атрибута и его содержимое, в качестве которого может выступать как строка, так и переменная;
• remove-attribute — удаление атрибута по имени из элемента. Если атрибут не существует, то он, естественно, не будет удалён;
• append-attribute-content — добавление содержимого к концу значения существующего атрибута. Необходимо передать в качестве свойств имя атрибута и добавляемое значение, которое может быть как строкой, так и переменной;
• prepend-attribute-content — добавление содержимого в начало значения существующего атрибута. В качестве свойств — имя атрибута и значение (строка или переменная);
• replace-attribute-content — замена содержимого атрибута новым содержимым (строкой или переменной). В качестве свойств передаётся имя существующего атрибута и новое значение;
• clear-attribute-content — очищение содержимого атрибута. Необходимо передать имя атрибута, содержимое которого следует обнулить;
• store-attribute-content — сохранение содержимого атрибута в определённой внутренней переменной;
• substitute-attribute-content — замена определённой подстроки содержимого элемента указанной строкой или переменной.

Для примера возьмём следующий элемент:

<a class="link" />

Попробуем произвести некоторые из описанных выше операций:

a.link
{
	/* Результат:
	   <a class="link">Моя ссылка</a> */
	append: "Моя ссылка";

	/* Результат:
	   <a class="link" href="http://example.com/">Моя ссылка</a> */
	add-attribute: href "http://example.com/";

	/* Результат:
	   <a class="link" href="http://example.com/my.html">Моя ссылка</a> */
	append-attribute-content: href "my.html";

	/* Результат:
	   <a class="link" href="http://example.com/my.html" id="myelement">Моя ссылка</a> */
	add-attribute: id "myelement";

	/* Результат: 
	   <a class="link" href="http://example.com/my.html">Моя ссылка</a> */
	remove-attribute: id;
}

Управление элементами

• hide — сокрытие (удаление) элемента. В качестве значения необходимо передать условное выражение;
• show — отображение элемента. В качестве значения — условное выражение;
• append-element — добавление дочернего элемента относительно текущего после всех остальных дочерних его элементов. Для проведения операции необходимо передать имя нового элемента или селектор элемента, который будет содеражть CSS-класс элемента или идентификатор элемента;
• prepend-element — добавление дочернего элемента относительно текущего перед всеми остальными дочерними его элементами. Для проведения операции необходимо передать имя нового элемента (или селектор);
• place-element — добавление дочернего элемента в позицию указанной строки. Для проведения операции необходимо передать строку для замены и имя нового элемента (либо селектор элемента). Новый элемент будет включать в себя заменённую строку;
• remove-element — удаление дочернего элемента относительно текущего. Необходимо передать имя элемента для удаления или селектор для нахождения нужного элемента;
• replace-element — замена дочернего элемента новым элементом. В качестве значения следует использовать селектор для нахождения элемента, которым следует заменить дочерний (который можно определить либо по имени элемента, либо таким же образом по селектору);

В качестве примера возьём элемент как в прошлом разделе:

<a class="link" />

Попробуем произвести некоторые манипуляции над ним:

a.link
{
	/* Скрываем, если %link_active равняется false */
	hide: expression(%link_active is false);

	/* Добавляем дочерний элемент span к текущему с идентификатором element */
	append-element: selector(span#element) expression(%link_current is true);
}

a.link span
{
	append: "Это ссылка";
}

/* Результат:
   <a class="link"><span id="element">Это ссылка</span></a> 
*/

Работа с CSS-классами

• add-class — добавление CSS-класса элементу;
• remove-class — удаление CSS-класса;
• replace-class — замена класса элемента, указанного первым значением, вторым значением;
• switch-class — циклическая смена одного CSS-класса другим. В качестве значения — два имени CSS-класса.

Дополнительных иллюстраций приводить здесь нет необходимости: названия свойств говорят сами за себя.

Циклы

Для циклов определены не только необходимые свойства, но и некоторые селекторы для удобства работы с первыми. Для начала разберём набор свойств:

• loop — добавление цикла. В качестве значений нужно передать переменную массива и внутреннюю (%%) переменную для доступа к элементам массива на каждой итерации цикла;

В качестве дополнительных селекторов выступают следующие:

• :loop-first — первый элемент цикла;
• :loop-last — последний элемент цикла;
• :loop-n(N) — N-ный элемент цикла.

Для примера, допустим, у нас есть следующая переменная:

%my.variable = [{"author" : "enhydra", "title" : "First article"},
		{"author" : "SvartalF", "title" : "Second article"},
		{"author" : "Hlomzik", "title" : "Third article"}]

И такой блок кода:

<ul class="articles">
	<li>
		<h2 />
		<span class="author" /> 
	</li>
</ul>

Преобразуем его с помощью цикла:

.articles li
{
	loop: %my.variable %%article;
}

.articles li h2
{
	append: %%article.title;
}

.articles li .author
{
	append: "Автор: ";
	append: %%article.author;
}

.artices li:loop-last
{
	add-class: last;
}

/* Результат:
   <ul class="articles">
		<li>
			<h2>First article</h2>
			<span class="author">enhydra</span> 
		</li>
		<li>
			<h2>Second article</h2>
			<span class="author">SvartalF</span> 
		</li>
		<li class="last">
			<h2>Third article</h2>
			<span class="author">Hlomzik</span> 
		</li>
	</ul>
*/

Подключение CTS-файлов

В зависимости от реализации CTS-шаблонизатора, подключение CTS-файлов к документам можно сделать различными способами. Мы же сделаем это так, как это сделано в CSS: inline-декларация CTS-стилей и подключение внешних файлов.

Подключение внешнего CTS-файла выглядит следующим образом:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
	<head>
		<title>Моя страница</title>
		<link href="template/sample.cts" type="text/cts" rel="transformation" />
	</head>
	<body>
		<!-- Содержимое документа -->
	</body>
</html>

А также можно использовать inline-декларацию (однако данный способ не рекомендуется из-за его семантической нестабильности):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
	<head>
		<title>Моя страница</title>
		<style type="text/cts">
			<!-- Правила трансформации -->
		</style>
	</head>
	<body>
		<!-- Содержимое документа -->
	</body>
</html>

После обработки таких документов CTS-шаблонизатором, им следует удалить все следы подключений, чтобы они не попали в публичный документ.

Теория реализации

Со стороны реализации CTS мы видим два элемента: основанный на CSS парсер и XML-парсер (или XHTML-парсер). Сначала будет обработан XHTML-документ, будет создано дерево его элементов. XML-парсер определяет, есть ли подключения внешних CTS-файлов или inline-декларации CTS. Если они присутствуют, к работе подключается CTS-парсер, основанный на CSS-парсере. В соответствии с внутренним алгоритмом, структура XML-дерева преобразуется с учётом указанного набора правил и выдаётся конечный результат.

Автор планирует в дальнейшем реализовать шаблонизатор Каскадных Таблиц Трансформации и применять его на практике. Помимо этого, планируется улучшение самого CTS и добавление в него новых свойств.

В заключение

Кажется, что такая структура очень подходит верстальщикам. При наличии хорошей документации, все свойства становятся понятными и ими довольно легко манипулировать. Использование такого шаблонизатора упрощает работу, однако со стороны производительности такое упрощение стоит работы двух разнородных парсеров. К слову, производительность системы можно увеличить, если добавить кеширование на разных этапах шаблонизации.

В эту прекрасную пятницу традиция «Забавы ради», которая продолжается уже несколько серий, обретает довольно интересные формы, не правда ли?

Комментирование

Форма комментирования (да и любая другая форма ввода) является одним из самых интересных, но в то же время сложных компонентов сайта. Чего только стоит соблюдение разметки комментария, ведь большинство сайтов позволяют так или иначе выделять определённые части введённого ими текста. Некоторые в качестве языка разметки комментария предпочитают (X)HTML, чему радуются Web-разработчики, другие — более приспособленные к полевым условиям движки: Markdown, Textile, BBCode и многие-многие другие. Мы остановимся на близкой сердцу разработчика XHTML-разметке, потому что она более природна, органично вписывается в интерьер Web-среды и позволяет держать написанный текст под контролем, а это самое главное тогда, когда предоставляется форма комментирования.

Как держать под контролем?

Для того, чтобы авторы комментариев успешно могли применять (X)HTML-комментарии, а администраторы сайтов чувствовали себя под защитой от разного рода нападений, можно использовать два подхода, один из который будет критическим, а второй — упрощённым, но от этого менее прочным.

Критический подход обработки комментариев состоит в том, что мы должны проверить, валидным ли является комментарий. Если это условие подтверждается, мы спокойно отправляем комментарий в дальнейшее плавание. С другой стороны, если при валидации были обнаружены ошибки, то следует сообщить о них автору комментария и попросить его их исправить.

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

1. Высокая нагрузка является основным недостатком подобного подхода, так как обработка входящих данных в качестве XML — это не самая тривиальная задача. Разумеется, существуют очень быстрые парсеры, которые способны мгновенно обрабатывать данные размером от 10 мегабайт, однако это единичные измерения, которые в большинстве случаев неприменимы в высоконагрузочных системах. С другой стороны, если удачно справиться с кешированием данных (то есть не обрабатывать каждый раз пришедшие куски данных вновь и вновь, а кешировать обработанные куски, обрабатывая лишь новые данные), то нагрузка может быть незначительно снижена;
2. Проверки подобного рода — они как игрушки: подходят для одного сайта, но не подходят для другого. К примеру, в блоге Web-разработчика поиграться с мини-валидатором довольно приятно, особенно, если его внешний вид будет напоминать старшего брата. Это придаёт стиль блогу, явную тематическую окраску и направленность. Однако для других тематических блогов такая проверка может быть избыточной.

В целом, если такую систему использовать на ненагруженных ресурсах (тематические персональные блоги, как вариант), то она не должна показывать свои плохие качества, а служить верой и правдой администратору. К тому же, последний может собирать статистику, какие ошибки люди больше всего совершают в (X)HTML-разметке и радовать читателей полезными сведениями.

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

К упрощённому подходу подходят ошибки и критического подхода, кроме второго, и добавляются некоторые нюансы, ведь исправление ошибок — это не совсем простая деятельность, она также сопряжена с определёнными трудностями.

Выводы

Разумеется, все эти рассуждения являются не более чем плодом больного воображения автора, хотя, кто знает, возможно, при довольно серьёзной оптимизации, они найдут своё место под солнцем будущих проектов.

Многие Web-разработчики, достигшие третьего уровня сложности игры в HTML (кто уже перешёл или начинает свой переход на строгий XHTML), могут задать вполне логичный вопрос: что это за атрибут такой, xmlns, который можно встретить на самой верхушке документа? Должно быть интересно, что он обозначает и зачем используется в XHTML. Давайте разбираться.

Природа загадочного атрибута

Атрибут xmlns — что же это такое? Этот атрибут можно встретить не только в XHTML, но и в его ближайшем родственнике: XML. Причём, как мы знаем, XML, в отличие от XHTML, не определяет никаких обязательных атрибутов и элементов, предоставляя инженеру полную свободу действий. Однако, даже в XML рассматриваемый нами атрибут выполняет особую роль, хоть он и не обязателен для определения в документе. В чём же заключается роль этого атрибута?

Представьте себе книжную полку, где каждое отделение содержит книги определённого стиля, жанра или автора. Всё на этой полке приведено в полный порядок и гармонию. Это облегчает читателю поиск любимой книги, облегчает ему поиск конкретного автора или выбор определённого жанра из всей коллекции. Особенно такая систематизация помогает при наличии немалого числа книг. Дома громадных книжных коллекций можно редко где увидеть, а вот в библиотеках — это единственный способ держать под контролем армию знаний. Представьте себе библиотеку, где всё было бы смешано между собой, книги сложены в кучу да ещё и в разных местах. Как долго вы бы искали то, зачем пришли?

Атрибут xmlns играет роль книжного стеллажа: он разделяет различные классы элементов и атрибутов, чтобы их легче было применять в документе, чтобы не происходило путанницы. Такая практика применяется не только в языках разметки: можно привести ещё несколько удачных реализаций подобной задумки. Разработчики конкретных языков программирования, например, C++, Java, Ruby или Python, встречаются с понятием «пространство имён» практически каждый день. Причём, в них он играет такую же роль, что и в XML.

Однако почему xmlns называется именно так? Всё просто: xmlns обозначает XML Namespace, то есть «Пространство имён XML».

Определение пространства имён

Определить пространство имён мы можем на любом элементе документа; его эффект будет распространяться на все элементы, вложенные в него и на сам этот элемент. У одного элемента мы можем определять сколь угодно пространств имён. Существует два способа определения пространства имён: префиксный и безпрефиксный.

1. Префиксный — это такой способ определения пространства имён, при котором мы задаём его имя. При использовании такого пространства имён всегда необходимо применять в дальнейшем расширенний вид имени элемента (или атрибута), чтобы указать на то, к какому пространству имён относится этот элемент (атрибут). Для определения префиксным способом используется следующая конструкция: xmlns:имя_пространства_имён="URI_пространства_имён";
2. Безпрефиксный способ подразумевает определение пространства имён по умолчанию для имён элементов (и атрибутов), записанных в обычной форме (это и есть та повседневная форма записи имён элементов и атрибутов, которую мы чаще всего используем). Его запись выглядит так же, как и при использовании префиксного способа, но без имени_пространства_имён, то есть: xmlns="URI_пространства_имён".

В каждом из этих способов вы могли видеть понятие URI_пространства_имён в качестве значения атрибута xmlns (или xmlns:имя_пространства_имён). Это самый обычный URI, который соответствует определяемому нами пространству имён. Добавляя в документ новое пространство имён, мы делаем соответствующую привязку всех элементов и атрибутов, использующих его, к определённому адресу в Интернете. Этот адрес указывает на Web-страницу, на которой расположена информация о том, какие элементы и атрибуты может включать в себя данное пространство имён. Совершенно необязательно, чтобы на той странице был страшный документ для обработки машинами; напротив: информация, представленная в нём, должна быть понятна человеку, потому что прежде всего люди используют различные пространства имён при разметке тех или иных документов.

Одно правило должно выполняться для такого типа определений пространства имён: URI должен быть уникален и не может быть пустым (несмотря на то, что пустая строка — это валидный URI). Это значит, что каждое отдельное пространство имён должно быть описано на своей собственной странице, чтобы не возникало никаких пересечений между разными сущностями.

Существует несколько ограничений, накладываемых на добавление новых пространств имён.

1. Пространство имён с именем xml является зарезервированным и используется по умолчанию для всех XML-документов. Это значит, что если вы создали XML-документ и не определили нигде свои пространства имён, то весь документ использует пространство имён xml;
2. Пространство имён с именем xmlns также является зарезервированным, так как с помощью него мы определяем другие пространства имён. По умолчанию, атрибут xmlns как раз и является членом данного пространства имён.

Теперь разберёмся с расширенным видом имени элемента. Обычно, мы встречаемся с такой записью элемента:

<element attr_first="value" attr_second="another_value">
Содержимое элемента и/или вложенные в него элементы
</element>

Если мы определяем новое пространство имён префиксным способом, то запись имён элементов и атрибутов приобретает следующий вид:

<namespace:element namespace:attr_first="value" namespace:attr_second="another_value">
</namespace:element>

В этом случае мы к имени каждому элемента и атрибута добавляем префикс, состоящий из имени пространства имён и двоеточия. Разумеется, необязательно, чтобы элемент и все его атрибуты были записаны в одном и том же пространстве имён. Элемент может использовать одно пространство имён, атрибуты — другое, а могут и не использовать вовсе.

<element namespace:attr_first="value" attr_second="another_value">
</element>

В вышеприведённом примере элемент element и атрибут attr_second используют пространство имён по умолчанию, а атрибут attr_first — пространство имён namespace.

Применение пространств имён

Данное полезное свойство XML следует применять тогда, когда очевидно, что в документе будут использованы сущности разных видов. Если используемые элементы в документе совершенно рознятся по своему предназначению, либо их парсинг будет происходить по разным критериям, то следует разграничить их в разные пространства имён.

При обработке документов с использованием пространств имён машинными средствами, можно использовать механизмы для предупреждающего вычленения элементов, соответствующих конкретным пространствам имён, чтобы облегчить последующую (возможную) процедуру обработки дерева XML-документа. Такая возможность очень полезна при построении шаблонизаторов, основанных на XML: можно разграничить элементы шаблонизатора и элементы интерфейса, тогда, вкупе с исчерпывающей документацией по каждому из пространств имён, получится отличная дифференцированная система обработки сложных структурированных XML-шаблонов.

Давайте посмотрим на простые примеры. Для начала создадим простой XML-документ:

<?xml version="1.0" encoding="utf-8" ?>
<vocabulary>
  <word>
    <name>Информация</name>
    <description>Продукт взаимодействия данных и методов, рассмотренный в контексте этого взаимодействия.</description>
  </word>
  <word>
    <name>Байт</name>
    <description>Единица измерения количества информации, 8 бит.</description>
  </word>
  <word>
    <name>Бит</name>
    <description>Один разряд двоичного кода (двоичная цифра).</description>
  </word>
</vocabulary>

Мы создали простой структурированный словарик определений. По умолчанию, мы не определили смысл каждого из наших тегов, потому что не задали пространство имён по умолчанию. Такая информация полезна прежде всего для редакторов подобных документов, так как из пространств имён они могут получить документацию по применяемой разметке. Информация может быть обычной XHTML-страницей, рекомендацией или даже статьёй, где рассказывается об использовании элементов и атрибутов данного пространства имён.

<?xml version="1.0" encoding="utf-8" ?>
<vocabulary xmlns="http://example.com/namespace/vocabulary.html">
  <word>
    <name>Информация</name>
    <description>Продукт взаимодействия данных и методов, рассмотренный в контексте этого взаимодействия.</description>
  </word>
  <word>
    <name>Байт</name>
    <description>Единица измерения количества информации, 8 бит.</description>
  </word>
  <word>
    <name>Бит</name>
    <description>Один разряд двоичного кода (двоичная цифра).</description>
  </word>
</vocabulary>

Теперь любой сможет пройти по этой ссылке и просмотреть информацию обо всех элементах, используемых в документе. Теперь усложним ситуацию: представим, что нам понадобилось размечать описание каждого слова XHTML-разметкой. Просто вписать имена соответствующих элементов мы не можем, поскольку мы определили собственное пространство имён для элементов без префиксов (даже если бы мы этого не сделали, по умолчанию для таких элементов используется пространство имён xml). Мы с этой проблемой можем спокойно, без нервов, справиться:

<?xml version="1.0" encoding="utf-8" ?>
  <vocabulary xmlns="http://example.com/namespace/vocabulary.html"
              xmlns:html="http://www.w3.org/1999/xhtml">
    <word>
      <name>Информация</name>
      <description>Продукт взаимодействия данных и методов, рассмотренный в <html:strong>контексте</html:strong> этого взаимодействия.</description>
    </word>
    <word>
      <name>Байт</name>
      <description>Единица измерения количества информации, <html:em>8 бит.</html:em></description>
    </word>
    <word>
      <name>Бит</name>
      <description>Один разряд двоичного кода (двоичная <html:a html:href="http://example.org/knowledges/ru/цифра">цифра</html:a>).</description>
    </word>
  </vocabulary>

Заметьте, что теперь мы разметили наши описания с помощью HTML. Обратите внимание на то, что и атрибуты, которые используются в XHTML, мы также записываем с префиксами. Теперь, если мы будем писать парсер, нам будет легко дифференцировать структурные и визуальные элементы документа. А теперь мы добавим ещё одно пространство имён, но уже к другому элементу, и определим внутреннюю структурную ссылку одного понятия на другое.

<?xml version="1.0" encoding="utf-8" ?>
  <vocabulary xmlns="http://example.com/namespace/vocabulary.html"
              xmlns:html="http://www.w3.org/1999/xhtml">
    <word>
      <name>Информация</name>
      <description>
        Продукт взаимодействия данных и методов, рассмотренный в <html:strong>контексте</html:strong> этого взаимодействия.
      </description>
    </word>
    <word xmlns:sa="http://examplex.com/namespace/vocabulary-seealso.html" sa:seealso="Бит, Информация">
      <name>Байт</name>
      <description>
        Единица измерения количества информации, <html:em>8 <sa:link sa:word="Бит">бит</sa:link>.</html:em>
      </description>
    </word>
    <word>
      <name>Бит</name>
      <description>
        Один разряд двоичного кода (двоичная <html:a html:href="http://example.org/knowledges/ru/цифра">цифра</html:a>).
      </description>
    </word>
  </vocabulary>

Теперь при обработке документа и реализации соответствующего алгоритма, мы можем создавать ссылки с одного слова на другое, или объединять слова в целые смысловые группы.

XHTML и пространство имён

Web-разработчики, использующие XHTML, могли видеть этот загадочный атрибут в самом начале документа. Возьмём для изучения первые две строчки текущего документа:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="ru" xml:lang="ru" xmlns="http://www.w3.org/1999/xhtml">

Первая строка — это определение типа документа, а вторая — это корневой элемент этого же документа. Корневой элемент содержит искомое определение пространства имён. Здесь он написан в безпрефиксной форме, то есть все элементы документа — это XHTML-элементы (это понятие раскрывается теперь просто чудесно: XHTML-элементы — это элементы, которые определены в соответствующем пространстве имён XHTML. Девушки будут в восторге!). При использовании сторонних элементов или других пространств имён, валидатор должен выдать ошибку. В первом случае он сделает это, потому что набор используемых элементов определён в DTD, привязанном к документу. Во втором случае это произойдёт, потому что других пространств имён не определено.

Заметьте, что в XHTML определены два атрибута из пространства имён xml, один из которых вы можете видеть в примере выше — xml:lang. Не удивляйтесь: если мы определили пространство имён по умолчанию для данного элемента и всех его потомков, то пространство имён xmlns:xml никуда не делось! Записывают данные атрибуты с префиксом для того, чтобы удовлетворить требованиям применения пространств имён и чтобы не было конфликтов с определением одинаковых по именам атрибутов в разных пространствах имён. Второй подобный атрибут в XHTML вы можете обнаружить самостоятельно в текстах DTD.

Послесловие

Некоторые очень сильно ругают теорию пространств имён в XML, находя её слишком избыточной и странной. Автор считает, что такое решение — это самое изящное решение, которое вообще можно было придумать для XML и его потомков и братьев, так как оно хорошо зарекомендовало себя и в других областях не только разработки, но и обычной жизни. Как уже было сказано ранее много раз, упорядочение и систематизация никогда не играли против человека, а всегда помогали ему выжить под натиском суровых реалий окружающего хаоса. На этой философской ноте меня вынуждают остановиться.

Если вам захочется технических подробностей об этом явлении, обратитесь к соответствующей рекомендации W3. До новых встреч и удачных вам пространств!

Мы рассмотрим полный цикл работы парсера, начиная от загрузки исходных данных и завершая готовым деревом элементов. В конце концов, мы сможем увидеть рабочую версию клиентской части XML-парсера. Пока мы не углубились в изучение вопроса, вы можете просмотреть сводную карту XML-парсинга и будем двигаться дальше.

Загрузка исходных данных

Перед тем, как что-то обрабатывать, мы должны это получить. Исходные данные мы можем доставить нашему парсеру из совершенно разнообразных источников, начиная от обычной строки и заканчивая удалённым адресом в сети.

Фабрика работы с исходными данными

Для того, чтобы мы не были зависимы от конкретного источника данных, нам следует создать слой абстракции над загрузкой данных. Именно он будет определять, какие именно данные следует получить и в соответствии с этим вызывать соответствующий обработчик. На практике подобное определение заключается, например, в эвристической обработке строки, в которой заключен путь к источнику данных. Вот примеры такой строки:

1. http://labs.web-zine.org/docs/oml/doc-xhtml1−strict.oml
2. /home/dinamyte/my.xml

Даже на глаз можно определить то, какой обработчик следует привлечь для получения данных (разумеется, на языке программирования это можно сделать с помощью регулярных выражений, своеобразного глазомера программирования). В противном случае — если строка не подпадает ни под одно правило — мы можем считать строку обычным XML:

<?xml version="1.0" encoding="utf-8" ?>

В этом случае обработчик источника данных привлекать не нужно, можно сразу передать XML парсеру. Строго говоря, даже при получении данных из файла или удалённого источника, мы всё равно сводим эти данные к обычной строке и передаём парсеру, который начинает усердно с ней работать.

Кодировка документа

Примечание: далее в тексте записи вы можете встретить такое понятие, как XML-элемент. Для данной записи мы считаем понятие элемента и узла в дереве синонимами, хотя на самом деле у них есть различия. Не запутайтесь.

Алгоритм парсинга

Перед обработкой данных, мы должны произвести ещё один подготовительный этап: выделить используемую документом кодировку. Данный этап нужен для того, чтобы правильно обрабатывать текстовые данные и данные об XML-элементах документа, ведь имена элементов и их содержимое может быть записано не только с помощью символов латинского алфавита: XML поддерживает Unicode, а, следовательно, и интернационализацию. При верном определении кодировки документа мы сможем добавить (или удалить) определённые шаги обработки документа. Например, если документ содержит лишь ASCII-символы, то нам не нужно применять функции для работы с интернационалым именованием.

Алгоритм определения кодировки заключается в следующем:

1. Определить кодировку документа по кодировке исходного файла или по одному из заголовков ответа от сервера (при получении исходных данных из удалённого источника);
2. Просмотреть атрибут encoding в декларации XML-документа и принять её как кодировку документа (даже несмотря на положительный результат предыдущей проверки, текущая имеет более высокий приоритет);
3. Если по каким-то причинам определить кодировку невозможно, это можно сделать эвристически, просканировав документ, либо логически, приняв utf-8 за кодировку документа.

Уже после этого этапа можно приступать к обработке документа.

Структуры парсинга

Парсинг любых данных подразумевает трансформацию исходных данных (зачастую текстовых) в структуры на применяемом для парсинга языке программирования. Мы будем составлять такие структуры с помощью хорошо комментированного Ruby.

В основе описания структур данных лежит принцип определения логической единицы в исследуемом нами явлении. В XML-парсинге такой единицей является элемент, который нам и следует описать. Он обладает следующим набором свойств:

1. Имя элемента;
2. Пространство (namespace) элемента;
3. Тип элемента (текстовый элемент, обычный элемент, и подобные);
4. Содержимое элемента (используется только для текстовых элементов);
5. Атрибуты элемента (массив атрибутов).

Помимо этого, мы должны определить набор свойств для связывания текущего элемента в дереве всех элементов. Это достигается путём добавления нижеуказанных свойств:

1. Родительский элемент (по умолчанию он не установлен, значит такой элемент является корневым элементом дерева);
2. Дочерние элементы (их массив, в том порядке, в каком они встречаются в исходных данных).

Теперь мы можем описать эту структуру с помощью Ruby, добавив при этом необходимые действия, которые мы можем выполнять с элементом.

#Объединяем классы (структуры данных) в отдельный модуль
module XML

	#Отдельный XML-элемент (узел в дереве)
	class SimpleNode

		#Свойства только для чтения
		attr_reader :name, :type, :namespace

		#Свойства для чтения и записи извне класса
		attr_accessor :parent, :attributes, :child_nodes, :child_node_position, :node_data

		#Инициализация класса
		# name - имя элемента (RAW-имя, например, div или svg:transformation)
		# type - тип элемента (:element для обычного элемента и :text для текстового)
		def initialize name, type = :element

			#Пространство имён элемента (по умолчанию его нет)
			@namespace = nil

			#Определяем, есть ли пространство имён у данного элемента
			if name.include? ":"

				#Разделяем по двоеточию; слева — пространство имён, справа — имя
				name = name.split ":"

				#Устанавливаем имя и пространство имён
				@namespace = name[0]
				@name = name[1]

			else
				#Пространство не указано, устанавливаем имя элемента
				@name = name
			end

			#Тип элемента
			@type = type

			#Родительский элемент (по умолчанию его нет)
			@parent = nil

			#Ассоциативный массив атрибутов
			#Имеет вид: имя_атрибута = значение_атрибута
			@attributes = {}

			#Массив дочерних элементов
			@child_nodes = []

			#Текстовое содержимое узла (только если его тип — text)
			@node_data = ""

		end

		#Набор простых операций с элементом

		#Добавление нового дочернего элемента (существующего)
		def append_node node

			#Текущий элемент — родительский для дочернего
			node.parent = self

			#Добавляем в массив всех дочерних
			@child_nodes << node

		end

		#Добавление нового атрибута
		def attribute_add name, value

			@attributes[name] = value

		end

		#Проверки тех или иных ситуаций

		#У элемента установлено пространство имён?
		def namespace_exists?
			@namespace != nil
		end

		#У элемента есть атрибуты?
		def attributes_exists?
			@attributes.length != 0
		end

		#У элемента есть дочерние элементы?
		def child_nodes_exists?
			@child_nodes.length != 0
		end

		#У элемента есть родительский элемент?
		def parent_exists?
			@parent != false
		end

	end

end

Логическую единицу мы создали, теперь будем двигаться вверх по уровням абстракции. Выше элемента у нас набор элементов, то есть документ. Документ представляет собой дерево связанных между собой элементов. Каждый элемент может иметь несколько дочерних элементов. Каждый дочерний элемент может иметь родительский; если такого элемента нет, то данный элемент — корневой в дереве документа.

Парсинг документа

Парсинг происходит именно в классе документа, в момент загрузки данных в него с помощью специального метода. После того, как мы получили исходные данные, нам следует очистить их от ненужных нам включений. Таким включением, например, можно считать комментарии, которые не несут никакой структурной нагрузки в документе (если мы, конечно, не делаем Meta XML-парсер, но об этом как-нибудь в другой раз, так как это ещё одна общирная тема для бесед).

Метод конечных автоматов

После удаления комментариев мы остаёмся один на один со структурной раскладкой документа. Мы должны приступать к его обработке. Какие шаги нам следует предпринять и как следует обрабатывать XML? Существует множество способов работы с XML. Некоторые заключаются в построении кеша и преобразовании XML в другой тип данных, чтобы потом применить другой парсер. Другие создают дерево элементов, как мы и условились сделать с самого начала, используя при этом метод конечных автоматов.

Весь процесс парсинга в последнем случае состоит из нескольких этапов: точки входа, различных постоянных состояний и точки выхода. При этом нам понадобится один временный элемент, который будет указывать на текущий элемент во всём дереве и одна переменная, указывающая на текущее состояние парсинга.

Точка входа — это начало процесса работы парсера, вычленение необходимых вхождений из документа. В этом случае мы собираем XML-теги: открывающие, закрывающие и то, что между ними.

Состояния могут быть следующими:

1. Открывающий тег (окончание открывающего тега) — создаётся новый элемент и заполняется имеющимися данными. Текущий элемент устанавливается в новый;
2. Закрывающий тег (его окончание) — текущий элемент устанавливается в родительский элемент текущего, так как нам следует подняться вверх по иерархии элементов (текущий элемент закончился);
3. Текстовое содержимое — создаётся новый элемент с отличным от обычного типа и заполняется текстовым содержимым. Представлять текстовые элементы лучше именно в виде отдельных элементов, так как нам необходимо хранить точную структуру документа;
4. Начало секции CDATA  — отключается XML-парсер до окончания секции (в соответствии со спецификацией XML, где указано, что мы не можем обрабатывать теги внутри CDATA;
5. Окончание секции CDATA — включается XML-парсер и продолжается дальнейшая обработка документа. Секция CDATA может быть присоединена к дереву в качестве обычного текстового элемента, либо в качестве элемента отдельного типа.

Когда тегов больше нет, мы попадаем в точку выхода, достигая таким образом окончания документа.

#Нам необходим класс простого элемента
require "library/xml/parser/node"

#Группируем созданные классы
module XML

	class Document

		#Свойства для чтения
		attr_reader :tree

		#Инициализация документа
		#В качетсве параметра передаётся тип создаваемых элементов
		#Данный шаг предпринят для обеспечения гибкости класса документа
		def initialize node_type = XML::SimpleNode

			#Сохраняем тип элемента
			@node_type = node_type

			#Создаём корень нашего дерева (тип — root)
			@tree = @node_type.new "root", :root

		end

		#По умолчанию мы считаем, что документ содержит кодировку utf-8
		#Обработка данных из строки
		def parse_string string

			#Удаляем комментарии
			string.gsub!(/<!--(.*?)-->/m, "")

			#При использовании CDATA в документе, мы должны обеспечить её целостность
			if string.include? "<![CDATA["

				#Удаляем < и > из секций CDATA
				string.scan(/(<!\[CDATA\[(.*?)\]\]>)/um).each do |token|
					token[1].gsub!("<", "<")
					token[1].gsub!(">", "&rt;")
					string.gsub!(token[0], "<![CDATA[" + token[1] + "]]>")
				end

			end

			#Заключаем содержимое каждого элемента в PCDATA
			#Этот шаг предпринят для получения текстового содержимого элемпента
			string.gsub!(/>(?!<)/m, "><![PCDATA[")
			string.gsub!(/(?!>)</m, "]]><")

			#Создаём указатель на результирующий массив
			result = @tree

			#All-in-one pattern: сканируем все возможные вхождения (кроме XMLDecl)
			string.scan(/\<([a-zA-Z0-9:\-]+)\s*([^>]+>|>)|<\/([a-zA-Z0-9:\-]+)>|<!\[(?:P|)CDATA\[(.*?)\]\]>/um).each do |token|

				#Переходим к методу конечных автоматов
				if token[0] != nil and token[1] != nil
					#Открывающий тег

					#Создаём экземпляр нового элемента и устанавливаем его имя
					new_tag = @node_type.new token[0], :element

					#Есть ли атрибуты у данного элемента?
					if token[1] != ">"

						#Если есть, добавляем их к элементу
						token[1].scan(/(([A-Za-z:\-_]+)=(?:\"|')([^"]+?)(?:\"|'))/).each do |attr|
							new_tag.attribute_add attr[1], attr[2]
						end

					end

					#Добавляем созданный элемент к дереву всех элементов
					result.append_node new_tag

					#Новый элемент становится текущим
					#Если элемент не содержит других элементов, то операция не производится
					result = new_tag if token[1][token[1].length - 2].chr != "/"

				elsif token[2] != nil
					#Закрывающий тег

					#Устанавливаем текущий элемент в родительский текущего
					#Условие: существование родительского элемента
					result = result.parent if result.parent_exists?

				elsif token[3] != nil and token[3].strip != ""
					#(P)CDATA — текстовое содержимое

					#Создаём текстовый элемент (его имя может быть пустым)
					new_tag = @node_type.new "", :text

					#Добавляем текстовые данные
					#result.node_data = token[3].gsub("<", "<").gsub(">", ">")
					new_tag.node_data = token[3]

					#Добавляем к текущему элементу
					result.append_node new_tag

				end

			end


		end

	end

end

Теперь мы можем создавать XML-документы и иметь доступ к их древовидной структуре, обращаясь к соответствующему свойству объекта документа. Примечательно, что применение данного способа позволяет обрабатывать не только полностью валидные документы, но даже и отдельные их части, поэтому такой парсер называется потоковым (Stream XML parser).

Итоги

Мы написали небольшой XML-парсер. Его можно оптимизировать и дальше, но в учебных целях подойдёт и столь компактная его версия. После реализации XML-парсера, мы можем со спокойной душой отправляться в плавание по просторам XML-трансформации и разного рода модификациям исходного дерева XML. Мы не станем останавливаться на текущем шаге и посвятим ещё парочку выпусков данной теме. А пока вы можете посмотреть на одну из моих рабочих версий XML-парсера.

Сегодня мы постараемся погрузиться в валидацию до боли знакомых нам языков разметки: XML и XHTML. На первый взгляд, они такие похожие и должны рассматриваться как одно целое, но на самом деле они довольно разные и для них следует писать совершенно разные валидаторы. Можно даже выразиться следующим образом: проверка XHTML на XML-валидаторе будет недостаточной, а XML на XHTML-валидаторе — избыточной, и обе проверки покажут, что документ невалиден.

Общие шаги

Перед тем как переходить к частному, рассмотрим общие шаги на пути к становлению валидации. Для того, чтобы произвести валидацию содержимого, его сначала нужно получить. Источник (то, что мы должны проверить на соответствие набору определённых правил) может быть совершенно непредсказуемым:

1. Файл;
2. Строка;
3. Удалённый источник.

Мы абстрагируемся от указанных выше источников, ведь на самом деле нам не так уж и важно, откуда мы получаем данные для валидации: все они в конечном итоге предстают в виде строки. После того, как мы получили строку, нам нужно её обработать таким образом, чтобы получить элементы, с которыми мы можем работать на том языке программирования, на котором мы программируем. Для начала мы должны определиться, в какие сущности мы можем превратить входные данные. Вспоминаем, что основной единицей в XML/XHTML является элемент. От него и будем отталкиваться. Помимо элемента, нам нужен контейнер элементов, который мы будем называть документом.

Каждый XML/XHTML-документ состоит из набора элементов, причём всегда есть корневой элемент, содержащий в себе все остальные элементы. Постойте! Но ведь это же обычное дерево! Да-да, всё правильно: мы видим перед собой дерево элементов. Мы пришли к достаточно важному выводу: любой XML-документ (и документ на любом XML-подобном языке) можно представить в виде дерева. После, с этим деревом мы можем выполнять самый разный набор операций: сравнение, удаление, перестановка, траверсинг (операция прохода по всем узлам дерева) и другие.

Как проверяется XML

Проверка XML несравненно проще проверки XHTML: нам необходимо лишь удостовериться в выполнении нескольких требований, что можно сделать совершенно спокойно, учитывая то, что у нас есть дерево элементов. Систематизируем необходимые правила:

1. Первый элемент в документе — это всегда декларация заголовка XML вида , где […] — атрибуты заголовка XML;
2. Все элементы должны быть названы верным образом и не должны содержать посторонних символов (пробелов, к примеру);
3. Все атрибуты должны быть записаны в правильной форме (проверяется достаточно просто, тем же регулярным выражением);
4. Документ должен содержать только один корневой элемент;
5. Вложенность элементов должна быть соблюдена (проверка данного утверждения достигается за счёт использования стека элементов, с помощью которого мы проверяем соответствия открывающих и закрывающих элементов);

Примечание: валидатор не должен исправлять ошибки в XML-документах, так как это не входит в его компетенцию.

Если все вышеуказанные правила соблюдаются, то документ считается валидным XML-документом. В противном случае — документ содержит ошибки, список которых валидатор может вывести пользователю для ознакомления и исправления.

XHTML: лёгкие Интернета

Проверка XHTML основывается на валидации XML. Сначала мы должны удостовериться в том, что документ является валидным с точки зрения XML (то есть соблюдена вложенность тегов, правильно оформлены элементы и их атрибуты, и другие), и уже потом накладывать дополнительные правила. Если документ не является валидным с точки зрения XML, то он заведомо не является валидным и с точки зрения XHTML.

Чтобы применять какие-либо правила XHTML к документу, сначала нужно эти правила описать таким образом, чтобы их было легко получить и как трафарет наложить на документ. Для валидации XHTML-документов правила могут храниться в виде нескольких форматов:

1. DTD-документы;
2. XML Schema;
3. Relax NG.

Независимо от формата, производится следующий набор проверок:

• Проверка всех используемых элементов в документе на их наличие в XHTML (если элемент, указанный в документе, не существует, то выдаётся соответствующая ошибка);
• Проверка на наличие обязательных атрибутов у соответствующих элементов;
• Проверка типа содержимого некоторых атрибутов на соответствие тем типам, которые указаны в правилах;
• Тип содержимого элемента должен совпдадать с тем, который указан в правилах;
• Так как XHTML определяет классы элементов (блоковые и текстовые), то валидатор должен убедиться в том, что элементы одного класса (уровня) должны быть правильно вложены в элементы другого класса (уровня). Подобные закономерности также описываются в правилах.

После выполнения указанного набора правил можно говорить о том, является ли документ валидным или напротив: содержит какие-то ошибки, которые валидатор может указать пользователю.

Итоги

Логично было бы заметить, что отсутствует описание процесса обработки документов для их представления в виде дерева элементов (абстрактно или на конкретном языке программирования). Если таковой процесс интересен читателям, то он будет описан в отдельной статье, в противном случае будем двигаться дальше по намеченному вектору.

В Web-инженеринге также не обошлось без упорядочивания и систематизации. Одним из примеров подобного явления в нашей с вами области является DTD, который раскладывает по полочкам набор известных (X)HTML-тегов, не даёт запутаться валидатору и браузеру, а также помогает программисту, в некотором роде предоставляя для него минимальный набор справочного систематизированного материала. Жуть как удобно, правда?

Цели DTD

Конечно же, DTD создан не просто так. Корни данного формата уходят ещё в SGML. Можно даже сказать иначе: DTD является обязательной частью приложения SGML (коим является и HTML, к примеру). В нём объявляются и описываются всевозможные правила, применимые именно к данному языку разметки. И правда: у HTML свои правила, у XHTML уже немного другие. Даже эту разницу необходимо где-то отразить, чтобы было видно, что это не одно и то же.

Разумеется, DTD является не просто контрактом между разными программистами: DTD — это надёжная опора для валидаторов и браузеров. Да, именно DTD используют валидаторы для того, чтобы проверить документ на соответствие всем необходимым требованиям. Браузер же в меньшей степени использует данный документ.

Сформулируем основные цели, которые преследует DTD:

1. Контракт между программистами;
2. Описание набора правил, соответствующих для конкретного языка разметки;
3. Самодокументация набора правил;
4. Обособление различных приложений SGML (HTML, XHTML и так далее);
5. Унификация способов записи правил разметки на разных языках.

Каждое правило тем или иным образом пересекается с другими правилами, таким образом образуя одну большую структуру данных описательного характера.

DTD в гипертекстовых языках разметки

Каждый Web-инженер встречался с таким явлением, как DOCTYPE. Все мы начинаем наши документы именно с объявления типа документа, чтобы браузеру было понятно, какой именно набор правил мы используем в разрабатываемом документе. Взглянем на различные DOCTYPE, существующие в XHTML:

<!DOCTYPE html
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<!DOCTYPE html
     PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!DOCTYPE html
     PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

Все три декларации типа документа состоят из 5 частей, каждая из которых отделена от соседних пробелами. Первые три части — DOCTYPE, html и PUBLIC — постоянны для HTML, а остальные варьируются в зависимости от используемого набора правил, применяемого к документу. Судя по данным декларациям, существуют три типа правил для HTML-документов: Strict, Transitional и Frameset. Последняя часть — это абсолютный путь (URI) к DTD-документу, который соответствует выбраному набору правил.

В данном случае, программист определяет, какой набор правил он будет использовать в разрабатываемом документе. Своё решение он выражает в виде записанного в начале HTML-файла DOCTYPE. Он,в свою очередь, будет использован браузером (User Agent) для того, чтобы выбрать соответствующий, правильный режим представления информации, более точную модель отображения данных. Можно сделать вывод, что выбор DTD является достаточно важной частью вёрстки, так как он накладывает отпечаток на последующие её этапы. Именно исходя из этого факта, можно говорить ещё и о том, что DTD является также и соглашением между Web-программистом и браузером, своеобразной гарантией правильного отображений документа.

Структура DTD

В дальнейшем мы будем рассматривать XHTML 1.0 Strict DTD.

Воспринимать структуру DTD можно достаточно просто, если помнить базовые типы данных, которые применяются в DTD. Все типы данных создаются конструкцией следующего вида:

<!тип_данных параметры>

Сейчас перечислим все возможные типы данных и остановимся на каждом из них подробно.

ENTITY

Данный тип данных используется для определения сущности, которая в дальнейшем будет подставляться в другие типы данных. Для того, чтобы лучше понять цель существования ENTITY, представьте себе константы в любом языке программирования и то, как они там используются.

Общий синтаксис ENTITY соответствует следующему выражению:

<!ENTITY % имя "содержимое">

Разберём части данного выражения.

1. имя — это произвольный набор символов, который, в дальнейшем, может быть использован для подстановки данной сущности;
2. содержимое — это набор данных, который будет подставлен заместо имени сущности.

Для того, чтобы подставить сущность в нужную часть DTD, используется конструкция следующего вида:

%имя;

Вот пример подобных конструкций:

<!ENTITY % Script "CDATA">
<!ENTITY % StyleSheet "CDATA">

Помимо такой записи сущностей, мы можем указать на то, что сущности находятся во внешнем файле, подключать который мы будем следующим образом:

<!ENTITY % имя PUBLIC "w3_путь" "имя_файла" > %имя;

В данной конструкции важную часть играет имя_файла, которое и указывает на тот файл, который нам следует подключить. Заметьте также после описания типа данных конструкцию %имя;, которая написана там для того, чтобы сразу подставить содержимое поключённого файла в сам DTD. Подобным образом, к примеру, описано подключение набора латинских символов:

<!ENTITY % HTMLlat1 PUBLIC
"-//W3C//ENTITIES Latin 1 for XHTML//EN"
"xhtml-lat1.ent">
%HTMLlat1;

ELEMENT

С помощью данного типа данных производится определение элемента (в нашей ситуации — HTML-элемента) и правил соблюдения иерархии для данного элемента (вложенность элементов).

Общий синтаксис ELEMENT соответствует следующему выражению:

<!ELEMENT имя_элемента правила_вложенности>

В этом случае имя_элемента будет использоваться для записи самого элемента непосредственно в HTML-документе:

<имя_элемента> </имя_элемента>

Теперь перейдём к правилам_вложенности: они могут быть записаны довольно большим количеством способов.

1. EMPTY — элемент не может содержать закрывающего тега; в таком случае для закрытия тега используются конструкция />, а весь элемент принимает вид <имя_элемента />;
2. (#PCDATA) или (#CDATA) — элемент может содержать только текстовое содержимое, то есть никаких вложенных тегов у него быть не может;
3. (элемент1) — элемент может содержать только один указанный элемент элемент1;
4. (элемент1|элемент2) — элемент может содержать либо элемент элемент1, либо элемент2, либо оба этих элемента;
5. (элемент1, элемент2) — элемент должен содержать оба элемента: элемент1 и элемент2 (оба в единственном экземпляре);
6. (…)+ — элемент должен содержать хотя бы один указанный элемент (или элементы);
7. (…)* — элемент может содержать любое количество указанных элементов (или одного элемента), а может и не содержать их вообще;
8. (…)? — элемент может содержать только один указанный элемент (или группу элементов).

Рассмотрим пример — объявление элемента html:

<!ELEMENT html (head, body)>

Данная конструкция говорит о том, что элемент html должен обязательно в себе содержать и элемент head, и элемент body. Ещё один пример, на этот раз связанный со списками:

<!ELEMENT ol (li)+>

Всё предельно понятно: элемент ol должен содержать хотя бы один вложенный элемент li.

Стоит заметить, что если вместо содержимого элемента встретится конструкция вида %имя;, то содержимое данной сущности (ENTITY) просто подставляется сюда и делается всё то же самое, что и без этой конструкции.

ATTLIST

Данный тип данных используется для определения атрибутов, которые может содержать указанный элемент.

Синтаксис определения списка атрибутов сводится к следующему виду:

<!ATTLIST имя_элемента
имя_атрибута1	тип_содержимого_атрибута1	обязательность_атрибута1
имя_атрибута2	тип_содержимого_атрибута2	обязательность_атрибута2
имя_атрибута3	тип_содержимого_атрибута3	обязательность_атрибута3
...
>

Список атрибутов может быть бесконечно большим (то есть количество атрибутов для одного элемента неограничено). Чтобы было легче понять, как это работает, рассмотрим элемент с некоторыми атрибутами:

<имя_элемента имя_атрибута1="содержимое_атрибута1"
			  имя_атрибута2="содержимое_атрибута2"
			  имя_атрибута2="содержимое_атрибута3"
			  >...</имя_элемента>

Теперь, думаю, примерно понятно, что обозначает каждая из колонок в объявлении атрибута. тип_содержимого_атрибута — это то, что может содержать в себе данный атрибут (набор символов, число, какое-то конкретное значение), а обязательность_атрибута говорит нам о том, обязателен ли данный атрибут для данного элемента. Рассмотрим значения обязательности атрибута более подробно:

1. #IMPLIED — атрибут является не обязательным, но он может быть применён к данному элементу;
2. #REQUIRED — атрибут должен обязательно быть записан для данного элемента;
3. #FIXED 'значение' — содержимое атрибута должно быть установлено только в указанное значение.

Рассмотрим примеры. Перво-наперво, посмотрим на то, как записан элемент style и его атрибуты:

<!ELEMENT style (#PCDATA)>
<!ATTLIST style
  %i18n;
  id          ID             #IMPLIED
  type        %ContentType;  #REQUIRED
  media       %MediaDesc;    #IMPLIED
  title       %Text;         #IMPLIED
  xml:space   (preserve)     #FIXED 'preserve'
  >

Видно, что элемент style не может содержать в себе вложенных тегов. Помимо этого, данный элемент должен обязательно содержать атрибут type, содержимое которого должно соответствовать сущности %ContentType;. Давайте найдём в файле DTD определение данной сущности:

<!ENTITY % ContentType "CDATA">

Это значит, что данный атрибут может содержать только символьные данные (текст). Обычно, в элементе style в данном атрибуте записано text/css. Если же посмотреть на атрибут xml:space, то он может содержать только значение preserve.

Попробуем создать весь HTML-элемент:

<style type="text/css" xml:space="preserve" media="all">
	a
	{
		color: #444;
	}
</style>

Данный элемент является валидным сам по себе. Но посмотрим же на другое использование данного элемента:

<style media="print">
	#footer
	{
		display: none;
	}
</style>

В этом случае элемент не является валидным, так как он не соответствует указанному набору правил, а именно не содержит в себе обязательный атрибут type.

Читаем DTD

Настало время проследить за тем, как можно использовать DTD в практических целях. К примеру, с помощью него мы можем узнать, как нам следует записывать те или иные элементы XHTML.

Давайте попробуем найти все блоковые элементы с помощью DTD:

<!ENTITY % Block "(%block; | form | %misc;)*">

Мы видим, что это определение включает в себя два других определения. Найдём же и их:

<!ENTITY % block
     "p | %heading; | div | %lists; | %blocktext; | fieldset | table">

Видим, что мы подобрались ещё ближе. Осталось найти ещё и объявленные здесь элементы — %heading;, %blocktext; и %lists; — и мы узнаем все блоковые элементы в HTML.

Давайте посмотрим на элемент h1:

<!ELEMENT h1  %Inline;>
<!ATTLIST h1
   %attrs;
   >

Видим, что данный элемент может содержать в себе только элементы, описанные в сущности %Inline;, поэтому нам стоит найти её и все используемые в ней другие сущности:

<!ENTITY % Inline "(#PCDATA | %inline; | %misc.inline;)*">

<!ENTITY % misc.inline "ins | del | script">

<!ENTITY % inline "a | %special; | %fontstyle; | %phrase; | %inline.forms;">

<!ENTITY % special
   "%special.pre; | object | img ">

<!ENTITY % special.pre
   "br | span | bdo | map">

<!ENTITY % fontstyle "tt | i | b | big | small ">

<!ENTITY % phrase "em | strong | dfn | code | q |
                   samp | kbd | var | cite | abbr | acronym | sub | sup ">

<!ENTITY % inline.forms "input | select | textarea | label | button">

Видим, что h1 может содержать все элементы текстового уровня, а также обычный набор символов (#PCDATA). Кроме того, отсюда сразу же можно сделать вывод о том, что данный элемент не может содержать в себе блоковые элементы: другие заголовочные элементы, параграфы, div, однако может содержать span, так как:

<!ENTITY % special.pre
   "br | span | bdo | map">

Здесь мы видим искомый наш элемент. Но вернёмся к нашему элементу h1. Видим в списке атрибутов лишь одну запись &attrs;, поэтому ищем запись вида <!ENTITY % attrs …:

<!ENTITY % attrs "%coreattrs; %i18n; %events;">

Вот оно: мы видим, что здесь используются другие группы элементов. Заметьте, что можно сразу же понять смысл определённых групп элементов: %events — это атрибуты для описания событий, %i18n — атрибуты для описания параметров интернационализации (языков, направления текста). Найдём, к примеру, последние:

<!ENTITY % i18n
 "lang        %LanguageCode; #IMPLIED
  xml:lang    %LanguageCode; #IMPLIED
  dir         (ltr|rtl)      #IMPLIED"
  >

Мы видим три определённых атрибута: lang, xml:lang, dir. Первые два содержат в себе описание языка, а последний может содержать только одно из двух значений: либо ltr, либо rtl.

Итоги

Многие считают, что DTD уже отживает своё. W3C продвигает новую XML Schema, которая в будуем заменит все декларации DTD. XML Schema является более органичной в том плане, что она сама написана с использованием XML и её легче обрабатывать, чем DTD. Что-ж, время покажет, но пока в интернете господствуют HTML 4, XHTML 1.0 рано хоронить DTD.

Да прибудут с вами спецификации, уважаемые читатели.

Давайте попробуем сегодня достичь подобного результата. Думаю, что у нас всё получится (впрочем, как всегда).

Теоретические изыскания

Как же можно облегчить жизнь тому, кто хочет каким-либо образом изменить, дополнить или перекроить Web-документы? Можно попробовать разделить документ на слои, чтобы легче было работать с каждым из них. Чтобы легче было понять смысл слоёных документов, представим себе следующую картину: у нас есть документ, содержащий в себе заголовок, основную часть и подвал. Мы хотим добавить к заголовку ещё и подзаголовок, но у нас сложилась такая ситуация, что мы не можем напрямую изменить содержимое документа (например, мы пишем расширение Firefox, или скрипт Greasemonkey и подобные) или нам нужно ненавязчиво расширить функциональность какого-то блока нашего документа (например, в экспериментальных целях). В обычной ситуации, мы бы перебирали всё DOM-дерево, чтобы добраться до нужного нам узла, после этого использовали ещё дюжину DOM-функций для дополнения искомого элемента до нужного нам представления. Согласитесь, что выполнять такое каждый раз — достаточно утомительное занятие. Как же избежать подобного?

Сделаем так: на основной странице ключевые элементы обычно всегда определяются по атрибуту id. Этим мы и воспользуемся: будем через AJAX подгружать нужный нам XML-файл, в котором будет описание слоя-настилки на наш документ. Посмотрим пример такого слоя:

<?xml version="1.0" encoding="utf-8" ?>
<collection>

	<overlay name="Header overlaying"
			 id="header"
			 insert="end"
			 type="plain">
		<![CDATA[<h2>Subtitle</h2>]]>
	</overlay>

</collection>

Данный слой накладывается на элемент с атрибутом id, равным header после всех существующих там элементов (атрибут insert со значением end). Само содержимое нового слоя содержится в специальном элементе CDATA, чтобы парсер не воспринимал всё содержимое элемента как XML, а считал его обычным текстом (при этом обязательно использование атрибута type со значением plain). С другой стороны, мы можем записывать содержимое слоя-настилки в виде XML, но тогда потребуется дополнительная процедура обработки содержимого слоя-настилки для превращения всех XML-элементов в XHTML-элементы.

Посмотрим на наш основной документ:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="ru" xml:lang="ru" xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<title>JsOverlay</title>
	</head>
	<body>

		<div id="header">
			<h1>Page title</h1>
		</div>

		<div id="content">
			<p>
				This is page content
			</p>
		</div>

		<div id="footer">
			<p>
				Footer, footer
			</p>
		</div>
	</body>
</html>

Всё становится предельно понятно: наш слой при наложении на документ образует симбиоз элементов, изменяя структуру документа до нужной нам:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="ru" xml:lang="ru" xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<title>JsOverlay</title>
	</head>
	<body>

		<div id="header">
			<h1>Page title</h1>
			<!-- Вот он, наш добавленный элемент -->
			<h2>Subtitle</h2>
		</div>

		<div id="content">
			<p>
				This is page content
			</p>
		</div>

		<div id="footer">
			<p>
				Footer, footer
			</p>
		</div>
	</body>
</html>

Маленькая деталь: предыдущий пример немного лукавит, так как перед тем, как наложить слой на документ, он оборачивается в элемент div с установленным атрибутом id для того, чтобы позже можно было бы проводить операции с данным слоем (удалять, например).

Что-ж, перейдём к практической части нашего повествования.

Практические изыскания

Сделаем для нашей теории небольшую практическую реализацию в качестве примера. Назовём наш класс-синглтон JSOverlay и создадим для него отдельное пространство имён:

var JSOverlay =
{

Далее, нам понадобится ассоциативный массив для хранения загруженных слоёв (чтобы их можно было контролировать после загрузки):

Overlays : {},

Мы уже сейчас можем реализовать метод для получения слоя (или слоёв, так как одному элементу может быть назначено несколько слоёв):

GetOverlayById : function(overlayid)
	{
		if (JSOverlay.overlays[overlayid] != null)
		{
			//Возвращаем всё, что найдено
			return JSOverlay.overlays[overlayid];
		}
		else
		{
			//Ничего не найдено
			return false;
		}
	},

Опишем класс слоя, чтобы было легче управлять столь одинаковыми сущностями:

Overlay : function()
	{

Нам понадобится структура информации о слое, которая должна состоять из имени слоя, его типа и позиции. Создадим её:

this.meta =
		{
			"name"   : null,
			"insert" : "end",
			"type"	 : null
		};

Чтобы не разбрасывать ассоциированные элементы, заключим их также в одну структуру:

this.elements =
		{
			//Контейнер слоя
			"container" : null,
			//Содержимое слоя (CDATA или чистый XML)
			"content"	: null,
			//Элемент, который мы дополняем (исходный элемент)
			"element"	: null
		};

Вслед за этим, реализовываем методы, необходимые для утилизации возможностей слоя:

this.attach = function()
		{
			//Создаём контейнер
			this.elements.container = document.createElement("div");
			//Атрибут id контейнера равен jsoverlay-<id-исходного-элемента>
			this.elements.container.id = "jsoverlay" +
										 ((this.elements.element.id != "") ? "-" + this.elements.element.id : "-body-element");

			//Заполняем его содержимое
			if (this.meta.type == "plain")
			{
				for (var i = 0; i < this.elements.content.childNodes.length; i++)
				{
					if (this.elements.content.childNodes[i].nodeType == 4)
						this.elements.container.innerHTML = this.elements.content.childNodes[i].nodeValue;
				}
			}
			else if (this.meta.type="xml">
			{
				//Если необходимо, это также можно реализовать
			}

			//Прибавляем контейнер в нужное местоположение
			switch (this.meta.insert)
			{
				case "end":
					this.elements.element.appendChild(this.elements.container);
				break;
				case "start":
					this.elements.element.insertBefore(this.elements.container,
													   this.elements.element.firstChild);
				break;
			}
		}

И ещё один метод, для отделения нового слоя от исходного элемента:

this.remove = function()
		{
			//Удаляем грязно
			this.elements.element.removeChild(this.elements.container);

			//Обнуляем контейнер
			this.elements.container = null;
		}

Заметьте, что мы не удаляем весь слой, а только то, что он внедряет на страницу. Осталось только завершить наш класс:

},

Двигаемся дальше. Теперь нам нужен метод уже пространства имён JSOverlay для загрузки нашего слоя. По сути, мы разделим данный метод на два метода: собственно загрузка и обработка XML-данных вместе с созданием, добавлением и активацией слоя. Начнём с загрузки через XMLHttpRequest (нет ничего проще):

LoadOverlay : function(overlayfile)
	{
		var Request = false;

		if (window.XMLHttpRequest)
		{
			Request = new XMLHttpRequest();
		}
		else if (window.ActiveXObject)
		{
			try
			{
				Request = new ActiveXObject("Microsoft.XMLHTTP");
			}
			catch (Exp)
			{
				try
				{
					Request = new ActiveXObject("Msxml2.XMLHTTP");
				}
				catch (ExpCascade)
				{
					//Очень жаль
					Request = false;
				}
			}
		}

		//Что?! Браузер не поддерживает XMLHttpRequest? С ума сойти!
		if (!Request)
			return false;

		//Создаём GET-запрос к XML-файлу с нашим слоем
		Request.open("GET", overlayfile);

		Request.onreadystatechange = function()
		{
			//Вроде всё хорошо
			if (Request.readyState == 4)
			{
				//Ещё раз убеждаемся, что всё действительно хорошо
				if (Request.status != 200 && Request.status != 304)
				{
					//Заберите меня отсюда!
					return;
				}

				//Вызываем обработчик XML-данных
				JSOverlay.ParseOverlay(Request.responseXML);

			}
		}

		//Отсылаем запрос
		Request.send(null);
	},

Понятно, что с помощью вышеописанного метода мы сможем загружать слои как JSOverlay.LoadOverlay("overlay/my.xml");. Естественно, путь, который загружается с помощью данного метода, должен существовать, иметь Content-Type text/xml (или один из подобных) и содержать в себе валидный и соответствующий XML.

Мы не реализовали последний метод, сделаем же это:

ParseOverlay : function(XmlOverlayDocument)
	{
		try
		{
			//Получаем набор слоёв
			var XmlOverlays = XmlOverlayDocument.getElementsByTagName("overlay");

			//Один файл может содержать несколько слоёв
			for (var i = 0; i < XmlOverlays.length; i++)
			{
				//Текущий слой
				var XmlCurrentOverlay = XmlOverlays[i];

				//Создаём новый экземпляр класса
				var Overlay = new JSOverlay.Overlay();

				//Метаинформация
				Overlay.meta.name   = XmlCurrentOverlay.getAttribute("name");
				Overlay.meta.insert = XmlCurrentOverlay.getAttribute("insert");
				Overlay.meta.type   = XmlCurrentOverlay.getAttribute("type");
				//Получаем id исходного элемента
				var element_id = XmlCurrentOverlay.getAttribute("id");

				//Типичные ситуации
				switch (element_id)
				{
					//Нужно присоединить к body
					case "body":
						element_id = document.body;
					break;

					default:
						element_id = document.getElementById(element_id);
					break;
				}

				if (element_id != null)
				{
					//Устанавливаем исходный элемент
					Overlay.elements.element = element_id;

					//Устанавливаем содержимое
					Overlay.elements.content = XmlCurrentOverlay;

					//Подключаем
					Overlay.attach();

					if (JSOverlay.overlays[element_id.id] == null)
					{
						JSOverlay.overlays[element_id.id] = [];
					}

					//Добавляем новый слой в массив слоёв для данного элемента
					JSOverlay.overlays[element_id.id].push(Overlay);
				}
				else
				{
					continue;
				}
			}

		}
		catch (excp)
		{
			return false;
		}
	}

Готово! Всё, что получилось, можно посмотреть на странице-примере, открыв её исходные коды.

Что можно добавить?

Чтобы облегчить себе жизнь в некоторых ситуациях, можно превратить overlay.js в какой-нибудь серверный скрипт, который будет генерировать JavaScript-код для подключения разных слоёв. К примеру, можно сделать так: при обращении к /overlay/add/ генерируется JavaScript для подключения слоя с именем .

Выводы

Представленный прототип уже сейчас может выполнять возложенные на него обязанности, но его можно расширять до бесконечности: поддержка стилей, встроенных в расширение скриптов (хотя, этого можно достичь, просто прописав в нём элемент script, который будет подключать внешний файл с кодом), дерева DOM (для поиска элементов не только по id, но и по другим отличительным чертам, например, по атрибуту class или и вовсе по произвольному атрибуту элементов). Можно даже периодически заглядывать на вышеуказанную страницу с примером, так как иногда там будет появляться новая версия небольшого скрипта.

Как всегда, в конце записи желаю моим читателям хорошего настроения на все выходные.