ErlangРаботыРевюСтатьиКнигаЗаказ
 

В сторону смысла

Кирилл Панфилов

Лучше день потерять, а потом за пять минут долететь!

Понятия «форма» и «содержание» появились очень давно. Аналогично, важность разграничения формы и содержания тоже была осознана давным-давно. Тем не менее, при создании веб-страниц принцип такого разграничения проводится далеко не всегда.

Типичный пример — редизайн. Первый (штатный) дизайнер делает сайт, состоящий из 214 страниц в формате .html, в каждом из них пишет навигационное меню, а стили в связанном CSS-файле описывают только цвет ссылок и нулевые отступы по краям страницы. На каждой странице он заголовки выделяет не тэгом <H1>, а сочетанием тэгов <B> и <font size=+4>, причём не всегда закрывает их. Потом дизайнер увольняется. Шедевр висит на сервере два года, а потом руководству сообщают, что сайт не соответствует современным требованиям, плюс к тому — на нём нельзя оставить отзыв, сделать заказ и отправить письмо. Руководство раскошеливается и приглашает веб-дизайнера со стороны. Тот смотрит файлы сайта и ужасается. Потому что переделать это невозможно: проще сделать заново.

Почему так происходит? Потому что первый дизайнер брал страницы одну за другой и просто вставлял новый текст вместо старого. Потому что он не смотрел вперёд и не думал, что сайт нужно будет переделывать: например, добавить пару разделов (из-за чего 214 раз придётся переписывать фрагмент кода, отвечающий за навигацию). Изменить раздел логотипа (аналогичный объём переделок). Он не думал, что любой поисковой системе будет сложно автоматически вычленить заголовок страницы из массива текста, не размеченного логически. Он вообще не осознавал, что фрагменты веб-страницы могут обладать семантикой. Не думал, что можно разметить их не формальными тэгами (которые только изменяют внешний вид), а логическими. Дело в том, что если вид заголовков, размеченных парой тэгов <H1>…</H1>, разонравился, его можно изменить правкой всего одной строки в CSS-файле, а не редактировать 214 страниц. Аналогично, если есть семантически схожие блоки текста, их можно оформить парой <SPAN CLASS="…">…</SPAN> и придумать имя класса, который будет описан в том же CSS-файле.

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

1.

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

Пожалуйста, не делайте разбивку на абзацы при помощи тэга <BR>… И ещё хуже — с помощью него же плюс несколько неразрывных пробелов в начале, чтобы имитировать книжный вид абзацев. Представьте, что с вашего сайта берут текст, копируют его в программу вёрстки, назначают стиль и, тихо ругаясь матом, убирают лишние пробелы, а потом ещё разбивают один ваш большой абзац в местах принудительного перевода строки на настоящие абзацы… Книжный вид абзацев можно, например, имитировать так: <P STYLE="text-indent:2em; margin:0px">…</P>.

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

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

Вырежи и сохрани
Серверных решений может быть несколько. Самое простое — включение на сервере в каждый из содержательных файлов одного или двух «оформительских» файлов (например, в верхнем шапка и меню, а в нижнем — нижняя панель с адресом компании и строкой поиска). Это делается с помощью директив include или require в зависимости от языка (поддерживается PHP, Perl, ASP, SSI и другими языками). Второй способ (действует на сервере Apache) — использование файла .htaccess, в котором пишутся директивы, автоматически вставляющие файлы с оформлением в начало или конец страницы. Способ удобнее тем, что имя одного из файлов может поменяться, а нижний блок вообще дизайнер захочет убрать. Наконец, есть третий способ: обратное включение. Это значит, что есть файл с «ядерным сценарием», или «ядром», который берёт откуда-то (например, из переменной QUERY_STRING, читающей строку запроса из адресной строки) данные о том файле, который нужно вывести, обрабатывает его, а затем включает в себя и выводит на экран. Очень гибкий способ, имеющий массу реализаций.

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

2.

В тексте, конечно, допустима разметка. Но, учитывая реализацию языков разметки в современных браузерах (на момент написания статьи — Internet Explorer 7, Netscape 8, Opera 9, Firefox 2, Safari 2 [обещают 3], Konqueror 3.5 и т. п.), вполне можно обойтись тэгами <DIV> и <SPAN> с классами, которые описываются в связанном CSS-файле, заголовочными тэгами, ссылками и картинками. Желательно, чтобы имена классов были не произвольными, а семантическими. Согласитесь, если вы назовёте класс «advice», то в дальнейшем класс блоков, отвечающий за советы пользователю, вы можете оформить как угодно, тогда как если вы назовёте его «blueframe», то при смене дизайна необходимо будет сменить и имя стиля — вдруг вы решите заключить все советы в красную рамку? А советов в ста пятнадцати файлах уже набралось порядка тысячи…

3.

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

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

Для хранения же «чистых» данных есть два основных способа: базы данных и файлы. В первом случае данные, связанные друг с другом, просто разнесены в разные ячейки виртуальной таблицы, где все строки пронумерованы, а столбцы поименованы. А с файлами можно поступить по-разному: либо хранить все значимые фрагменты в отдельных небольших файлах, либо (как было описано выше) разделять фрагменты данных в одном файле — после чего анализировать файл скриптом,— либо использовать одну из форм XML (семантически размеченные файлы). Последнее зависит от ваших потребностей. Если XML-файлы для вас — это основное хранилище данных со сложной рубрикацией, то стоит использовать собственно язык XML в связке с XSLT-преобразованиями, причём желательно на сервере с помощью модулей языков веб-программирования — браузеры не всегда корректно интерпретируют эту связку. Если пойти по пути наименьшего сопротивления, то можно разные фрагменты данных заключать в тэги, принятые на вашем сайте (например, <COMMENTS>тэги комментариев</COMMENTS>), а функцию разбора файла на фрагменты, ограниченные этими тэгами, возложить на самостоятельно написанный скрипт. Практика показывает, что такой скрипт вполне можно уместить в 10 строчек.

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

Резюме

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