![]() |
![]() |
|
![]() Главная страница Библиотека (скачать книги) Скачать софт Введение в программирование Стандарты для C++ Уроки по C# Уроки по Python HTML Веб-дизайн Ассемблер в среде Windows ActiveX Javascript Общее о Линукс Линукс - подробно Линукс - новое Delphi Паскаль для начинающих Турбопаскаль Новости Партнеры Наши предложения Архив новостей |
Урок 8. Полезные советы
В каждом отдельно взятом файле (статья, описание продукта, поисковый механизм и т. п.) описание внешнего вида данной страницы должно сводиться к минимуму. Например, разбивка на абзацы. А если страницы включаются в файл, который обрабатывает их, то оформление текста абзаца нужными тэгами может происходить и на сервере.
Пожалуйста, не делайте разбивку на абзацы при помощи тэга <br>... И еще хуже — с помощью него же плюс несколько неразрывных пробелов в начале, чтобы имитировать книжный вид абзацев. Представьте, что с вашего сайта берут текст, копируют его в программу верстки, назначают стиль и, тихо ругаясь матом, убирают лишние пробелы, а потом еще разбивают один ваш большой абзац в местах принудительного перевода строки на настоящие абзацы. Книжный вид абзацев можно, например, имитировать так:
Принципиальным является то, что оформление должно быть собрано в отдельных файлах, которые просто связываются с содержательными файлами явно (например, включением таблиц стилей) или автоматически (предварительная обработка корневым файлом остальных на сервере и выдача посетителю страницы, сформированной из нескольких файлов). Серверные технологии тут всегда предпочтительнее, потому что они позволяют гибко управлять взаимоотношениями файлов.
Вырежи и сохрани 1. Серверных решений может быть несколько. Самое простое — включение на сервере в каждый из содержательных файлов одного или двух «оформительских» файлов (например, в верхнем шапка и меню, а в нижнем — нижняя панель с адресом компании и строкой поиска). Это делается с помощью директив include или require в зависимости от языка (поддерживается PHP, Perl, ASP, SSI и другими языками).
Второй способ (действует на сервере Apache) — использование файла .htaccess, в котором пишутся директивы, автоматически вставляющие файлы с оформлением в начало или конец страницы. Способ удобнее тем, что имя одного из файлов может поменяться, а нижний блок вообще дизайнер захочет убрать. Наконец, есть третий способ: обратное включение. Это значит, что есть файл с «ядерным сценарием», или «ядром», который берет откуда-то (например, из переменной $QUERY STRING, читающей строку запроса из адресной строки) данные о том файле, который нужно вывести, обрабатывает его, а затем включает в себя и выводит на экран. Очень гибкий способ, имеющий массу реализаций. В итоге всех этих манипуляций с файлами у нас остается не так уж много: девственно чистые файлы с содержанием страниц и заголовками (опороченные разве что разбивкой на абзацы или иными тэгами, обеспечивающими грамотную и красивую верстку), с одной стороны, и файлы сценариев по обработке страниц — с другой. Каждый отвечает только за порученные ему задачи.
2. В тексте, конечно, допустима разметка. Желательно, чтобы имена классов были не произвольными, а семантическими. Согласитесь, если вы назовете класс «advice», то в дальнейшем класс блоков, отвечающий за советы пользователю, вы можете оформить как угодно, тогда как если вы назовете его «blueframe», то при смене дизайна необходимо будет сменить и имя стиля — вдруг вы решите заключить все советы в красную рамку? А советов в ста пятнадцати файлах уже набралось порядка тысячи...
3. Последнее важное правило: автоматизируйте повторы. Если у вас на одной странице повторяются блоки текста с одинаковым оформлением, то, возможно, стоит этот текст вынести в отдельный файл, разграничить значимые блоки разделителями (например, |) и написать в основном файле страницы сценарий, который будет разбивать текст на фрагменты, заносить фрагменты в массив и на основе этого массива формировать цикл с повторением кода, оформляющего внешний вид текста. Автоматизация, естественно, не замыкается на этом примере. Основная мысль заключается в том, что, если встречаются повторяющиеся фрагменты кода (и есть вероятность, что количество повторов будет больше двух или трех), лучше доверять делать такие повторы скриптам.
Для хранения же «чистых» данных есть два основных способа: базы данных и файлы. В первом случае данные, связанные друг с другом, просто разнесены в разные ячейки виртуальной таблицы, где все строки пронумерованы, а столбцы поименованы. А с файлами можно поступить по-разному: либо хранить все значимые фрагменты в отдельных небольших файлах, либо (как было описано выше) разделять фрагменты данных в одном файле — после чего анализировать файл скриптом, — либо использовать одну из форм XML (семантически размеченные файлы). Последнее зависит от ваших потребностей. Если XML-файлы для вас — это основное хранилище данных со сложной рубрикацией, то стоит использовать собственно язык XML в связке с XSLT-преобразо- ваниями, причем желательно на сервере с помощью модулей языков веб-программирования — браузеры не всегда корректно интерпретируют эту связку. Если пойти по пути наименьшего сопротивления, то можно разные фрагменты данных заключать в тэги, принятые на вашем сайте (например, <comments>тэги комментариев</comments>), а функцию разбора файла на фрагменты, ограниченные этими тэгами, возложить на самостоятельно написанный скрипт. Практика показывает, что такой скрипт вполне можно уместить в 10 строчек:
Такой подход облегчает изменение структуры: правка вида всех повторяющихся фрагментов производится только в одном месте.
Резюме Использование смысловой (семантической) разметки веб-страниц делает возможными многоаспектную автоматическую обработку текстов и гибкое управление данными. |
|
Библиотека программиста. 2009. |
|