ADDRESS

<!ENTITY % address.content "((%text;) | P)*"> <!ELEMENT ADDRESS - - %address.content>

При внесении в документ элемента ADDRESS необходимо указывать как

начальный, так и конечный тэги, а также такую информацию, как авторство и сведения,

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

должны воспроизводить содержимое этого элемента в виде отдельного параграфа (или

группы параграфов). Заметим, что внутри этого элемента могут содержаться элементы

параграфов, простой текст и элементы текстового уровня (имеющие в HTML3.2 DTD запись

%text).

Пример:

Newsletter editor<BR>

J.R. Brown<BR>

8723 Buena Vista, Smallville, CT 01234<BR>

Tel: +1 (123) 456 7890

</ADDRESS>

Аннотация

Язык разметки гипертекста (HTML) является простым средством разметки, предназначенным для создания гипертекстовых документов, легко переносимых с одной платформы на другую. Документы на языке HTML, являющегося разновидностью SGML, имеют универсальную семантику, которая дает возможность предоставлять информации из большого набора приложений. Данная спецификация определяет версию 3.2 языка HTML. Цель разработчиков HTML 3.2 заключалась в обобщении практических рекомендаций, накопленных с начала 1996 года, а также в том, чтобы подготовить замену для версии 2.0 языка HTML ().

APPLET (Апплеты Java)

<!ELEMENT APPLET - - (PARAM | %text)*> <!ATTLIST APPLET codebase %URL #IMPLIED -- code base -- code CDATA #REQUIRED -- class file -- alt CDATA #IMPLIED -- for display in place of applet -- name CDATA #IMPLIED -- applet name -- width %Pixels #REQUIRED -- suggested width in pixels -- height %Pixels #REQUIRED -- suggested height in pixels -- align %IAlign #IMPLIED -- vertical or horizontal alignment -- hspace %Pixels #IMPLIED -- suggested horizontal gutter -- vspace %Pixels #IMPLIED -- suggested vertical gutter -- > <!ELEMENT PARAM - O EMPTY> <!ATTLIST PARAM name NMTOKEN #REQUIRED -- The name of the parameter -- value CDATA #IMPLIED -- The value of the parameter -- >

Для данного элемента необходимо указывать и начальный, и конечный тэги. Поддерживается всеми браузерами, имеющими поддержку для языка Java. Данный элемент позволяет включать апплеты Java прямо в HTML-документы. Для передачи параметров такому апплету в блок APPLET должны заноситься соответствующие элементы PARAM. Вслед за элементами PARAM в теле APPLET-а должна даваться альтернативная информация для тех браузеров, которые не имеют средств для поддержки языка Java. При этом подобная информация должна ограничиваться элементами разметки на уровне текста, указанными в блоке %text в DTD. Java-совместимые браузеры игнорируют указанный дополнительный блок информации, написанный на языке HTML. Вы можете также использовать описанную возможность для контроля за ходом выполнением апплета, публикуя здесь текст, поясняющий его действия. Среди других возможных применений альтернативного блока информации - переадресация читателя на страницу с разметкой, более приемлимой для браузеров, не имеющих поддержки языка Java, либо просто распечатка очередной колкости в адрес пользователя, не имеющего Java-совместимого браузера.

Простой пример использования Java-апплета:

<applet code="Bubbles.class" width=500 height=500> Java апплет, рисующий движущиеся пузыри. </applet>

Другой пример, где уже задействован элемент PARAM:

<applet code="AudioItem" width=15 height=15> <param name=snd value="Hello.au|Welcome.au"> Java апплет, исполняющий мелодию приглашения. </applet>

codebase = codebaseURL

Необязательный атрибут, задающий для данного апплета базовый URL-адрес. Это может

быть каталог или папка, где содержится его код. Если же данный атрибут не указан, то в

качестве базового используется URL-адрес самого HTML-документа.

code = appletFile

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

подкласс Applet, используемый в данном апплете. Указываемый в атрибуте адрес не

является абсолютным, а отсчитывается начиная с базового URL-адреса текущего апплета.

alt = alternateText

Необязательный атрибут, содержащий некий текст, который должен быть выведен на

экран, если браузер пользователя понимает тэг APPLET, но не может по каким-либо

причинам запускать на выполнение апплеты Java.

name = appletInstanceName

Необязательный атрибут, дающий название данному апплету. Последнее позволяет любым

апплетам, находящимся на одной и той же странице, находить друг друга (и

взаимодействовать).

width = пикселов

height = пикселов

Обязательные атрибуты, определяющие (в пикселах) исходные ширину и высоту окна, в

котором будет работать данный апплет. Это не относится к другим рабочим и диалоговым

окнам, генерируемым уже в ходе выполнения апплета.

align = alignment

Обязательный атрибут, указывающий способ выравнивания для данного апплета.

Возможные значения этого атрибута - те же самые (и с тем же результатом), что и для

элемента IMG: top, middle, bottom,

left и right,

vspace = pixels

hspace = pixels

Необязательные атрибуты, определяющие (в пикселах) ширину чистых полей над и под

текущим апплетом (VSPACE), либо слева и справа (HSPACE). В

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

IMG, когда он имеет атрибуты VSPACE и HSPACE.

Элемент PARAM используется для передачи апплету

именованных параметров:

<PARAM NAME = ПараметрАпплета VALUE =

значение>

Элементы PARAM - единственная возможность передавать параметры для

апплета. Апплеты читают выбранные пользователем параметры посредством метода

getParameter().

name = название параметра для апплета

value = значение параметра

Объекты-символы языка SGML, такие как é,

" и ¹, проходят

расшифровку перед тем, как параметры будут переданы апплету. Чтобы в качестве

параметра использовать символ &, замените его объектом &.

Замечание: Элементы PARAM должны стоять в самом начале контейнера

APPLET. Они не были занесены в состав DTD из-за технических особенностей

SGML моделей со смешанным контексом.

ASP-программирование: сравнение VBScript, JScript, PerlScript

ASP-страницы, почему-то, всегда связывают со скриптом VBScript. Хотя это, наверное, худший из возможных вариантов. ASP могут быть написаны на любом WSH (Windows Scription Host)-cовместимом скриптовом языке. Рассмотрим 3 варианта - VBScript, JScript, PerlScript. Первые два - VBScript & JScript поддерживаются Miscrosoft, и не требуют дополнительных инсталляций. PerlScript автоматически устанавливается при инсталляции . Сравним эти три варианта.

BASE

<!ELEMENT BASE - O EMPTY> <!ATTLIST BASE href %URL #REQUIRED >

Элемент BASE указывает для данного документа базовый адрес URL, который затем будет использоваться при переопределении относительных адресов URL с использованием правил, задаваемых соответствующей спецификацией URL. Например, в случае разметки <BASE href="http://www.acme.com/intro.html"> ... <IMG SRC="icons/logo.gif">

соответствующее изображение будет соотнесено с источником http://www.acme.com/icons/logo.gif

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

BASEFONT

<!ELEMENT BASEFONT - O EMPTY -- base font size (1 to 7) --> <!ATTLIST BASEFONT size CDATA #IMPLIED -- e.g. size=4, defaults to 3 -- >

Указывает базовый размер шрифта. BASEFONT является пустым элементом,

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

атрибут SIZE, которому можно присваивать целые значения в пределах от 1

до 7. Указываемый ими базовый размер шрифта используется при печати нормального и

предварительно форматированного текста. Однако это не относится к заголовкам, за

исключением тех случаев, когда в них используется элемент FONT с

указанием относительного размера шрифта.

Благодарности

Автор выражает благодарность членам редакторского совета W3C HTML, штатным

сотрудникам W3C, а также тем, кто внес вклад в разработку этой спецификации.

Блочные элементы разметки

параграфы

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

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

одного параграфа используйте атрибут ALIGN, например <P

неупорядоченные списки

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

один или несколько элементов LI, представляющие отдельные пункты списка.

упорядоченные (т.е. нумерованные) списки

Здесь также требуется указывать как начальный, так и конечный тэги, а также один

или несколько элементов LI, представляющие в списке отдельные пункты.

списки определений

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

DT размечается термин, а элементом DD - соответствующее ему

определение.

преформатированный текст

Для данного элемента необходимо указывать начальный и конечный тэги. Внутри такого

элемента текст печатается шрифтом фиксированной ширины и при этом сохраняется разметка

оригинала (пробелы и символы конца строк).

деление документа на отдельные блоки

Для данного элемента необходимо указывать как начальный, так и конечный тэги.

Элемент DIV обычно используется с атрибутом ALIGN,

указывающим способ выравнивания текста внутри тех блочных элементов, которые его

содержат. Элемент ALIGN может иметь одно из следующих значений:

LEFT, CENTER или RIGHT.

выравнивание текста

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

для центрирования стоящего между ними текста. Более радикальное решение проблемы

выравнивания текстов см. в DIV.

разметка цитат

Необходимо указывать как начальный, так и конечный тэги. Данный элемент

используется при разметке протяженных цитат, текст которых при этом обычно печатается

со сдвинутыми краями.

заполняемые формы

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

заполняемой формы, которая будет обработываться на HTTP сервере. Атрибутами этого

элемента могут быть ACTION, METHOD и ENCTYPE.

Заполняемые формы не могут быть вложены друг в друга.

примитивные формы HTML

Данный элемент не является контейнером, так что конечный тэг для него использовать

нельзя. Подменяет элемент FORM и используется для создания простых форм,

имеющих единственное поле под ввод текста. В документе может использоваться только

один элемент ISINDEX, появляющийся в заголовке, либо основном тексте.

горизонтальные линейки

Не является контейнером, так что использовать конечный тэг нельзя. Может иметь

атрибуты ALIGN, , SIZE и

WIDTH.

таблица, может быть вложенной

Требуется указывать начальный и конечный тэги. Каждая таблица начинается с

необязательного элемента CAPTION, за которым следует один или несколько

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

несколько ячеек, задаваемых элементами TH или TD . Элемент

TABLE может иметь атрибуты WIDTH, BORDER,

CELLSPACING и CELLPADDING.

BLOCKQUOTE

<!ELEMENT BLOCKQUOTE - - %body.content>

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

They went in single file, running like hounds on a strong scent, and an eager light was in their eyes. Nearly due west the broad swath of the marching Orcs tramped its ugly slot; the sweet grass of Rohan had been bruised and blackened as they passed.

from "The Two Towers" by J.R.R. Tolkien.

BR - концы строк

Используется для принудительного завершения текущей строки. Является пустым

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

чтобы новая строка не "наезжала" на уже имеющиеся изображения, в тэге может

использоваться атрибут CLEAR. Так в результате использования атрибута

<BR CLEAR=LEFT> новая строка начнется уже подо всеми изображениями,

имеющимися с левой стороны листа, точно так же атрибут <BR

CLEAR=RIGHT> заставит новую строку спуститься ниже всех изображений на

правой половине листа, и наконец, атрибут <BR CLEAR=ALL> заставит

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

Декларация языка HTML 3.2 в SGML

Используется 8-битный набор символов ISO Latin-1. По сравнению с версией HTML 2.0

значительно увеличен предельный размер для заголовков и названий тэгов, однако

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

ограничений на длину элементов разметки.

<!SGML "ISO 8879:1986" -- SGML Declaration for HyperText Markup Language version 3.2 With support for ISO Latin-1 and increased limits for tag and literal lengths etc. --

CHARSET BASESET "ISO 646:1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0"

DESCSET 0 9 UNUSED 9 2 9 11 2 UNUSED 13 1 13 14 18 UNUSED 32 95 32 127 1 UNUSED

BASESET "ISO Registration Number 100//CHARSET ECMA-94 Right Part of Latin Alphabet Nr. 1//ESC 2/13 4/1"

DESCSET 128 32 UNUSED 160 96 32

CAPACITY SGMLREF TOTALCAP 200000 GRPCAP 150000 ENTCAP 150000

SCOPE DOCUMENT SYNTAX SHUNCHAR CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127

BASESET "ISO 646:1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0"

DESCSET 0 128 0

FUNCTION RE 13 RS 10 SPACE 32 TAB SEPCHAR 9

NAMING LCNMSTRT "" UCNMSTRT "" LCNMCHAR ".-" UCNMCHAR ".-" NAMECASE GENERAL YES ENTITY NO DELIM GENERAL SGMLREF SHORTREF SGMLREF NAMES SGMLREF QUANTITY SGMLREF ATTSPLEN 65536 LITLEN 65536 NAMELEN 65536 PILEN 65536 TAGLVL 100 TAGLEN 65536 GRPGTCNT 150 GRPCNT 64

FEATURES MINIMIZE DATATAG NO OMITTAG YES RANK NO SHORTTAG YES LINK SIMPLE NO IMPLICIT NO EXPLICIT NO OTHER CONCUR NO SUBDOC NO FORMAL YES APPINFO NONE >

DIR и MENU

<!ELEMENT (DIR|MENU) - - (LI)+ -(%block)> <!ATTLIST (DIR|MENU) compact (compact) #IMPLIED >

Данные элементы были составной частью языка HTML с самых первых дней. Предназначение их - создание неотсортированных списков, подобных тем, что получаются при использовании элемента UL. Программам просмотра было рекомендовано воспроизводить элементы DIR в виде списка из нескольких колонок, а элемент MENU - в виде списка из одной колонки типа меню. На практике же, Mosaic и большинство других браузеров игнорировали это требование и осуществляли разметку элементов DIR и MENU точно так же, как и UL.

DIV и CENTER

<!ELEMENT DIV - - %body.content> <!ATTLIST DIV align (left|center|right) #IMPLIED -- alignment of following text -- >  <!ELEMENT center - - %body.content>

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

образом, внутри соответствующего элемента DIV можно использовать атрибут

ALIGN. При этом значением последнего могут быть LEFT,

CENTER или RIGHT (причем указанные значения имеют тот же

смысл, что и в случае параграфов <P>).

Заметим, что поскольку DIV является блочным элементом, в документе он

будет дополнительно играть роль закрывающего тэга для еще открытого элемента

P, если таковой имеется. В остальных случаях браузеры конечных

пользователей не должны делать разбивку на параграфы до и после элементов

DIV. Элемент CENTER полностью эквивалентен элементу

DIV с атрибутом ALIGN=CENTER. Для обоих элементов

DIV и CENTER надо указывать начальный и конечный тэги.

Элемент CENTER был введен в спецификацию браузера Netscape еще до

того, как в HTML 3.0 был внесен выполняющий аналогичную функцию элемент

DIV. Затем этот элемент был сохранен и в спецификации HTML 3.2 из-за

широко распространения упомянутого браузера.

FONT

<!ELEMENT FONT - - (%text)* -- local change to font --> <!ATTLIST FONT size CDATA #IMPLIED -- [+]nn e.g. size="+1", size=4 -- color CDATA #IMPLIED -- #RRGGBB in hex, e.g. red: color="#FF0000" -- >

Для элемента FONT необходимо указывать как начальный, так и конечный

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

двумя тэгами, размер шрифта и/или цвет. Возможные атрибуты - SIZE и

COLOR. Размер шрифта задается по некой шкале, самостоятельно определяемой

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

точки и другими единицами измерения. Предлагаемая в данной спецификации интерпретация

элемента FONT может иметь дальнейшее развитие в новых версиях языка HTML.

size

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

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

целое число от 1 до 7. Для шрифта можно также указывать относительный размер, сообщая

атрибуту целое число со знаком (например, это может быть size="+1" или

size="-2"). В последнем случае реальный размер шрифта определяется

суммированием указанного в атрибуте значения и текущего базового размера, заданного

элементом BASEFONT (см. ниже).

color

указывает цвет, которым будет выделен данный кусок текста. Цвета задаются в виде

RGB-значения с шестнадцатеричной нотацией, либо выбирается один из 16 стандартных

href="#colors">цветов, описанных в элементе

при рассмотрении атрибута BGCOLOR.

Браузеры некоторых разработчиков могут распознавать атрибут FACE,

значением которого является список шрифтов, приведенных через запятую в порядке

уменьшения приоритета. Если в системе клиента имеется шрифт с указанным названием, он

будет использоваться при воспризведении данного фрагмента. Атрибут FACE

официально не входит в состав языка HTML 3.2.

Результаты изменения абсолютного размера шрифта:

size=1

size=2

size=3

size=4

size=5

size=6

size=7

Результаты изменения относительного размера шрифта (базовый размер при этом равен

3):

size=-4

size=-3

size=-2

size=-1

size=+1

size=+2

size=+3

size=+4

То же самое, если базовый размер шрифта равен 6:

size=-4

size=-3

size=-2

size=-1

size=+1

size=+2

size=+3

size=+4

FORM

<!ENTITY % HTTP-Method "GET | POST" -- as per HTTP specification --> <!ELEMENT FORM - - %body.content -(FORM)> <!ATTLIST FORM action %URL #IMPLIED -- server-side form handler -- method (%HTTP-Method) GET -- see HTTP specification -- enctype %Content-Type; "application/x-www-form-urlencoded" >

Элемент FORM используется в языке разметки HTML для создания заполняемых форм. Причем вы можете иметь сразу несколько таких форм в одном и том же документе. Для элемента FORM во всех случаях необходимо писать и начальный, и конечный тэги. (Заметим, что для создания простейших форм Вы также можете воспользоваться элементом ). В пределах элемента FORM можно использовать большой набор элементов HTML, кроме того при создании форм вы можете задавать несколько типов (текстовые поля в одну или несколько строк, группы радиокнопок, контрольные квадратики, и меню).

Атрибуты элемента FORM:

action

Определяет URL адрес, который используется либо для отправления формы по

электронной почте (например, action="mailto:foo@bar.com"), либо для

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

данную форму (к примеру, action="http://www.acme.com/cgi-

bin/register.pl").

method

Если предыдущий атрибут action задает адрес HTTP-сервера, то атрибут method

определяет, какой из HTTP методов будет использоваться для пересылки этому серверу

содержимого текущей формы. Это может быть либо GET, либо

POST (по умолчанию используется GET).

enctype

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

содержания данной формы. По умолчанию используется application/x-www-form-

urlencoded.

Остальные подробности касательно работы с формами приводятся в документе RFC 1867.

Формированию уровня бизнес-логики

Объекты 2nd tier принято разделять на две группы - представляющие клиента и его действия (Session Beans в EJB), и представляющие сущности источника данных (Entity Beans в EJB). Cущности источника данных (в частности - БД) выявляются и формулируются на фазе планирования / разработки логической структуры проекта. К сожалению во многих проектах эти фазы отсутствуют как класс и правит тенденция к стихийному развитию структуры БД. Если вам достался подобный проект, то придется заново тщательно проработать структуру базы данных, выявлять основные сущности и распределить все таблицы к конкретным сущностям.

Объекты, представляющие клиента на 2nd tier, реализуют возможные действия клиента. Эти действия осуществляются только через объекты - сущности (и не через прямой доступ к DB). Поскольку хардкодить все, даже самые незначительные, операции в компилируемых объектах возьмется далеко не любая компания, можно предложить писать эти объекты на ASP в страницах, не содержащих HTML (см. главу о вынесении HTML из ASP). Тогда получается такое изменение схемы распределенной архитектуры для IIS/ASP/COM:

Мы можем выделить ASP-код, представляющий клиента, исключительно с бизнес-логикой, без HTML-форматирования и взаимодействия с пользователем. Как и в ситуации с хранимыми процедурами, такой отход от правила может быть, иногда, оправдан. Требования к нему просты: код бизнес-логики нужно организовать в независимую, от остального 1st tier, структуру объектов, которая не занимается делами 1st tier (т.е. никак не взаимодействует с пользователем напрямую). Этот код лучше хранить в отдельных файлах. А в обычном коде 1st tier использовать одинаковый интерфейс, способ создания и удаления таких встроенных ASP-объектов и настоящих 2nd tier объектов. В этом помогут, описанные ранее, Project ASP API и ObjectFactory. Тогда не возникнет "размазывания" кода бизнес-логики по интерфейсу пользователя, а, при необходимости, его легко можно будет вынести в настоящий 2nd tier объект.

Объекты, представляющие сущности на 2nd tier, реализуют следующие услуги:

вернуть атрибуты сущности по уникальному ключу;

искать сущность по условию;

искать группы сущностей по условию или работать как итератор;

изменить атрибуты сущности;

создать новую сущность;

удалить сущность;

Можно предложить написать унифицированный объект для работы с сущностями. Рассмотрим один из вариантов подобного подхода, основанный на SQL-шаблонах.

HR - горизонтальные линейки

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

где осуществляется переход от одного обсуждаемого вопроса к другому. В браузерах с

речевым интерфейсом такая линейка должна воспроизводиться как пауза в речи. <!ELEMENT HR - O EMPTY> <!ATTLIST HR align (left|right|center) #IMPLIED () #IMPLIED size %Pixels #IMPLIED width %Length #IMPLIED >

Элементы HR не являются контейнерами, так что конечный тэг

использовать в этом случае нельзя. Элемент может иметь атрибуты ALIGN,

, SIZE и WIDTH:

align

Определяет, сдвинута ли линейка влево, вправо или стоит на текущей строке по

центру (атрибуты align=left, align=center или

соответственно). По умолчанию линейка центрируется.

Данный атрибут заставляет программу пользователя закрашивать линейку сплошным

цветом, а не делать ее как традиционную двухцветную "выемку".

size

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

линейки.

width

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

пикселах (например width=100), либо как определенный процент от

расстояния между левым и правым ограничителями текущей строки (например

width="50%"). По умолчанию ширина линейки принимается равной 100 %.

HTML-форма и ее ASP-обработчик в одном файле

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

HTML как частный случай SGML

Язык HTML 3.2 является реализацией SGML - стандартного обобщенного языка разметки (Standard Generalized Markup Language), отвечающей требованиям международного стандарта ISO 8879. Являясь реализацией SGML, синтаксис документа HTML 3.2 определяется комбинацией и (DTD). Данная спецификация дает определенную интерпретацию для элементов HTML 3.2, а также накладывает новые ограничения на допустимый синтаксис самого языка, что вызвано трудностями его формализации в DTD.

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

<P>

Текст

эквивалентна:

<P>Текст

Аналогично, должен игнорироваться конец записи, стоящий непосредственно перед завершающим тэгом. Например: Текст

</P>

эквивалентно:

Текст</P>

Если не осуществляется разметка специального текста (например, текста с элементами PRE), в языке HTML последовательность из нескольких следующих друг за другом пробелов считается эквивалентной одному пробелу (в ASCII его десятичный код - 32). Подобные правила оставляют за авторами значительную свободу при внесении изменений в уже размеченный текст. Заметим, что в дальнейшие реализации языка HTML будет включена интерпретация для символа горизонтальной табуляции (в ASCII десятичный код 9), связанная с внесением в ассоциированную таблицу стиля некого правила для табуляций.

Объекты SGML, встречающиеся в контексте PCDATA или в атрибутах CDATA, должны адекватно расшифровываются анализатором языка. Например, é должно заменятся на символ из набора ISO Latin-1 с десятичным кодом 233 (прописная буква e со знаком акцента). Данный символ могло также представить в виде записи, содержащей его название, например é. Даже сам символ & можно включить в текст, воспользовавшись записью с его названием: &.

Спецификация HTML позволяет не ставить в кавычки атрибуты CDATA, если в них содержатся только буквы (от a до z и от A до Z), дефисы (в ASCII десятичный код 45) и точки (в ASCII десятичный код 46). В общем же случае значение атрибута может быть записано внутри двойных или одинарных кавычек (в ASCII их десятичные коды - 34 и 39 соответственно). Внутри атрибута, помещенного в двойные кавычки, можно ставить символы одинарных кавычек, и наоборот.

Заметим, что некоторые браузеры конечных пользователей требуют использования сокращенной записи для следующих атрибутов: COMPACT, ISMAP, CHECKED, NOWRAP, и NOHREF. Эти программы не воспринимают синтаксис типа COMPACT=COMPACT или ISMAP=ISMAP, хотя такая возможность и допускается в спецификации HTML 3.2 DTD.

Декларации SGML и DTD, используемые в спецификации HTML 3.2, даются в приложениях к данному документу. Остальные основополагающие принципы лексического анализа языка HTML даны в статье Дена Коннолли .

IMG - встроенные изображения

<!ENTITY % IAlign "(top|middle|bottom|left|right)"> <!ELEMENT IMG - O EMPTY -- Embedded image --> <!ATTLIST IMG src %URL #REQUIRED -- URL of image to embed -- alt CDATA #IMPLIED -- for display in place of image -- align %IAlign #IMPLIED -- vertical or horizontal alignment -- height %Pixels #IMPLIED -- suggested height in pixels -- width %Pixels #IMPLIED -- suggested width in pixels -- border %Pixels #IMPLIED -- suggested link border width -- hspace %Pixels #IMPLIED -- suggested horizontal gutter -- vspace %Pixels #IMPLIED -- suggested vertical gutter -- usemap %URL #IMPLIED -- use client-side image map -- ismap (ismap) #IMPLIED -- use server image map -- >

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

Элемент IMG не является контейнером, так что использовать здесь

закрывающий тэг не разрешается. Изображение может смещаться по вертикали относительно

текущей строки текста, либо ставиться с левого или правого края. См. описание атрибута

CLEAR в элементе BR, диктующего как тексту следует

"обтекать" подобные изображения.

например, <IMG SRC="canyon.gif" ALT="Большой Каньон">

Элементы IMG могут иметь следующие атрибуты:

src

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

Определяет URL-адрес того источника, откуда берется изображение, например это может

быть графический файл типа GIF, JPEG или PNG.

alt

Используется в качестве текстового описания к данному изображению и совершенно

необходим для взаимодействия с браузерами, ориентированными на речевой интерфейс либо

работающими исключительно в текстовом режиме.

align

Определяет, как будет позиционироваться данное изображение относительно строки

текста, в которую оно помещено:

align=top

Ставит на один уровень верхний край изображения и верхнюю границу текущей строки.

Разработчики браузеров расходятся в том, как интерпретировать этот атрибут. Некоторые

из браузеров принимают во внимание лишь строку текста, стоящую перед элементом IMG, и

игнорируют все, что стоит за ним.

align=middle

Ставит базовую линию текущей строки вровень с центром изображения.

align=bottom

Используется по умолчанию и выравнивает нижнюю часть изображения по базовой линии

текущей строки.

align=left

Ставит изображение с левого краю. При этом левый маркер разметки временно

смещается так, чтобы текст, следующий за изображением, "обтекал" его по правому краю.

Описанный здесь алгоритм компоновки изменяется в присутствии любого текста,

выровненного по левому краю, либо любой другой картинки, оказавшейся при разметке

прямо перед нашим изображением. При наличии такого текста (но не картинки)

изображения, подлежащие выравниванию по левому краю, как правило, переносятся на новую

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

Смещает картинку к правому краю страницы. Затем правый маркер разметки временно

передвигается так, чтобы текст, выводимый на экран вслед за картинкой, обтекал ее по

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

по правому краю текста или другой картинки, оказавшейся при разметке перед нашим

изображением. При наличии такого текста (но не картинки) изображение, подлежащее

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

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

Заметим, что некоторые браузеры начинают ставить фиктивные пробелы, если на

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

краю (либо, наоборот, по правому). Как следствие, авторы документов не должны

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

образом. См. в описании элемента как различными

способами управлять текстовым потоком.

width

Задает в пикселах ширину изображения. Если этот атрибут указан одновременно с

атрибутом height, то это дает возможность браузеру для очередного изображения заранее

зарезервировать место на экране, еще до того, как сама картинка будет доставлена ему

1по сети.

height

Задает в пикселах высоту изображения. Если этот атрибут указан одновременно с

атрибутом width, то это позволяет браузеру заранее резервировать место на экране для

очередного изображения, еще до того, как последнее будет доставлено по сети.

border

Если элемент IMG участвует в разметке как составная часть некой

гипертекстовой связи, то браузеры, как правило, будут отмечать это обстоятельство,

рисуя цветную рамку вокруг подобной картинки (обычно синего цвета). Атрибутом

border можно воспользоваться, желая выбрать определенную ширину для

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

border=0. Браузеры конечных пользователей должны иметь дополнительные

средства, напоминающие им, что над данным изображением можно щелкать клавишей мыши.

Например, это может быть изменение формы указателя мыши при попадании на подобное

изображение.

hspace

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

оставлять чистые поля. Ширину этих полей (в пикселах) как раз и задает атрибут

HSPACE. По умолчанию считается, что атрибут HSPACE имеет

малое, но все же ненулевое значение.

vspace

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

создавать чистые поля. Занчение атрибута VSPACE указывает ширину этих

полей (в пикселах). По умолчанию считается, что атрибут VSPACE имеет

малое, но все же ненулевое значение.

usemap

Может использоваться для того, чтобы сообщить браузеру URL-идентификатор фрагмента

навигационной карты, создаваемой элементом на компьютере

клиента.

ismap

Если элемент IMG является составной частью гипертекстовой связи и

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

ISMAP заставляет браузер передавать на сервер координаты точки, где был

произведен щелчок. Реализация данного механизма встречается с проблемами в случае

браузеров с чисто текстовым и речевым интерфейсом. Там, где это возможно, вместо ISMAP

используйте элемент MAP.

В следующем примере показано, как пользоваться атрибутом ISMAP:

<a href="/cgibin/navbar.map"><img src=navbar.gif ismap

border=0></a>

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

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

от старого URL, заданного в атрибуте HREF. Делает он это, добавляя в

конце символ "? ", координату X, запятую ", " и координату Y соответствующей точки

(единицей измерения служит пиксел). Затем осуществляется переход на созданый таким

образом адрес URL. Например, если пользователь щелкнул клавишей мыши по точке с

координатами x=10 и y=27, то будет создан следующий URL:

"/cgibin/navbar.map?10,27". Обычно удачным оказывается подход,

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

другие чисто графические элементы, показывающие, что по данному изображению можно

щелкать клавишей мыши.

Заметим, что что когда мы говорим о пикселах, мы имеем ввиду пикселы на экране

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

коэффициент при воспроизведении соответствующих изображений на устройствах с очень

высоким разрешением, например при распечатке на лазерных принтерах. Например, если

браузер пользователя имеет на дисплее монитора разрешение 75 пикселов на дюйм, то при

передаче этой информации на лазерный принтер с разрешением 600 точек на дюйм,

величины, указанные при разметке HTML-страниц в пикселах, должны умножаться на

коэффициент 8.

INPUT текстовые поля, радиокнопки, контрольные ящички, ...

Элементы INPUT не являются контейнерами, так что закрывающий тэг

использовать в этом случае не разрешается.

<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX | RADIO | SUBMIT | RESET | FILE | HIDDEN | IMAGE)"> <!ELEMENT INPUT - O EMPTY> <!ATTLIST INPUT type %InputType TEXT -- what kind of widget is needed -- name CDATA #IMPLIED -- required for all but submit and reset -- value CDATA #IMPLIED -- required for radio and checkboxes -- checked (checked) #IMPLIED -- for radio buttons and check boxes -- size CDATA #IMPLIED -- specific to each type of field -- maxlength NUMBER #IMPLIED src %URL #IMPLIED -- for fields with background images -- align (top|middle|bottom|left|right) top -- image alignment -- >

type

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

type=text (по умолчанию)

Создает поле ввода под одну строку текста, чей размер можно устанавливать

посредством атрибута (например атрибут

size=40 задает поле длиной, достаточной для прямого ввода 40-а символов).

При этом браузер должен предоставлять пользователю возможность ввести в подобное поле

строку текста, чей размер превышает указанный предел. На практике это должно

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

рамки видимого поля. Посредством атрибута

вы можете наложить уже настоящее ограничение на максимальное количество символов,

которое можно ввести в данное поле. Для присвоения некого имени данному полю может

использоваться атрибут , а атрибут

href="#value">value задает некую строку инициализации, которая при

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

type=password

В основном подобен атрибуту type=text, однако в данном случае вводимые символы

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

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

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

href="#isize">size и для

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

даном поле, и на фактическую длину вводимой строки текста:

<input type=password size=12 name=pw>

type=checkbox

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

типа ("да"/"нет"), либо для ввода некой величины, которая одновременно может

характеризоваться по нескольким позициям. Последний вариант реализуется в форме в виде

нескольких полей - контрольных ящичков, имеющих один и тот же атрибут
href="#name">name и различные атрибуты
href="#value">value. Каждый активированный в ходе заполнения

контрольный ящичек генерирует отдельную пару "название/значение" в соответствующем

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

некоторого ящичка в состояние "активированно" используйте атрибут
href="#checked">checked.

<input type=checkbox checked name=uscitizen value=yes>

type=radio

Используется для ввода в форму некого параметра, являющегося результатом

однозначного выбора из определенного набора альтернатив. Последним при разметке

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

один и тот же атрибут . В радиокнопках

обязательно следует указывать также и атрибут .

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

пару "название/значение" в соответствующем поле данных. В каждой группе радиокнопок

одна должна быть изначально активирована посредством атрибута
href="#checked">checked.

<input type=radio name=age value="0-12">

<input type=radio name=age value="13-17">

<input type=radio name=age value="18-25">

<input type=radio name=age value="26-35" checked>

<input type=radio name=age value="36-">

type=submit

Посредством этого типа создается кнопка, по которой пользователь может щелкнуть

клавишей мыши, желая предоставить содержимое формы на соответствующий сервер. Надпись

на кнопке задается с помощью атрибута . Если к

тому же задан атрибут , то в передаваемую на

сервер информацию дополнительно включается пара данных "название кнопки/значение". В

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

См. в пункте type=image как создавать графический вариант для подобных

кнопок.

<input type=submit value="Принадлежность к ...">

type=image

Данный атрибут используется при создании графического образа для кнопок,

инициирующих передачу данных. URL для соответствующего изображения задается

посредством атрибута . Выравнивание картинки

осуществляется согласно значению атрибута . В

этом отношении графические изображения кнопок подобны элементам
href="#img">IMG, так что вы можете точно так же осуществлять их

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

передаче данных серверу сообщаются координаты x и y той точки на изображении, где был

произведен щелчок клавишей мыши. При этом информация о поле типа image записывается в

виде двух пар значений "название/величина". "название" получается посредством

добавления к названию соответствующего поля image суффикса ".x" в случае абсциссы, и

".y" в случае ординаты:

<p>Теперь укажите точку на следующей карте:

<input type=image name=point src="map.gif">

Замечание: Воспроизведение графических полей обычно сопровождается

проблемами в случае с браузерами, работающими с текстовом режиме, и в случае

браузеров, имеющих речевой интерфейс!

type=reset

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

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

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

воспользовавшись атрибутом . Информация о

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

после заполнения формы.

<input type=reset value="Инициирует пере...">

type=file

Дает пользователям возможность дополнить содержимое текущей формы неким файлом.

При разметке этого элемента обычно создается поле для ввода текста, к которому

прилагается кнопка. Щелчок по этой кнопке приводит к раскрытию нового окошка, где

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

непосредственно в исходном текстовом поле. Точно так же, как и в случае type=text, вы

можете использовать здесь атрибут , чтобы выбрать

ширину данного поля формы (единицей измерения здесь служит средняя ширина символов).

Вы можете также установить верхний предел для длины вводимого имени файла посредством

атрибута . Некоторые браузеры имеют

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

списком в стиле MIME (через запятую), заданным в атрибуте ACCEPT.

Например, в случае accept="image/*", выбор файлов ограничен графическими

изображениями. Дополнительную информацию можно найти в .

<input type=file name=photo size=20 accept="image/*">

type=hidden

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

дает возможность размещать на серверах в рамках некой формы секретную информацию.

Когда заполненная форма предоставляется серверу, данная информация передается

посредством пары "название/величина", создаваемой соответствующими атрибутами. Данный

вопрос связан с безопасностью протокола HTTP. Другой подход к данной задаче связан с

использованием в рамках HTTP механизма "".

<input type=hidden name=customerid value="c2415-345-8563">

name

Используется при выборе названия для данного поля, которое впоследствии будет

использоваться для его идентифицикации во время передачи сведений на сервер.

value

Используется при инициализации данного поля, либо задает текстовый заголовок для

кнопок (передачи введенных данных на сервер, либо повторной инициализации формы).

checked

Данный атрибут первоначально используется для установки контрольных ящичков и

радиокнопок в состояние "активировано".

size

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

- средняя ширина символов. Например,

size=20

maxlength

Задает максимальное количество символов, которые можно ввести в текстовом поле.

src

Задает URL-адрес картинки, используемой при создании графической кнопки,

инициирующей передачу данных.

align

Указывает способ выравнивания для графических кнопок, инициирующих передачу

данных. Полностью аналогичен атрибуту align элемента
href="#img">IMG и может принимать одно из следующих значений:

top, middle, bottom, left или

right, по умолчанию считается, что этот атрибут имеет значение

bottom.

ISINDEX

<!ELEMENT ISINDEX - O EMPTY> <!ATTLIST ISINDEX prompt CDATA #IMPLIED -- текст сообщения -->

Элемент ISINDEX указывает на то, что браузер должен выделить отдельное текстовое поле для ручного ввода строки запроса. Не имеется никаких ограничений на количество символов, которые можно было бы ввести таким образом. Чтобы выбрать сообщение, изначально записываемое самим браузером в такое поле, можно воспользоваться атрибутом PROMPT, например <ISINDEX PROMPT="Искомая фраза">

Семантика элементов ISINDEX в настоящее время хорошо разработана только для тех случаев, когда базовый адрес для текущего документа - URL, построенный на протоколе HTTP. В таком случае, как правило, как только пользователь нажимает клавишу Enter, серверу посылается строка запроса, составной частью которой является базовый адрес URL текущего документа. Например, если в строку запроса введена фраза "десять зеленых яблок" и документ имеет базовый URL: http://www.acme.com/

то генерируемый запрос имеет вид: http://www.acme.com/?десять+зеленых+яблок"

Заметим, что при этом символы пробела отображаются в символы " + " и что в адресе URL используются стандартные символы-ограничители. Остальные подробности см. в спецификации .

Примечание На практике, конструируемая таким образом строка запроса ограничивается символами из набора Latin-1, поскольку в настоящее время не существует какого-либо механизма, позволяющего в URL указать, какой набор символов был использован для составления запроса.

Известные способы разделения HTML и бизнес-кода

Можно ли как-то изменить ситуацию со смешиванием ASP кода и HTML? Готовые решения, видимо, ждут нас в ASP+. Некоторые улучшения уже сейчас предлагает JSP, что не очень актуально для ASP.

Существуют, также, такие подходы как XML и CSS. XML, по своей идеологии, выглядит панацеей от проблемы смешивания информации и представления. Архитектор разрабатывает(если это необходимо) DTD-файл в самом начале проекта , XSL-файл отдает в разработку дизайнеру, а XML-файл генерирует программист. Время покажет, какие ловушки приготовил нам XML, но пока не очень многие организации позволяют себе полностью отказаться от HTML в пользу XML. Хотя когда-нибудь это произойдет.

Однако, в том же HTML есть возможность частично вынести дизайн в отдельный файл - при помощи CSS. Только это желательно делать в самом начале проекта. Энтузиазм может придать осознание той мысли, что все записи типа <font size=...> или <b> и т.д. придется потом самому же вручную переписывать на <span class=...>. Первоначальный CSS файл программист может придумать самостоятельно - без дизайнера. Вот некоторые рекомендации, которые могут облегчить применение CSS:

стили задаются командами <span class=... > и </span>. Не следует использовать <font class=...> - т.к. тогда тяжело будет отследить наличие нестилевого дизайна; другие записи, например <td class=...>, вполне допустимы ;

<b>,<i> - тоже должны быть заменены, хотя бы на <span class="bold"> и <span class="italic"> - это поможет дизайнеру;

не используйте имена цветов в названиях стилей. ( например, не надо писать class="while"). Если дизайн будет сильно меняться, это может оказаться другой цвет. Лучше используйте имена, отвечающие за позицию элемента на странице. Например class="body_text" - может означать обычный текст, а class="table_bold_link" - означать стиль ссылки в таблице, выделенную жирным цветом;

не перекрывайте форматирование CSS форматированием других тэгов (например <body text=... link=...>), которые вообще лучше оставить без атрибутов форматирования.

    CSS, без сомнения, может улучшить ситуацию. Но, во многом, дизайн все равно останется смешанным с кодом. Каким же образом разделить страницу на 2 части? Отдать дизайнеру-дизайнерово, а программисту - код? Поискав в интернете, можно встретить несколько вариантов решения этой задачи. Наиболее распространенные советы - это вырезать из ASP кусочки HTML и сохранить их в файлы, которые потом включить через SSI. Второй подход - это HTML шаблоны, в которых заранее заданная подстрока заменяется на конкретные данные.

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

    Другой подход - это применение HTML-шаблонов. Т.е. какая-то заранее заданная последовательность символов в обычной HTML странице заменяется на значение переменной. Например, пусть последовательность "[header]" заменяется на прочитанное из БД поле PAGE_HEADER, которое равно, к примеру, "Shop Information".

часть HTML-шаблона:	результат:
<h1>[header]</h1>	<h1>Shop Information</h1>

ASP-страница читает и обрабатывает нужный шаблон, а затем посылает результат клиенту одной командой Response.Write().

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

Элемент A (анкер)

<!ELEMENT A - - (%text)* -(A)>

<!ATTLIST A

name CDATA #IMPLIED -- named link end --

href %URL #IMPLIED -- URL for linked resource --

rel CDATA #IMPLIED -- forward link types --

rev CDATA #IMPLIED -- reverse link types --

title CDATA #IMPLIED -- advisory title string --

Анкеры нельзя вкладывать друг в друга, они должны всегда иметь начальный и конечный

тэги. Назначением этого элемента является создание гипертекстовых связей, а также

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

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

Путь к <a href="hands-on.html">счастью</a>.

<h2><a name=mit>545 Tech Square - Рай для

хакеров</a></h2>

name

Этот атрибут должен одной строкой уникальным образом характеризовать данное место

в текущем HTML-документе. Атрибут NAME используется для того, чтобы

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

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

область.

href

Задает некую URL-конструкцию, выступающую в роли сетевого адреса для ресурса,

соответствующего данному анкеру. Таким ресурсом может быть другой HTML документ, файл

PDF, картинка и т.д.

rel

Прямая ссылка, известная также как "тип связи". Может выступать в качестве

инструкции, как поступать с конкретным ассоциированным ресурсом при выдаче на печать

информационных ресурсов Сети, связанных с нашим документом посредством гипертекстовых

связей.

rev

Определяет обратную связь. Так связь документа A с документом B посредством анкета

с атрибутом REV=relation означает те же самое, что и связь B с A

посредством анкера с атрибутом REL=relation. Так в некоторых случаях для

идентификации автора документа используется атрибут REV=made (сообщающий

адрес его электронной почты посредством URL типа mailto, либо дающий ссылку на

домашную страницу этого человека).

title

Предоставляемое для справки название (title) ассоциированного ресурса.

Элемент BODY и его производные

Данный элемент содержит собственно тело (текст) документа. При этом и начальный и конечный тэги элемента BODY могут быть опущены. В теле документа может содержаться достаточно большой набор элементов:

Ключевые атрибуты данного элемента - BACKGROUND, BGCOLOR, TEXT, LINK, VLINK и ALINK - могут использоваться для того, чтобы задать повторяющееся фоновое изображение, дополнительный цвет фона и цвет, который будет использоваться при печати на экране обычного текста и гипертекстовых связей. <!ENTITY % body.content "(%heading | %text | %block | ADDRESS)*"> <!ENTITY % color "CDATA" -- a color specification: #HHHHHH @@ details? --> <!ENTITY % body-color-attrs " bgcolor %color #IMPLIED text %color #IMPLIED link %color #IMPLIED vlink %color #IMPLIED alink %color #IMPLIED "> <!ELEMENT BODY O O %body.content> <!ATTLIST BODY background %URL #IMPLIED -- texture tile for document background -- %body-color-attrs; -- bgcolor, text, link, vlink, alink -- >

Пример: <body bgcolor=white text=black link=red vlink=maroon alink=fuschia>

bgcolor

Определяет цвет фона для тела документа. См. ниже синтаксис для кодировки таких цветов.

text

Определяет цвет, используемый при выводе на экран текста из данного документа.

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

BGCOLOR или BACKGROUND.

link

Определяет цвет, который будет использоваться при выводе на экран текста из еще

не выбранных вами гипертекстовых связей.

vlink

Определяет цвет, который будет использоваться при выводе на экран текста из уже

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

alink

Задает цвет, которым будут выделяться в тексте гипертекстовые связки в тот момент,

когда пользователь щелкает по ним клавишей мыши.

background

Определяет адрес URL, откуда будет браться изображение для подготовки фона к

текущему документу.

В языке HTML цвета задаются по схеме

шестнадцатеричными числами (например как COLOR="#C0FFC0"), либо одним из

16 общепринятых названий для цвета. Первоначально эти цвета были выбраны в

соответствии со стандартными 16-ю цветами, которые использовала VGA палитра в системе

Windows.

Названия цветов и соответствующие значения RGB

	Black = "#000000"		Green = "#008000"
	Silver = "#C0C0C0"		Lime = "#00FF00"
	Gray = "#808080"		Olive = "#808000"
	White = "#FFFFFF"		Yellow = "#FFFF00"
	Maroon = "#800000"		Navy = "#000080"
	Red = "#FF0000"		Blue = "#0000FF"
	Purple = "#800080"		Teal = "#008080"
	Fuchsia = "#FF00FF"		Aqua = "#00FFFF"

Элемент HEAD и его производные

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

<!ENTITY % head.content "TITLE & ISINDEX? & BASE?"> <!ENTITY % head.misc "SCRIPT|STYLE|META|LINK"> <!ELEMENT HEAD O O (%head.content) +(%head.misc)>

Запись %head.misc используется для того, чтобы позволить соответствующим элементам многократно возникать в произвольных позициях в пределах элемента HEAD.

Итак, в состав заголовка документа могут входить следующие элементы:

определяет заголовок документа, необходим во всех случаях. используется при простом поиске по ключевому слову, см. атрибут PROMPT. определяет базовый адрес URL, используемый относительными ссылками (relative URLs). зарезервировано для использования в будущем в описательных языках. зарезервировано для использования в будущем таблицами стилей. используется для предоставления некой метаинформации (парные конструкции типа "название/значение"). используется для создания связей с другими документами.

Элементы TITLE, SCRIPT и STYLE являются контейнерами, а потому для них необходимо указывать как начальный, так и конечный тэги. Остальные элементы из приведенного списка не являются контейнерами, так что для них нельзя указывать закрывающий тэг. Заметим, что браузеры, подчиняющиеся требованиям спецификации, будут игнорировать содержимое элементов SCRIPT и STYLE.

Элементы на уровне блоков и текста

Большинство элементов, которые могут появляться в теле документа, подпадают под одну из двух категорий: элементы на уровне блоков, инициирующие переход к следующему параграфу, и элементы на уровне текста, которые этого не делают. Основные элементы на уровне блоков - заголовки (от H1 до H6), параграфы (P), элементы списков (LI), и горизонтальные линейки (HR). Основные элементы на уровне текста - элементы выделения (EM, I, B и FONT), связи для гипертекста (A), вложенные объекты (IMG и APPLET) и концы строк (BR). Заметим, что элементы на уровне блоков обычно выступают как контейнеры для материалов и элементов на уровне текста, а также для других элементов уровня блоков (исключение составляют заголовки и элементы адресации). В то же время внутри элементов текстового уровня могут содержаться лишь элементы того же уровня. Конкретная же модель разметки у каждого элемента своя.

Элементы разметки фраз

Для всех элементов данного класса необходимо указывать как начальный тэг, так и

конечный, например.

Это некий <EM>выделенный текст</EM>.

EM основной элемент, используемый в HTML для выделения текстов, обычно

реализуется с привлечением наклонного шрифта

STRONG усиленное выделение, обычно реализуемое посредством жирного шрифта

DFN дает пример для обсуждаемого термина (понятия)

CODE используется для выделения программного кода

SAMP используется при предоставлении в документе распечаток программ,

программных сценариев и т.д.

KBD используется для выделения текста, который пользователь должен набрать

на клавиатуре

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

с командами

CITE используется для обозначения цитат или ссылок на другие источники

Элементы текстового уровня

Размещение в документе элементов текстового уровня не вызывают перехода на

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

разметка текста, в общем случае могут быть вложенными. Они могут содержать другие

элементы текстового уровня, но не блочные элементы.

Элементы, задающие шрифт, используемый при разметке документа

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

тэг, например.

Это некий <B>жирный текст</B>.

Элементы текстового уровня, если в этом есть необходимость, должны быть вложены

правильным образом - следующий пример иллюстрирует ошибку:

Это некий <B>жирный и <I></B>наклонный текст</I>.

Браузеры должны стараться максимально точно следовать указаниям вложенных элементов

разметки, осуществляющих выделение, например.

Это некий <B>жирный и <I>наклонный текст</I></B>.

Набор шрифтов, оговариваемых в спецификации HTML, ограничивается разметкой речи,

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

TT телетайпный текст или текст фиксированной ширины

I стиль с наклонным шрифтом

B стиль с жирным шрифтом

U стиль с подчеркиванием текста

STRIKE стиль с перечеркиванием текста

BIG печать текста шрифтом увеличенного размера

SMALL печать текста шрифтом уменьшенного размера

SUB печать текста со сдвигом вниз (нижний индекс)

SUP печать текста со сдвигом вверх (верхний индекс)

Замечание: в будущих версиях языка HTML элемент STRIKE может быть заменен на

более краткий тэг "S", введенный в HTML версии 3.0.

JScript (JavaScript)

Одним из новаторских изобретений фирмы Netscape стал скриптовый язык JavaScript. Его синтаксис официально основывается на чрезвычайно популярном сейчас языке Java. А это, в свою очередь, говорит о схожести с C и C++. Особый интерес в JavaScript представляет оригинальная система динамического создания объектов, что позволят применять объектно-ориентированный подход. Несмотря на отсутствие инкапсуляции, странное наследование и неограниченный полиморфизм (проверки типов в JavaScript нет), применение объектов выводит программирование ASP-страниц на более высокий уровень, позволяя использовать стандартные паттерны проектирования, упрощая код и делает его более логичным, расширяемым и переносимым. Можно, например, создавать оболочки (которые еще называют адаптерами или врапперами) COM-объектов (того же ADODB), более удобные для применения, и абстрагирующие основной ASP-код от этого-самого COM-объекта (позволяя, при необходимости, легко заменить его на другой объект 2nd tier).

JScript является клоном языка JavaScript от Microsoft. Отличия JavaScript и JScript минимальны, однако их следует знать (отличия описаны в документации по JScript) и обходить (или абстрагировать), поскольку применение JScript в ASP открывает уникальную перспективу - возможность простого перевода Web-приложения, почти без переписывания основного кода, на технологию JSP (Java Server Pages). Это не означает, что мы собираемся бросать ASP и срочно переходить на JSP. Просто, в современных условиях, быть не привязанным к единственной платформе и/или технологии - очень ценное свойство проекта, которое, быть может, спасет его от гибели. Если грамотно абстрагировать ASP- и Windows-зависимый код в общие библиотеки, то, переписав только эти библиотеки, мы, теоретически, получим JSP-сайт. (JSP страницы могут быть написаны на JavaScript, а конструкции <%...%>, <%=...%> схожи и в ASP и в JSP). Это, однако, не относится к объектам 2nd tier, которые переводить придется отдельно.

Достоинством JavaScript можно считать его применение на стороне клиента (DHTML в Web-броузере), что позволяет создать "корпоративный стандарт". Т.е. программист-разработчик может применять единую технологию на стороне клиента и сервера (VBScript также можно использовать на стороне клиента, для броузера Internet Explorer, но это, обычно, не практикуется). Если разработки в компании ведутся на Java, С или С++, то JavaScript весьма гармонично впишется в рабочую среду. Недостатком конкретной реализации JScript можно считать отсутствие аналога VBScript-функции chrB(), что ограничивает возможность работы с однобайтовыми потоками данных. Что, с другой стороны, стимулирует вынесение сложного кода в объекты 2-nd tier.

International Organization for Standardization 1986

<!ENTITY nbsp CDATA " " -- no-break space --> <!ENTITY iexcl CDATA "¡" -- inverted exclamation mark --> <!ENTITY cent CDATA "¢" -- cent sign --> <!ENTITY pound CDATA "£" -- pound sterling sign --> <!ENTITY curren CDATA "¤" -- general currency sign --> <!ENTITY yen CDATA "¥" -- yen sign --> <!ENTITY brvbar CDATA "¦" -- broken (vertical) bar --> <!ENTITY sect CDATA "§" -- section sign --> <!ENTITY uml CDATA "¨" -- umlaut (dieresis) --> <!ENTITY copy CDATA "©" -- copyright sign --> <!ENTITY ordf CDATA "ª" -- ordinal indicator, feminine --> <!ENTITY laquo CDATA "«" -- angle quotation mark, left --> <!ENTITY not CDATA "¬" -- not sign --> <!ENTITY shy CDATA "" -- soft hyphen --> <!ENTITY reg CDATA "®" -- registered sign --> <!ENTITY macr CDATA "¯" -- macron --> <!ENTITY deg CDATA "°" -- degree sign --> <!ENTITY plusmn CDATA "±" -- plus-or-minus sign --> <!ENTITY sup2 CDATA "²" -- superscript two --> <!ENTITY sup3 CDATA "³" -- superscript three --> <!ENTITY acute CDATA "´" -- acute accent --> <!ENTITY micro CDATA "µ" -- micro sign --> <!ENTITY para CDATA "¶" -- pilcrow (paragraph sign) --> <!ENTITY middot CDATA "·" -- middle dot --> <!ENTITY ccedil CDATA "¸" -- small c, cedilla --> <!ENTITY sup1 CDATA "¹" -- superscript one --> <!ENTITY ordm CDATA "º" -- ordinal indicator, masculine --> <!ENTITY raquo CDATA "»" -- angle quotation mark, right --> <!ENTITY frac14 CDATA "¼" -- fraction one-quarter --> <!ENTITY frac12 CDATA "½" -- fraction one-half --> <!ENTITY frac34 CDATA "¾" -- fraction three-quarters --> <!ENTITY iquest CDATA "¿" -- inverted question mark --> <!ENTITY Agrave CDATA "À" -- capital A, grave accent --> <!ENTITY Aacute CDATA "Á" -- capital A, acute accent --> <!ENTITY Acirc CDATA "Â" -- capital A, circumflex accent --> <!ENTITY Atilde CDATA "Ã" -- capital A, tilde --> <!ENTITY Auml CDATA "Ä" -- capital A, dieresis or umlaut mark --> <!ENTITY Aring CDATA "Å" -- capital A, ring --> <!ENTITY AElig CDATA "Æ" -- capital AE diphthong (ligature) --> <!ENTITY Ccedil CDATA "Ç" -- capital C, cedilla --> <!ENTITY Egrave CDATA "È" -- capital E, grave accent --> <!ENTITY Eacute CDATA "É" -- capital E, acute accent --> <!ENTITY Ecirc CDATA "Ê" -- capital E, circumflex accent --> <!ENTITY Euml CDATA "Ë" -- capital E, dieresis or umlaut mark --> <!ENTITY Igrave CDATA "Ì" -- capital I, grave accent --> <!ENTITY Iacute CDATA "Í" -- capital I, acute accent --> <!ENTITY Icirc CDATA "Î" -- capital I, circumflex accent --> <!ENTITY Iuml CDATA "Ï" -- capital I, dieresis or umlaut mark --> <!ENTITY ETH CDATA "Ð" -- capital Eth, Icelandic --> <!ENTITY Ntilde CDATA "Ñ" -- capital N, tilde --> <!ENTITY Ograve CDATA "Ò" -- capital O, grave accent --> <!ENTITY Oacute CDATA "Ó" -- capital O, acute accent --> <!ENTITY Ocirc CDATA "Ô" -- capital O, circumflex accent --> <!ENTITY Otilde CDATA "Õ" -- capital O, tilde --> <!ENTITY Ouml CDATA "Ö" -- capital O, dieresis or umlaut mark --> <!ENTITY times CDATA "×" -- multiply sign --> <!ENTITY Oslash CDATA "Ø" -- capital O, slash --> <!ENTITY Ugrave CDATA "Ù" -- capital U, grave accent --> <!ENTITY Uacute CDATA "Ú" -- capital U, acute accent --> <!ENTITY Ucirc CDATA "Û" -- capital U, circumflex accent --> <!ENTITY Uuml CDATA "Ü" -- capital U, dieresis or umlaut mark --> <!ENTITY Yacute CDATA "Ý" -- capital Y, acute accent --> <!ENTITY THORN CDATA "Þ" -- capital THORN, Icelandic --> <!ENTITY szlig CDATA "ß" -- small sharp s, German (sz ligature) --> <!ENTITY agrave CDATA "à" -- small a, grave accent --> <!ENTITY aacute CDATA "á" -- small a, acute accent --> <!ENTITY acirc CDATA "â" -- small a, circumflex accent --> <!ENTITY atilde CDATA "ã" -- small a, tilde --> <!ENTITY auml CDATA "ä" -- small a, dieresis or umlaut mark --> <!ENTITY aring CDATA "å" -- small a, ring --> <!ENTITY aelig CDATA "æ" -- small ae diphthong (ligature) --> <!ENTITY ccedil CDATA "ç" -- small c, cedilla --> <!ENTITY egrave CDATA "è" -- small e, grave accent --> <!ENTITY eacute CDATA "é" -- small e, acute accent --> <!ENTITY ecirc CDATA "ê" -- small e, circumflex accent --> <!ENTITY euml CDATA "ë" -- small e, dieresis or umlaut mark --> <!ENTITY igrave CDATA "ì" -- small i, grave accent --> <!ENTITY iacute CDATA "í" -- small i, acute accent --> <!ENTITY icirc CDATA "î" -- small i, circumflex accent --> <!ENTITY iuml CDATA "ï" -- small i, dieresis or umlaut mark --> <!ENTITY eth CDATA "ð" -- small eth, Icelandic --> <!ENTITY ntilde CDATA "ñ" -- small n, tilde --> <!ENTITY ograve CDATA "ò" -- small o, grave accent --> <!ENTITY oacute CDATA "ó" -- small o, acute accent --> <!ENTITY ocirc CDATA "ô" -- small o, circumflex accent --> <!ENTITY otilde CDATA "õ" -- small o, tilde --> <!ENTITY ouml CDATA "ö" -- small o, dieresis or umlaut mark --> <!ENTITY divide CDATA "÷" -- divide sign --> <!ENTITY oslash CDATA "ø" -- small o, slash --> <!ENTITY ugrave CDATA "ù" -- small u, grave accent --> <!ENTITY uacute CDATA "ú" -- small u, acute accent --> <!ENTITY ucirc CDATA "û" -- small u, circumflex accent --> <!ENTITY uuml CDATA "ü" -- small u, dieresis or umlaut mark --> <!ENTITY yacute CDATA "ý" -- small y, acute accent --> <!ENTITY thorn CDATA "þ" -- small thorn, Icelandic --> <!ENTITY yuml CDATA "ÿ" -- small y, dieresis or umlaut mark -->

LINK

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

В принципе элементы LINK могут использоваться для:

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

<!ELEMENT LINK - O EMPTY> <!ATTLIST LINK href %URL #IMPLIED -- URL привязанного ресурса -- rel CDATA #IMPLIED -- типы прямых связей -- rev CDATA #IMPLIED -- типы обратных связей -- title CDATA #IMPLIED -- строка заголовка для справки -- >

href

Задает некий адрес URL, указывающий на ассоциированный ресурс. rel

Прямая связь, известная также как "тип связи". Вводит определенное взаимоотношение между текущим документом и ресурсом, на который указывает атрибут HREF . Типы связей в HTML пока еще нестандартизированы, хотя некоторые соглашения в этом плане и были достигнуты. rev

Данный элемент определяет обратные отношения. Например, если есть привязка документа A к документу B, выраженная параметром REV=отношение, то в документе B то же самое отношение фиксируется с помощью атрибута REL=отношение. Так в некоторых случаях может использоваться отношение REV=made для того, чтобы указать имя автора данного документа, адрес его электронной почты (посредством URL типа mailto), либо установить связь с личной страницей данного человека. title

Заголовок ассоциированного ресурса, указываемый для справки.

Некоторые из рекомендованых типов взаимосвязей:

rel=top

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

Данная связь указывает на некий файл, где приводится оглавление к данному документу. rel=index

Данная связь указывает на другой документ, который можно использовать в целях индексного поиска по текущему документу. rel=glossary

Данная связь указывает на некий документ, где содержится глоссарий терминов, относящихся к текущему документу. rel=copyright

Данная связь ссылается на текст, где указаны авторские права на данный документ. rel=next

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

Данная связь ссылается на предыдущий документ в неком предопределенном маршруте просмотра. rel=help

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

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

Примеры элементов LINK:

<LINK REL=Contents HREF=toc.html>

<LINK REL=Previous HREF=doc31.html>

<LINK REL=Next HREF=doc33.html>

<LINK REL=Chapter REV=Contents HREF=chapter2.html>

MAP - навигационные карты, обрабатываемые браузерами конечных клиентов

Элемент MAP реализует механизм обработки графических навигационных

карт самим браузером клиента. Элементы MAP могут находиться том же самом документе,

где производится разметка, либо группироваться в отдельном файле (хотя до сих пор

последнее еще не распространено достаточно широко). Для элемента MAP

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

или несколько элементов AREA, которые определяют на карте контрольные

зоны и связывают их с определенными URL-адресами. <!ENTITY % SHAPE "(rect|circle|poly)"> <!ENTITY % COORDS "CDATA" -- comma separated list of numbers --> <!ELEMENT MAP - - (AREA)+> <!ATTLIST MAP name CDATA #REQUIRED > <!ELEMENT AREA - O EMPTY> <!ATTLIST AREA shape %SHAPE rect coords %COORDS #IMPLIED -- defines coordinates for shape -- href %URL #IMPLIED -- this region acts as hypertext link -- nohref (nohref) #IMPLIED -- this region has no action -- alt CDATA #REQUIRED -- needed for non-graphical user agents -- >

Простой пример использования графической навигационной карты типа "панель

инструментов":

</map>

Элемент MAP имеет единственный атрибут NAME, который дает

карте некое название. Впоследствии это название указывается в элементе

IMG с составе атрибута USEMAP с тем, чтобы сослаться на

данную навигационную карту через URL-идентификатор фрагмента. Заметим, что для слова,

указываемого в атрибуте NAME, строчные и прописные буквы отличаются друг

от друга.

Элемент AREA является пустым элементом, и потому для него нельзя

указывать закрывающий тэг. Может иметь следующие атрибуты: SHAPE,

COORDS, HREF, NOHREF и ALT.

Атрибуты SHAPE и COORDS создают на изображении карты

контрольную зону. Если атрибут SHAPE не был указан при разметке, то по

умолчанию предполагается, что задано SHAPE="RECT".

shape=rect coords="левое-x, верхнее-y,

правое-x, нижнее-y"

shape=circle coords="центральное-x,

центральное-y, радиус"

shape=poly

coords="x1,y1,

x2,y2,

x3,y3, ..."

где координаты x и y даны в пикселах и отсчитываются от левого

верхнего угла соответствующего изображения. Если в x и y после числа

следует символ процента, то указанную величину следует интерпретировать как процент от

ширины изображения (или, соответственно, от высоты). Например:

SHAPE=RECT COORDS="0, 0, 50%, 100%"

Атрибут HREF сообщает URL-адрес точки, куда будет направлен читатель

при выборе данной контрольной зоны. Если вы хотите на карте указать некую область,

которая при этом не выполняла бы функции контрольной зоны, используйте атрибут

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

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

Если происходит перекрытие двух или более зон, то та из них, которая при разметке

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

определенными позднее. Это означает, что элементы AREA с атрибутом

NOHREF должны, как правило, ставиться перед элементами с атрибутом

HREF.

Атрибут ALT используется при выборе текстовых комментариев, которые

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

координационного устройства в контрольную зону навигационной карты. Комментарии также

используются при создании текстового меню в случае, когда браузер клиента работает не

в графическом режиме. Авторам Web-документов настоятельно рекомендуется

сопровождать навигационные карты четкими ALT-комментариями в целях

сохранения совместимости с браузерами, имеющими речевой интерфейс, либо работающими в

текстовом режиме.

Материалы для дальнейшего чтения...

The World Wide Web Consortium

Дополнительную информацию о деятельности организации W3C и о состоянии работ над

совершенствованием протоколов HTML, HTTP, а также другие материалы можно найти по

адресу в . Сведения о языке HTML

можно также получить по адресу

href="http://www.w3.org/pub/WWW/MarkUp/">http://www.w3.org/pub/WWW/MarkUp/.

HTML 2.0 (RFC1866)

Авторы Tim Berners-Lee и Dan Connolly, ноябрь 1995 года Дает спецификацию для языка

разметки гипертекста версии 2.0. Доступен по адресу

href="ftp://ds.internic.net/rfc/rfc1866.txt">ftp://ds.internic.net/rfc/rfc1866.txt

Form-based File Upload in HTML (RFC1867) Авторы E. Nebel и L. Masinter,

ноябрь 1995 года. Описывает расширения к языку HTML 2.0 (RFC1866), реализующие

подкачку файлов из форм HTML. Доступен по адресу

href="ftp://ds.internic.net/rfc/rfc1867.txt">ftp://ds.internic.net/rfc/rfc1867.txt

HTML Tables (RFC1942)

Автор Dave Raggett, май 1996 года. Описывает модель таблиц, используемую в языке HTML.

Является расширением для модели построения таблиц , заданной в спецификации HTML 3.2.

Доступен по адресу

href="ftp://ds.internic.net/rfc/rfc1942.txt">ftp://ds.internic.net/rfc/rfc1942.txt

, либо в качестве рабочего документа W3C по адресу

href="http://www.w3.org/pub/WWW/TR/WD-tables">http://www.w3.org/pub/WWW/TR/WD-

tables.

A Lexical Analyzer for HTML and Basic SGML

Автор Dan Connolly, июнь 1996 года. Рассматривает лексические основы анализа HTML

документов. Доступен по адресу

The Hypertext Transfer Protocol (HTTP)

Дополнительную информацию о протоколе HTTP можно найти по адресу:

href="http://www.w3.org/pub/WWW/Protocols">http://www.w3.org/pub/WWW/Protocols.

A Standard Default Color Space for the Internet - sRGB

Авторы Michael Stokes, Mathew Anderson, Srinivasan Chandrasekar и Ricardo Motta,

ноябрь 1996 года. Доступен по адресу:

href="http://www.w3.org/pub/WWW/Graphics/Color/sRGB.html">http://www.w3.org/pub/WWW/Gr

aphics/Color/sRGB.html.

Дается четкое определение модели RGB, позволяющее осуществлять точное воспроизведение

RGB изображений на различных компьютерных платформах и при различных условиях

освещенности.

Меню SELECT

<!ELEMENT SELECT - - (OPTION+)>

<!ATTLIST SELECT

name CDATA #REQUIRED

size NUMBER #IMPLIED

multiple (multiple) #IMPLIED

<!ELEMENT OPTION - O (#PCDATA)*>

<!ATTLIST OPTION

selected (selected) #IMPLIED

value CDATA #IMPLIED -- defaults to element content --

Элемент SELECT создает в заполняемой форме меню типа "выбор одного

пункта из многих", либо "несколько пунктов из многих". Элемент SELECT

должен содержать начальный и конечный тэги, а также один или несколько элементов

OPTION, описывающих отдельные пункты меню. Меню типа "один из многих"

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

обычно предстает в виде списка с контрольными ящичками против каждого пункта.

Пример:

<OPTION VALUE=a>Ваниль

<OPTION VALUE=b>Клубника

<OPTION VALUE=c>Ром and Изюм

<OPTION VALUE=d>Персик and Апельсин

</SELECT>

Атрибуты элемента SELECT:

name

Сообщает название для данного качества, которое затем будет использоваться во

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

Каждый выбранный пункт меню ассоциируется с парой значений "название/величина",

которая заносится в заполняемую форму.

size

В меню типа "несколько из многих" устанавливает количество одновременно видимых

пунктов.

multiple

Наличие этого атрибута говорит о том, что в данном меню пользователи могут сразу

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

один пункт.

Атрибуты элемента OPTION:

selected

Если для элемента OPTION указан атрибут selected, то соответствующий этому

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

Однако если в меню типа "один из нескольких" изначально таким образом помечено более

одного пункта, то это будет ошибкой.

value

Задает некое значение, которое соответствует данному пункту меню и впоследствии

может быть представлено наряду с другими сведениями о содержимом заполненной формы. В

последнем случае это значение будет объединено с названием соответствующего свойства,

указанным ранее в элементе SELECT посредством атрибута name.

Неупорядоченные списки

<!ELEMENT UL - - (LI)+> <!ENTITY % ULStyle "disc|square|circle"> <!ATTLIST UL -- unordered lists -- type (%ULStyle) #IMPLIED -- bullet style -- compact (compact) #IMPLIED -- reduced interitem spacing -- > <!ELEMENT LI - O %flow -- list item --> <!ATTLIST LI type (%LIStyle) #IMPLIED -- list item style -- >

Неупорядоченные списки имеют вид: <UL> <LI> ... первый пункт списка

<LI> ... второй пункт списка

... </UL>

Итак, элемент UL используется для создания неупорядоченных списков.

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

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

тэг для элемента LI может быть всегда опущен. Заметим, что элементы

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

пользователя печатать списки в более компактном стиле, может дополнительно

использоваться атрибут COMPACT.

В элементах UL и LI может использоваться атрибут

TYPE, устанавливающий стиль разметки для данного списка. Допустимые

значения атрибута - "disc", "square" и "circle". Стиль разметки в общем случае зависит

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

элементу в списке:

в случае <li type=disc>

в случае <li type=square>

в случае <li type=circle>

При выборе такого списка ставилась цель обеспечить совместимость с разметкой,

которая изначально использовалась в 1993 году программой Mosaic.

Независимость ASP кода от источника данных, снятие нагрузки с IIS, упрощение ASP кода...

Мы уже рассмотрели, как вынести HTML в отдельный файл и отдать его дизайнеру. Но остался еще один кандидат на то, чтобы убрать его из ASP. Это - SQL. Он усложняет ASP-код, жестко связывает его с конкретным сервером базы данных, загружает IIS излишними вычислениями, снижает возможность масштабирования. Проще говоря - он превращает 3-х уровневое приложение в 2-х уровневое (клиент-сервер).

Рассмотрим архитектуру 3-х уровневого web-приложения, применительно к IIS, ASP и COM

Где на данной схеме расположить ASP c ADODB? Поскольку используется прямая запись SQL и однозначное обращение к конкретной базе данных, то можно утверждать, что ASP обращается непосредственно к 3rd tier, а ADODB является сервисом доступа к данным, и принадлежит 3rd tier. В 3-х уровневой архитектуре прямая связь 1st tier c 3rd tier недопустима. Говоря об SQL, можно утверждать, что он однозначно связывает код с выбранным типом сервера базы данных (будь то Oracle, MSSQL или что либо еще). То, что можно писать только на ANSI SQL, который будет работать везде, скорее всего миф. В любом случае это очень сложно реализовать.

Посмотрим, что можно предложить.

Общая объектно-ориентированная библиотека: Project ASP API

Для упрощения использования любой новой технологии (и для описанных выше конвертаций ASP проекта в проект JSP/PHP) жизненно необходимо абстрагировать системные средства ASP в библиотеку общего пользования. Эту библиотеку можно специально приспособить под конкретный проект, для значительного упрощения ее применения. Рассмотрим типичных кандидатов на помещение в общую, объектно-ориентированную, библиотеку.

Config - это объект, который хранит все настройки, общие для сайта в целом. Реально, они будут записываться при старте сайта в ASP коллекцию Application(), например из конфигурационного XML или INI-файла или просто из global.asa. Но весь остальной ASP-код работает с конфигурационными параметрами исключительно через этот объект и к способу хранения/чтения этих параметров никак не привязан. Параметры конфигурации могут быть представлены, в объекте Config, как атрибуты объекта и/или как методы getStr("Section","Entry","Default"), getInt(...), getBool(...), и т.д.

ConfigUser - этот объект хранит переменные текущей сессии пользователя. Абстрагируя переменные сессии в этот объект, мы получаем независимость от способа хранения переменных сессии. Мы можем как угодно менять и комбинировать способы хранения этих переменных: коллекция Session(), Cookies, Database, поля HTML формы - что угодно. При этом основной код будет оставаться неизменным. Доступ к переменным можно организовать аналогично объекту Config, но уже с возможностью модификации этих переменных - getStr(...)/setStr(...), и т.д.

    Тут возникает весьма неоднозначный вопрос - об именовании объектов. Как в ASP, так и в сервлетах/JSP общую конфигурацию рекомендуется записывать в коллекцию Application (application), а пользовательскую - в Session (session). Проблема в том, что концепции коллекций Application и Session подразумевают то, что туда можно записать все, что угодно и время жизни этих коллекций ограничено. Они универсальны, и не приспособлены специально для хранения конфигураций.

    Поэтому назвать наши конфигурационные объекты надо как-то по-другому (не application и session). Например: ConfigApp/ConfigUser, AppProperties/UserProperties, GlobalProperties/SessionProperties и т.п. Еще один фактор - это сокращения в названиях. Это не очень хороший стиль, поскольку многие сокращения могут оказаться непрозрачны для некоторых разработчиков.

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

    ObjectFactory - если задуматься о будущем, то запись Server.CreateObject(...) в основном ASP коде покажется весьма ограничивающим фактором. Если понадобится использовать J2EE CAS COM Bridge (мост от Sun для использования EJB и обычных Java-классов через COM), то процесс создание объекта уже будет отличатся, и запишется так (JScript):

_factory = Server.CreateObject("J2EECAS.JavaClassLoaderFactory");

_classloader = _factory.CreateClassLoader();

_class = _classloader.FindClass("java.lang.String");

objJavaStr = _class.New();

И основной ASP код придется переписывать. Для мостов CORBA придется использовать другую запись. Нет, конечно, может быть не все так плохо, и возможно для данного конкретного проекта никогда не понадобится связь ни с EJB, ни с CORBA, ни что-нибудь еще (пострашнее :) ). Но кто знает...

    Если вы все же решились абстрагировать и эту сторону проектной реальности, то ObjectFactory, минимально должен предоставлять 2 метода - создание и удаление объекта. Не важно что обычно удалением объектов занимался сборщик мусора. Пусть даже наш метод удаления объекта на самом деле ничего не делает - это не важно. Пусть он будет, и пусть он вызывается когда нужно - будущее нас рассудит.

    У каждого объекта 2-nd tier должен быть псевдоним для его идентификации при обращении к ObjectFactory. Например в основном коде будет запись ObjectFactory.CreateObject("MailSender"); И только ObjectFactory на самом деле будт знать что это COM объект с AppId "com.sa.soft.utils.SendMail005".

    Параллельно ObjectFactory можно нагрузить мелкими функциями - контролем всяческих пулов и кэшей, проверкой валидности объекта, etc.

    И, чтобы уж совсем по-модному, доступ к вышеописанным объектам должен осуществляться через единственный объект-ядро:

    Core - этот объект должен присутствовать во всех ASP страницах основного кода в единственном экземпляре (синглетонами также должны быть объекты Config, ConfigUser и ObjectFactory. а вот DB-объекты - необязательно). Главная задача объекта Core - создавать и возвращать все описанные выше объекты написанной вами библиотеки, гордо именуемой Project ASP API.

    Например, Core.getConfigApp() создаст объект ConfigApp и вернет на него ссылку. Повторный вызов не будет создавать объект повторно, а вернет ту же ссылку (чтобы гарантировать, что ConfigApp останется синглетоном). Помимо того, что основной ASP-код станет более понятным, мы получим весьма полезный эффект. Core может запоминать ссылки на все созданные им объекты. И вызвав в конце ASP-страницы метод, например, Core.close(), мы получим гарантированное

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

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

Общие сравнительные характеристики:

ASP Script:	VBScript	JScript	PerlScript
Объктно-ориентированное программирование	Нет	Да	Да
2nd tier на COM	Да	Да	Да
2nd tier на CORBA	Только через мосты	Только через мосты	Да
2nd tier на EJB	Только через мосты	Только через мосты	Только через мосты
Схожие языки (для формирование корпоративного стандарта)	MS Visual Basic, any Basic	JavaScript, Java, C, C++	Perl, PHP
Проект может мигрировать на другую Web-технологию	Нет	Да, на JSP	Да, на PHP или Perl CGI/ISAPI
Проект может мигрировать на другую платформу	Нет	Да, JSP на любой JSP-совместимой платформе	Да, PHP/Perl на любой PHP/Perl-совместимой платформе

Критериями выбора скрипта разработки для ASP могут стать:

возможности этого скрипта, как языка программирования

корпоративные стандарты компании

возможности простой миграции проекта на конкурирующие технологии

простота поддержки

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

W3C Document Type Definition for

<!ENTITY % HTML.Version "-//W3C//DTD HTML 3.2 Final//EN"

-- Typical usage:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <html> ... </html> -- >



<!ENTITY % HTML.Deprecated "INCLUDE">



<!ENTITY % Content-Type "CDATA" -- meaning a MIME content type, as per RFC1521 -->

<!ENTITY % HTTP-Method "GET | POST" -- as per HTTP specification -->

<!ENTITY % URL "CDATA" -- The term URL means a CDATA attribute whose value is a Uniform Resource Locator, See RFC1808 (June 95) and RFC1738 (Dec 94). -->



<!ENTITY % head.misc "SCRIPT|STYLE|META|LINK" -- repeatable head elements -->

<!ENTITY % heading "H1|H2|H3|H4|H5|H6">

<!ENTITY % list "UL | OL | DIR | MENU">

<![ %HTML.Deprecated [ <!ENTITY % preformatted "PRE | XMP | LISTING"> ]]>

<!ENTITY % preformatted "PRE">



<!ENTITY % ISOlat1 PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML"> %ISOlat1;

  <!ENTITY gt CDATA ">" -- greater than --> <!ENTITY lt CDATA "<" -- less than -->



<!ENTITY % font "TT | I | B | U | STRIKE | BIG | SMALL | SUB | SUP">

<!ENTITY % phrase "EM | STRONG | DFN | CODE | SAMP | KBD | VAR | CITE">

<!ENTITY % special "A | IMG | APPLET | FONT | BASEFONT | BR | SCRIPT | MAP">

<!ENTITY % form "INPUT | SELECT | TEXTAREA">

<!ENTITY % text "#PCDATA | %font | %phrase | %special | %form">

<!ELEMENT (%font|%phrase) - - (%text)*>



<!ELEMENT FONT - - (%text)* -- local change to font --> <!ATTLIST FONT size CDATA #IMPLIED -- [+]nn e.g. size="+1", size=4 -- color CDATA #IMPLIED -- #RRGGBB in hex, e.g. red: color="#FF0000" -- >

<!ELEMENT BASEFONT - O EMPTY -- base font size (1 to 7)--> <!ATTLIST BASEFONT size CDATA #IMPLIED -- e.g. size=3 -- >

<!ELEMENT BR - O EMPTY -- forced line break --> <!ATTLIST BR clear (left|all|right|none) none -- control of text flow -- >

 

<!ENTITY % block "P | %list | %preformatted | DL | DIV | CENTER | BLOCKQUOTE | FORM | ISINDEX | HR | TABLE">



<!ENTITY % flow "(%text | %block)*">



<!ENTITY % body.content "(%heading | %text | %block | ADDRESS)*">

<!ENTITY % color "CDATA" -- a color specification: #HHHHHH @@ details? -->

<!ENTITY % body-color-attrs " bgcolor %color #IMPLIED text %color #IMPLIED link %color #IMPLIED vlink %color #IMPLIED alink %color #IMPLIED ">

<!ELEMENT BODY O O %body.content> <!ATTLIST BODY background %URL #IMPLIED -- texture tile for document background -- %body-color-attrs; -- bgcolor, text, link, vlink, alink -- >

<!ENTITY % address.content "((%text;) | P)*">

<!ELEMENT ADDRESS - - %address.content>

<!ELEMENT DIV - - %body.content> <!ATTLIST DIV align (left|center|right) #IMPLIED -- alignment of following text -- >

 <!ELEMENT center - - %body.content>



<!ELEMENT A - - (%text)* -(A)> <!ATTLIST A name CDATA #IMPLIED -- named link end -- href %URL #IMPLIED -- URL for linked resource -- rel CDATA #IMPLIED -- forward link types -- rev CDATA #IMPLIED -- reverse link types -- title CDATA #IMPLIED -- advisory title string -- >





<!ENTITY % SHAPE "(rect|circle|poly)"> <!ENTITY % COORDS "CDATA" -- comma separated list of numbers -->

<!ELEMENT MAP - - (AREA)*> <!ATTLIST MAP name CDATA #IMPLIED >

<!ELEMENT AREA - O EMPTY> <!ATTLIST AREA shape %SHAPE rect coords %COORDS #IMPLIED -- defines coordinates for shape -- href %URL #IMPLIED -- this region acts as hypertext link -- nohref (nohref) #IMPLIED -- this region has no action -- alt CDATA #REQUIRED -- needed for non-graphical user agents -- >



<!ENTITY % Types "CDATA" -- See Internet Draft: draft-ietf-html-relrev-00. txt LINK has been part of HTML since the early days although few browsers as yet take advantage of it.

Relationship values can be used in principle:

a) for document specific toolbars/menus when used with the LINK element in the document head: b) to link to a separate style sheet c) to make a link to a script d) by stylesheets to control how collections of html nodes are rendered into printed documents e) to make a link to a printable version of this document e.g. a postscript or pdf version -->

<!ELEMENT LINK - O EMPTY> <!ATTLIST LINK href %URL #IMPLIED -- URL for linked resource -- rel %Types #IMPLIED -- forward link types -- rev %Types #IMPLIED -- reverse link types -- title CDATA #IMPLIED -- advisory title string -- >



<!ENTITY % Length "CDATA" -- nn for pixels or nn% for percentage length --> <!ENTITY % Pixels "NUMBER" -- integer representing length in pixels -->



<!ENTITY % IAlign "(top|middle|bottom|left|right)">

<!ELEMENT IMG - O EMPTY -- Embedded image --> <!ATTLIST IMG src %URL #REQUIRED -- URL of image to embed -- alt CDATA #IMPLIED -- for display in place of image -- align %IAlign #IMPLIED -- vertical or horizontal alignment -- height %Pixels #IMPLIED -- suggested height in pixels -- width %Pixels #IMPLIED -- suggested width in pixels -- border %Pixels #IMPLIED -- suggested link border width -- hspace %Pixels #IMPLIED -- suggested horizontal gutter -- vspace %Pixels #IMPLIED -- suggested vertical gutter -- usemap %URL #IMPLIED -- use client-side image map -- ismap (ismap) #IMPLIED -- use server image map -- >



  <!ELEMENT APPLET - - (PARAM | %text)*> <!ATTLIST APPLET codebase %URL #IMPLIED -- code base -- code CDATA #REQUIRED -- class file -- alt CDATA #IMPLIED -- for display in place of applet -- name CDATA #IMPLIED -- applet name -- width %Pixels #REQUIRED -- suggested width in pixels -- height %Pixels #REQUIRED -- suggested height in pixels -- align %IAlign #IMPLIED -- vertical or horizontal alignment -- hspace %Pixels #IMPLIED -- suggested horizontal gutter -- vspace %Pixels #IMPLIED -- suggested vertical gutter -- >

<!ELEMENT PARAM - O EMPTY> <!ATTLIST PARAM name NMTOKEN #REQUIRED -- The name of the parameter -- value CDATA #IMPLIED -- The value of the parameter -- >





<!ELEMENT HR - O EMPTY> <!ATTLIST HR align (left|right|center) #IMPLIED () #IMPLIED size %Pixels #IMPLIED width %Length #IMPLIED > 

<!ELEMENT P - O (%text)*> <!ATTLIST P align (left|center|right) #IMPLIED >





<!ELEMENT ( %heading ) - - (%text;)*> <!ATTLIST ( %heading ) align (left|center|right) #IMPLIED >





<!ENTITY % pre.exclusion "IMG|BIG|SMALL|SUB|SUP|FONT">

<!ELEMENT PRE - - (%text)* -(%pre.exclusion)> <!ATTLIST PRE width NUMBER #implied -- is this widely supported? -- >

<![ %HTML.Deprecated [

<!ENTITY % literal "CDATA" -- historical, non-conforming parsing mode where the only markup signal is the end tag in full -->

<!ELEMENT (XMP|LISTING) - - %literal> <!ELEMENT PLAINTEXT - O %literal>

]]>



<!ELEMENT BLOCKQUOTE - - %body.content>







<!ELEMENT DL - - (DT|DD)+> <!ATTLIST DL compact (compact) #IMPLIED -- more compact style -- >

<!ELEMENT DT - O (%text)*> <!ELEMENT DD - O %flow;>

 <!ELEMENT (OL|UL) - - (LI)+>



<!ENTITY % OLStyle "CDATA" -- constrained to: [1|a|A|i|I] --> <!ATTLIST OL -- ordered lists -- type %OLStyle #IMPLIED -- numbering style -- start NUMBER #IMPLIED -- starting sequence number -- compact (compact) #IMPLIED -- reduced interitem spacing -- >



<!ENTITY % ULStyle "disc|square|circle">

<!ATTLIST UL -- unordered lists -- type (%ULStyle) #IMPLIED -- bullet style -- compact (compact) #IMPLIED -- reduced interitem spacing -- >

<!ELEMENT (DIR|MENU) - - (LI)+ -(%block)> <!ATTLIST DIR compact (compact) #IMPLIED > <!ATTLIST MENU compact (compact) #IMPLIED >

   



<!ENTITY % LIStyle "CDATA" -- constrained to: "(%ULStyle|%OLStyle)" -->

<!ELEMENT LI - O %flow -- list item --> <!ATTLIST LI type %LIStyle #IMPLIED -- list item style -- value NUMBER #IMPLIED -- reset sequence number -- >



<!ELEMENT FORM - - %body.content -(FORM)> <!ATTLIST FORM action %URL #IMPLIED -- server-side form handler -- method (%HTTP-Method) GET -- see HTTP specification -- enctype %Content-Type; "application/x-www-form-urlencoded" >

<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX | RADIO | SUBMIT | RESET | FILE | HIDDEN | IMAGE)">

<!ELEMENT INPUT - O EMPTY> <!ATTLIST INPUT type %InputType TEXT -- what kind of widget is needed -- name CDATA #IMPLIED -- required for all but submit and reset -- value CDATA #IMPLIED -- required for radio and checkboxes -- checked (checked) #IMPLIED -- for radio buttons and check boxes -- size CDATA #IMPLIED -- specific to each type of field -- maxlength NUMBER #IMPLIED src %URL #IMPLIED -- for fields with background images -- align (top|middle|bottom|left|right) top -- image alignment -- >

<!ELEMENT SELECT - - (OPTION+)> <!ATTLIST SELECT name CDATA #REQUIRED size NUMBER #IMPLIED multiple (multiple) #IMPLIED >

<!ELEMENT OPTION - O (#PCDATA)*> <!ATTLIST OPTION selected (selected) #IMPLIED value CDATA #IMPLIED -- defaults to element content -- >



<!ELEMENT TEXTAREA - - (#PCDATA)*> <!ATTLIST TEXTAREA name CDATA #REQUIRED rows NUMBER #REQUIRED cols NUMBER #REQUIRED >





 <!ENTITY % Where "(left|center|right)">

 <!ENTITY % cell.halign "align (left|center|right) #IMPLIED" >

 <!ENTITY % cell.valign "valign (top|middle|bottom) #IMPLIED" >

<!ELEMENT table - - (caption?, tr+)> <!ELEMENT tr - O (th|td)*> <!ELEMENT (th|td) - O %body.content>

<!ATTLIST table -- table element -- align %Where; #IMPLIED -- table position relative to window -- width %Length #IMPLIED -- table width relative to window -- border %Pixels #IMPLIED -- controls frame width around table -- cellspacing %Pixels #IMPLIED -- spacing between cells -- cellpadding %Pixels #IMPLIED -- spacing within cells -- >

<!ELEMENT CAPTION - - (%text;)* -- table or figure caption --> <!ATTLIST CAPTION align (top|bottom) #IMPLIED >

<!ATTLIST tr -- table row -- %cell.halign; -- horizontal alignment in cells -- %cell.valign; -- vertical alignment in cells -- >

<!ATTLIST (th|td) -- header or data cell -- nowrap (nowrap) #IMPLIED -- suppress word wrap -- rowspan NUMBER 1 -- number of rows spanned by cell -- colspan NUMBER 1 -- number of cols spanned by cell -- %cell.halign; -- horizontal alignment in cell -- %cell.valign; -- vertical alignment in cell -- width %Pixels #IMPLIED -- suggested width for cell -- height %Pixels #IMPLIED -- suggested height for cell -- >





<!ENTITY % head.content "TITLE & ISINDEX? & BASE?">

<!ELEMENT HEAD O O (%head.content) +(%head.misc)>

<!ELEMENT TITLE - - (#PCDATA)* -(%head.misc) -- The TITLE element is not considered part of the flow of text. It should be displayed, for example as the page header or window title. -->

<!ELEMENT ISINDEX - O EMPTY> <!ATTLIST ISINDEX prompt CDATA #IMPLIED -- prompt message -->



<!ELEMENT BASE - O EMPTY> <!ATTLIST BASE href %URL #REQUIRED >

<!ELEMENT META - O EMPTY -- Generic Metainformation --> <!ATTLIST META http-equiv NAME #IMPLIED -- HTTP response header name -- name NAME #IMPLIED -- metainformation name -- content CDATA #REQUIRED -- associated information -- >



<!ELEMENT STYLE - - (#PCDATA)* -(%head.misc) -- style info --> <!ELEMENT SCRIPT - - (#PCDATA)* -(%head.misc) -- script statements -->



<!ENTITY % version.attr "VERSION CDATA #FIXED '%HTML.Version;'">

<![ %HTML.Deprecated [ <!ENTITY % html.content "HEAD, BODY, PLAINTEXT?"> ]]>

<!ENTITY % html.content "HEAD, BODY">

<!ELEMENT HTML O O (%html.content)> <!ATTLIST HTML %version.attr; >

Параграфы

<!ELEMENT P - O (%text)*> <!ATTLIST P align (left|center|right) #IMPLIED >

Элемент P используется для разметки параграфов. Он является

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

указывать необязательно, поскольку он всегда может быть поставлен в нужное место самой

программой просмотра гипертекста. Если где-либо в документе стоит элемент

P, то браузер должен в этом месте завершить текущий абзац и/или,

соответственно, инициировать новый. При этом алгоритм разметки оставляется на

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

друг от друга полосой свободного пространства.

Пример:

<P>Первый параграф.

<P>Второй параграф.

Обычно параграфы выравниваются по левому краю листа. Указать же другой тип

горизонтального выравнивания можно с помощью атрибута ALIGN:

align=leftПараграф, выровненный по левому краю.

align=centerЦентрированный параграф.

Параграф, выровненный по правому краю.

Например:

<p align=center>Это центрированный параграф.

<p >А это параграф, выровненный по правому краю.

По умолчанию текст документа выравнивается по левому краю листа, изменить этот

режим разметки можно с помощью элементов или

href="#center">CENTER.

Перемещаем SQL из ASP-файлов в SQL-шаблоны

Одним из главных достоинств ASP является его скриптовость. Т.е. файл и исходным кодом является одновременно и исполняемым файлом. Без необходимости компиляции, связывания и т.д. Выигрыш в скорости у компилируемых объектов обычно бывает менее важен, чем простота скриптов на фазе поддержки проекта. Ничто не сравнится с ощущением молниеносного всевластия над ошибками в приложении, когда можно что-либо подправить в непосредственно работающем сайте прямо по время презентации, зайдя на сервер по FTP (что, конечно же, мы делать не будем, т.к. нарушим структуру версионного контроля).

И, если слишком многое хардкодить в компилируемых объектах 2nd tier, то скриптовость ASP мы утратим. Здесь уместно предложить разумный компромисс. Сложные операции клиента мы согласимся хардкодить в объекты 2nd tier. А вот со всеми SELECT и с единичными INSERT,UPDATE,DELETE (не требующих участия в сложных транзакциях) поступим проще. Вынесем их во внешние файлы, называемые SQL-шаблонами. С ними будет работать один унифицированный объект 2nd tier.

SQL-шаблоны могут иметь любую структуру - XML, INI, etc. Они, теоретически, могут храниться как угодно, и не обязательно в файлах. Главный принцип в том, что каждому SQL-выражению задается сущность, тип (SELECT, UPDATE, INSERT, DELETE) и присваивается имя. И основной код 1st tier обращается к уникальному SQL по комбинации: сущность+тип+имя шаблона. Затем передаются входящие параметры и (в случае SELECT) получаются исходящие. Т.е., основной код 1st tier и клиентских Session-объектов с SQL больше никак не связан.

По сути SQL-шаблоны - это очень простой способ реализовать все объекты сущностей (Entity Beans) быстро и унифицированно.

PerlScript (ActivePerl)

Появившись как язык для написания UNIX-скриптов, Perl обрел новое призвание в Web-разработках благодаря своей простоте, уникальным возможностям для работы со строками, большому количеству библиотек и своей бесплатности. Использовать Perl как PerlScript в ASP несколько эффективнее, чем в качестве CGI или ISAPI, поскольку открывает доступ к стандартным и весьма полезным ASP-объектам (Server, Application, Session, etc.). Perl поддерживает объектно-ориентированное программирование, что дает ему преимущества, описанные выше для JavaScript. Недостатком (условным) использования PerlScript является необходимость его установки на сервер (усложнение deployment), а также то, что это свободно-распространяемый продукт, безо всяких гарантий. С другой стороны, для стран СНГ эта характеристика присуща большинству программных продуктов, и потому этот недостаток неактуален. Решать, кто дольше просуществует и будет продолжать выпускать обновленные версии своих продуктов - Microsoft или ActiveState (разработчик ActivePerl) - тоже дело неблагодарное. Поэтому стоит изначально закладывать в проект возможность для перехода на конкурирующую технологию. Для ASP+PerlScript эта технология - PHP. Так же, как ASP+JScript можно перевести на JSP, так и ASP+PerlScript можно перевести на PHP, поскольку скриптовый язык PHP по синтаксису близок к Perl. Этот переход видится немного более сложным, чем ASP+JScript->JSP, но вполне осуществимым.

К неоднозначным фактам можно отнести наличие у Perl большого количества библиотек. Несмотря на кажущееся явное преимущество, концентрация слишком большой функциональности в ASP-страницах (к чему склоняют Perl-библиотеки) приводит к нарушению баланса распределенной системы. Вместо того, чтобы выносить функциональность в 2nd tier объекты, разработчики размещают сложный и ресурсоемкий код в ASP-файлы, в результате система становится немасштабируемой, а IIS - перегруженным. Решением этой проблемы выглядит разработка 2nd tier COM-объектов на том же Perl (возможность писать COM-объекты на Perl ActiveState предлагала, на момент написания статьи, за 110$). Опять же, мы имеем корпоративный стандарт - ASP+PerlScript & COM-объекты на Perl, со всеми преимуществами корпоративных стандартов.

Поля для ввода нескольких строк текста TEXTAREA

<!ELEMENT TEXTAREA - - (#PCDATA)*>

<!ATTLIST TEXTAREA

name CDATA #REQUIRED

rows NUMBER #REQUIRED

cols NUMBER #REQUIRED

Для элементов TEXTAREA необходимо указывать как начальный, так и

конечный тэги. Содержимое данного элемента должно ограничиваться лишь текстом и

объектами-символами. Обычно содержит текст инициализации, который при загрузке

документа изначально будет записываться в данное поле.

Пример:

<TEXTAREA NAME=address ROWS=4 COLS=40&gt

Ваш адрес ...

</TEXTAREA>

Браузерам конечных пользователей рекомендуется, подготавливая информацию такого

поля к передаче на сервер, обозначать концы строк в виде пары символов CR и LF (в

кодах ASCII это десятичные числа 13 и 10). В данных, представляемых на сервер, должен

использоваться набор символов ISO Latin-1, если о сервере заранее не сообщается, что

он может работать и с другими наборами символов.

name

Определяет название, которое будет использовано для идентификации данного поля

textarea при предоставлении заполненной формы на сервер.

rows

Задает количество строк текста, видимых на экране. Пользователям должна быть

предоставлена возможность ввести большее количество строк, чем задано этим параметром,

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

содержимого поля textarea в случаях, когда текст уходит за пределы видимой области.

cols

Определяет ширину создаваемого текстового поля (единицей измерения служит средняя

ширина символов). Пользователи должны тем не менее иметь возможность ввести строку

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

некие средства для прокрутки содержимого поля textarea в горизонтальном направлении,

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

также автоматически разбивать длинные строки текста на несколько более коротких, зато

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

средствах горизонтальной прокрутки.

Поля заполняемых форм

В пределах элемента FORM разрешается использовать только

href="#input">INPUT, и

href="#textarea">TEXTAREA. Элемент

href="#input">INPUT может использоваться в заполняемых формах для

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

для ввода паролей, контрольные ящички, радиокнопки, кнопки подтверждения и

перезагрузки, скрытые поля формы, поля для загрузки файлов, а также кнопки с

изображениями. Элементы используются для

разметки меню с единственным или множественным выбором. Элементы

href="#textarea">TEXTAREA используются для разметки полей, изначально

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

используется затем при инициализации соответствующего поля.

Послесловие

Не привязываемся к Microsoft, не привязываемся к языку скриптов, не привязываемся к

стандартным ASP-объектам, не привязываемся к MTS... (о стремлении к абсолютной свободе)

Смысл этой статьи сводится к тому что проекту, при желании, можно придать довольно большую степень свободы. Даже без особых дополнительных затрат. Свободу от аппаратной/программной платформы, web-технологии, источника данных, инфраструктуры 2nd tier, от проблем с web-мастерами не разбирающимися в программировании и с бездарными в web-дизайне программистами (к коим относит себя автор статьи). Свободу от прихотей Microsoft, Sun, Oracle, Borland, Allaire, BEA и т.д. , которые привнесли в нашу жизнь все эти занимательные технологии и часто приятно, и не очень, удивляют нас своими выходками.

В 80-х годах SQL дал программистам относительную свободу от конкретной реализации сервера реляционной БД. В 90-х появился, например, J2EE, претендующий на предоставление свободы от конкретной реализации сервера приложений. Но почему бы не быть свободыми и от SQL, и от J2EE, даже строя проект на этих технологиях? :)

Август - Октябрь 2001

Предварительно отформатированный текст

<!ELEMENT PRE - - (%text)* -(%pre.exclusion)> <!ATTLIST PRE width NUMBER #implied >

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

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

Элемент PRE имеет ту же самую модель контекста, что и параграф, за исключением графических изображений и элементов, вызывающих изменение размера шрифта, таких как IMG, BIG, SMALL, SUB, SUP и FONT.

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

Пример использования элемента PRE:

<PRE> Higher still and higher

From the earth thou springest

Like a cloud of fire;

The blue deep thou wingest,

And singing still dost soar, and soaring ever singest.

</PRE>

будет воспроизведено как:

Higher still and higher

From the earth thou springest

Like a cloud of fire;

The blue deep thou wingest,

And singing still dost soar, and soaring ever singest.

Символ горизонтальной табуляции (записываемый в кодировках Unicode, US ASCII и ISO

8859-1 как десятичное число 9) должен интерпретироваться стандартным образом как

наименьшее количество пробелов, кратное 8. Использовать этот символ крайне

нежелательно, поскольку при редактировании текстов символу табуляции обычно на

странице ставятся в соответствие другие позиции, что в свою очередь приводит к

неадекватному воспроизведению данного документа другими программами.

API для использования SQL-шаблонов

Работу с SQL-шаблонами будет осуществлять специально написанный унифицированный объект 2nd tier. А в ASP стандартная библиотека Project ASP API будет предоставлять удобную оболочку (адаптер) для этого объекта. Пусть этот адаптер называется EntityManager. Упрощенно, он должен предоставлять все те же 4 DML функции: SELECT, UPDATE, INSERT, DELETE. Часто предлагается использовать другие названия, чтобы подчеркнуть, что это уже не SQL, а абстрактная сущность уровня бизнес-логики. "SELECT" называют, например, "Get", "UPDATE" -> "Amend", "INSERT" -> "New" или "Create", "DELETE" -> "Remove". Ограничения, также, накладывает используемый язык программирования. Например, в JScript "delete" является зарезервированным словом и его нельзя использовать как имя.

"SELECT" можно разделить на 2 метода. Один возвращает единичную строку выборки. А второй возвращает объект-итератор, через который можно получить многострочную выборку. В JScript и PerlScript достаточно просто реализуется динамическое создание нового типа объекта и его возврат как результат метода. В обоих случаях "SELECT"-методов, атрибуты возвращаемого объекта будут соответствовать OUT-переменным SQL-шаблона. А, в случае многострочной выборки, объект будет дополнительно содержать стандартные, для итератора, методы next() и eof(). Никто не запрещает также предложить другие удобные в работе методы.

Вот пример списка методов класса EntityManager:

selectOne(entity_name, template_name, arg1, arg2, ..., argN)	Этот метод получает имя сущности, имя шаблона и список входных параметров шаблона. Как результат, возвращается объект, содержащий выходные параметры шаблона в виде своих атрибутов. В JavaScript это реализуется при помощи функции eval(): например так: s = "this.sFirstName='"+sFirstName+"';\n"; s += "this.sLastName=... ... obj = eval("new function(){ "+s+" } "); return obj; Все эти механизмы скрывает адаптер EntityManager. Он взаимодействует с 2nd tier объектом, который может передавать сразу все полученные атрибуты в виде пригодной для eval() строки. Таким образом будет экономится время на вызовы 2nd tier (все атрибуты будут получены одним вызовом) и на формирование JScript-объекта.
selectSet(entity_name, template_name, arg1, arg2, ..., argN)	Этот метод возвращает объект-итератор, атрибуты которого аналогичны описанным для selectOne(), а методы стандартны для итераторов: next(), eof(), и close()
selectAttr(entity_name, template_name, arg1, arg2, ..., argN)	Возвращает значение первого выходного параметра шаблона (для простейших SELECT-выражений, выбирающих 1 значение)
exists(entity_name, template_name, arg1, arg2, ..., argN)	Возвращает TRUE/FALSE при наличии/отсутствии результирующих строк у SQL-шаблона типа SELECT
update(entity_name, template_name, arg1, arg2, ..., argN)	Реализует DML-команду UPDATE
insert(entity_name, template_name, arg1, arg2, ..., argN)	Реализует DML-команду INSERT
remove(entity_name, template_name, arg1, arg2, ..., argN)	Реализует DML-команду DELETE
close()	деструктор объекта EntityManager

Вышеописанные методы имеют переменное число

    Вышеописанные методы имеют переменное число аргументов, что совсем не является проблемой для Perl, а в JavaScript массив аргументов метода объекта (внутри этого метода) получается через запись this.имя_метода.arguments;

    Очень часто более сложную бизнес-логику для операции с сущностями абстрактно можно свести к одной из 4х вышеупомянутых DML команд - SELECT, INSERT, UPDATE, DELETE. И так же нужно передать входные и получить выходные параметры. А это означает, что мы можем использовать одинаковую форму записи вызовов к SQL-шаблонам и к сложным операциям бизнес-логики 2nd tier. Корректную переадресацию вызовов инкапсулирует EntityManager, действуя в зависимости от имени шаблона. Например, вызов SQL-шаблона сущности Shop, типа INSERT, c именем "NewShop", может переадресовываться сложному объекту 2nd tier, создающему новый экземпляр сущности Shop и выполняющий соответствующие действия. Основной ASP-код не будет никак от этого зависеть, т.к. форма вызова остается унифицированной.

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

Пример разделения монолитной ASP-страницы

Вам, вероятно, интересно будет взглянуть на то, что станет с обычной ASP-страницей, переработанной по описанным методикам. Вот "притянутый за уши" пример:

Монолитный ASP-файл: showcustomers.asp	Разделенные файлы:
<%@Language=JScript%> <html> <head> <title>Customers</title> </head> <body> <% dtBefore = Session("Date_Before"); dtAfter = Request.Cookies("Date_After"); if ((dtBefore==null) (typeof(dtBefore)=="undefined")){ // use default value if empty dtBefore = "01.01.2200"; } if ((dtAfter==null) (typeof(dtAfter)=="undefined")){ // use default value if empty dtAfter= "01.01.1950"; } %> <h4>All Customers between <%=dtAfter%> and <%=dtBefore%> </h4> <% objADOConn = Server.CreateObject("ADODB.Connection"); objADOConn.Open("dsn=DSN_DBSAMPLE;"); rst = objADOConn.Execute(" \ select FIRST_NAME, LAST_NAME \ from CUSTOMER \ where REGISTER_DATE <= "+dtBefore+" \ and REGISTER_DATE >= "+dtAfter+" \ order by LAST_NAME, FIRST_NAME \ ");%> <table><tr><td>First Name</td> <td>Last Name</td></tr> <% while (!rst.EOF) { %> <tr><td><%=rst.Fields("FIRST_NAME").Value%></td> <td><%=rst.Fields("LASE_NAME").Value%></td></tr> <% rst.MoveNext(); } %> </table> <% rst.Close(); objADOConn.Close(); %> </body> </html>		showcustomers.asp
<%@Language=JScript%> <!--#include file="/libs/Core.inc"--> <% dtBefore = Core.getSession().getDate("Date_Before", "01.01.2200"); // default value if empty dtAfter = Core.getSession().getDate("Date_After", "01.01.1950"); // default value if empty objEM = Core.getEntityManager(); iter = objEM.selectSet("Customer","AllBetweenDates", dtAfter, dtBefore); %> <!--#include file="_t_showcustomers.htm.asp"--> <% Core.close(); %>
HTML-шаблон: _t_showcustomers.htm.asp
<html> <head> <title>Customers</title> </head> <body> <h4>All Customers between <%=dfAfter%> and <%=dfBefore%> </h4> <table> <tr><td>First Name</td> <td>Last Name</td></tr> <% while (!iter.eof()) { %> tr><td><%=iter.sFirstName%></td> <td><%=iter.sLastName%></td></tr> <% iter.next(); } %> </table> </body> </html>
SQL-шаблон (INI format): /entities/Customer/select/ AllBetweenDates.ora8
[Params] name=AllBetweenDates type=select entity=Customer INnames=dtAfter,dtBefore INtypes=d,d OUTnames=sFirstName,sLastName OUTtypes=s,s [SQL] select FIRST_NAME, LAST_NAME from CUSTOMER where REGISTER_DATE <= ::dtBefore and REGISTER_DATE >= ::dtAfter order by LAST_NAME, FIRST_NAME

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

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

Данный материал может использоваться SGML-браузерами в качестве инструкций языка

sgml при проверке документов на соответствие правилам HTML 3.2 DTD. При этом

предполагается, что данный набор правил был записан в виде файла "HTML32.dtd" и что в

файле "ISOlat1.ent" указаны объекты Latin-1.

-- html32.soc: catalog for parsing HTML 3.2 documents -- SGMLDECL "HTML32.dcl" PUBLIC "-//W3C//DTD HTML 3.2 Final//EN" HTML32.dtd PUBLIC "-//W3C//DTD HTML 3.2 Draft//EN" HTML32.dtd PUBLIC "-//W3C//DTD HTML 3.2//EN" HTML32.dtd PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML" ISOlat1.ent

Пример структуры SQL-шаблонов

Рассмотрим один из вариантов организации структуры SQL-шаблонов в виде каталогов и файлов.

Допустим, корневой каталог структуры называется просто "entities" ("сущности").

В этом каталоге находятся подкаталоги, соответствующие сущностям базы данных. На рисунке их четыре: Agent, Customer, Goods, Shop. (имена сущностей принято записывать в единственном числе).

В каждом каталоге сущности находятся 4 подкаталога, соответствующих типам DML SQL-выражений: SELECT, UPDATE, INSERT, DELETE.

В каталогах DML-типов находятся сами SQL-шаблоны. Это просто файлы, у которых имя соответствует назначению SQL-шаблона, а расширение, например, определяет тип DB сервера под который они написаны. (т.е. можно иметь несколько одинаковых SQL-шаблонов оптимизированных под разные типы SQL-серверов: Oracle, MSSQL, MySQL, etc.).

Дополнительно, в корневом каталоге "entities" может находиться общий конфигурационный файл доступа к DB. А в каталогах сущностей - опциональные конфигурационные файлы доступа к DB для каждой сущности. Таким образом, мы можем обеспечить инфраструктуру для хранения различных сущностей на различных DB-серверах.

Приведем пример файла SQL-шаблона в *.INI-подобном формате (исключительно для простоты, т.к. XML-формат файла в данном случае гораздо удобнее). Это шаблон сущности Customer, типа SELECT, который производит выборку имен и фамилий всех клиентов, зарегистрировавшихся в промежутке между двумя заданными датами

[Parameters]

name=AllBetweenDates

type=select

entity=Customer

INnames=dtAfter,dtBefore

INtypes=d,d

OUTnames=sFirstName,sLastName

OUTtypes=s,s

[SQL]

select FIRST_NAME, LAST_NAME

from CUSTOMER

where REGISTER_DATE <= ::dtBefore

and REGISTER_DATE >= ::dtAfter

order by LAST_NAME, FIRST_NAME

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

Затем идут имена и типы входных параметров(INnames, INtypes). Входные параметры доступны в SQL выражении через синтаксис "::"+<имя параметра>. Типы задаются символами. Например, дата/время - d, строка - s, целое число - i, и т.д.

Затем идут имена и типы выходных параметров - атрибутов(OUTnames, OUTtypes).

И, наконец, в секции [SQL] записано само SQL выражение. Его результат доступен 1st tier по именам, записанным в OUTnames.

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

Но на практике, это не слишком большая проблема.

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

Приоритеты в Business Web Application

Так или иначе, нам придется делать выбор - что важнее в Business Web Application с точки зрения пользователя (как источника прибыли), в условиях ограниченных ресурсов на разработку( временных, финансовых, кадровых и т.д.). Предлагаемая иерархия такова:

1. Функциональная адекватность

- Приложение корректно выполняет свои функции в идеальных условиях (один пользователь в единицу времени, идеальное функционирование аппаратуры и т.д.).

2. Надежность в условиях ограниченной загрузки

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

3. Удобство работы, интуитивно понятный интерфейс

- пользователям удобно работать с системой;

4. Возможность обслужить максимальное расчетное количество одновременно работающих пользователей

- система готова надежно обслужить всех потенциальных пользователей;

5. Высокая скорость работы

- короткое время отклика системы;

6. Красивый дизайн

- дизайн системы эстетически приятен большинству пользователей;

Это спорная схема. Если первейшая задача - продемонстрировать что-то несведущим инвесторам, что пункты 5 и 6, например, можно вынести на первые места. Но для долгосрочного Business Web-проекта приведенная схема, вероятно, близка к реальности. И она хорошо показывает, почему существует так много медленных и не очень эстетичных Web-приложений. Cовременные условия разработки интернет-проектов - это спешка. А в спешке существует склонность не задумываться о вторичных приоритетах до момента выполнения первичных. Требуется "побыстрее что-то сделать". А когда это сделано, оказывается, что надо все переписывать - либо с нуля, либо по частям. Однако, даже если, допустим, пункты 3-6 не имеют изначально большого приоритета, о них все равно следует помнить, и закладывать в проект возможности их решения в будущем. Тогда это решение будет на порядок меньшим по затратам.

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

Проблема ASP-приложений: смесь HTML, SQL и VBScript, с трудом поддающаяся осмыслению

Появление Active Server Pages(ASP) для многих стало знаменательным событием. Технологии-конкуренты - Personal (в начале подразумевался Perl) Home Pages(PHP), Java Server Pages(JSP), ColdFusion Markup Language(CFML) и PL/SQL Server Pages (PSP) появились позднее и, частично, носили подражательный характер (что не уменьшает их достоинств). Наиболее интересными и полезными качествами, которыми привлекала технология ASP, можно считать:

удобный способ объединение Server-Side Script c HTML;

скриптовый подход (интерпретируемый язык) - т.е. файл с исходным кодом ASP одновременно является его исполняемым файлом, что упрощает процессы разработки и поддержки;

концепция "Session" - переменные для каждого пользовательского соединения, как удачное решение вечной проблемы stateless-протокола HTTP;

возможность организации распределенной архитектуры на основе инфраструктуры COM (Component Object Model), DCOM, COM+. Дополнительные возможности, предоставляемые Microsoft Transaction Server (MTS) - такие, например, как контекст объектов, пул и т.д.;

удобный набор объектов-утилит: Server, Application, Request, Response, Session, ObjectContext.

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

    К тому же, полученный подобным образом ASP-файл, в конкретный момент времени, может править только 1 человек. Грубо говоря, это означает, что если работает программист - то дизайнер спит. А если файл правит дизайнер - то спит программист. Т.е. наблюдается невозможность распределения труда там, где она потенциально возможна, и могла бы ускорить разработку.

    Применяемый, в быстро развивающемся Internet, такой неоднозначный подход, как Rapid Application Development (RAD), еще больше обостряет ситуацию. Проекты часто разрабатываются на скорую руку - лишь бы что-то быстро показать инвесторам, а затем уже пересматривается архитектура, приглашаются профессиональные дизайнеры. Но эти дизайнеры совершенно бессильны что-либо исправить в той кошмарной смеси HTML, SQL и VB/J/PerlScript которая, в общем-то, разрабатывалась как прототип, и была, почему-то, принята за конечный продукт (по горячему желанию руководства), в котором надо всего лишь "немного улучшить дизайн".

    Вышеописанное несколько напоминает распространенную ситуацию с популярными средствами RAD в области разработки обычных Standalone-приложений. Такими как Delphi, C++Builder, Centura Team Developer, VisualBasic, и т.д. Когда код бизнес-логики оказывается "размазанным" по различным обработчикам элементов пользовательского интерфейса. Навсегда связывая проект с имеющейся технологией и архитектурой и затрудняя поддержку и расширение кода. Масштабирование(т.е., например, вынесение бизнес-логики в объекты 2nd tier - COM,CORBA,EJB), фактически, становится невыполнимым, поскольку код бизнес-логики придется, в буквальном смысле, "соскабливать" с различных ComboBoxes, TextFields, Buttons, и т.п.

    Таким "размазыванием" страдают и современные разработки на ASP. С другой стороны, представляется вполне возможным избежать подобной ситуации. Просто осознавая с самого начала возможные неприятности в будущем, и закладывая в проект дополнительные степени свободы. Например, всегда хорошо иметь, про запас, возможность быстро сменить инфраструктуру Web-приложения - т.е., например, перейти с ASP на JSP или PHP, без переписывания основного кода.  И эта возможность - вполне реальный эффект (причем м.б. даже побочный) хорошей организации проекта.

    Для начала, сформулируем проблемы, присущие многим ASP-проектам, с которыми мы будем бороться:

Смесь бизнес-кода и HTML приводит к трудностям поддержки и того и другого;

Наличие большого количества DB-зависимого кода в ASP-страницах привязывает их к источнику данных;

Перегруженность ASP-страниц функциональностью приводит к перегрузкам IIS (хотя это можно решить кластеризацией IIS);

Смысловая перегрузка ASP-страниц затрудняет их поддержку;

Хранение бизнес-логики в ASP-страницах в "размазанном" виде приводит к затруднению ее вынесения в объекты 2-nd tier (при необходимости масштабирования и поддержки разных видов 1st tier-клиентов);

Полная зависимость кода проекта от самой технологии ASP

Что предлагается делать в этой статье (кратко):

Вынести HTML из ASP-страниц в отдельные файлы;

Вынести SQL из ASP-страниц;

Абстрагировать Microsoft ASP-специфические возможности в объекты общей библиотеки;

Организовать все часто используемые функции в виде методов общей объектно-ориентированной библиотеки;

Использовать JScript или PerlScript и отслеживать пути быстрого перехода на JSP/PHP, при возникновении подобной необходимости.

Распределенная архитектура, как наиболее подходящая для Business Web Application

В этой схеме собраны почти все варианты названий трех уровней распределенного приложения. Чтобы избежать путаницы, будем именовать уровни так: 1st tier, 2nd tier и 3rd tier, по причине краткости написания. Выбирать названия по другим критериям слишком сложно. Называть 3-х уровневую архитектуру N-уровневой вероятно не стоит, т.к. эти N уровней, обычно, появляются как более детальное изображение той же 3-х уровневой схемы, не внося принципиально новых идей. N-уровневые схемы удобны чтобы показать систему с точки зрения развертывания и администрирования. Но с точки зрения разработки эти дополнительные уровни малоинтересны.

Три уровня (с позиции программирования) - это хранение, обработка

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

2-x уровневая архитектура (Клиент-Сервер)

В классической архитектуре клиент-сервер, бизнес-логика может располагаться как у клиента, так и на сервере. В результате существует тенденция смешивания бизнес-логики с интерфейсом пользователя и/или со структурой БД.

3-x уровневая архитектура (идеальный вариант)

3-х уровненая архитектура подразумевает четкое выделение бизнес-логики.

Интересно отметить, что сервисы для вызова бизнес-логики (2nd tier), относятся к 1st tier. А вот интерфейс с базой данных (или любым источником данных) - сразу к 3rd tier. Такой подход позволяет четко очертить границы уровня бизнес-логики и отличие 3-х уровневого подхода от 2-х уровневого (клиент-сервер).

3-x уровневая архитектура (фактический вариант)

На практике, мы имеем нечто подобное. По различным причинам бизнес-логика остается на 1st и 3rd tier. Это может быть оправдано, если не приведет к перегрузке уровня, на котором находится ненормированный код. И если этот код легко можно перенести в 2nd tier объекты. Например, поместив бизнес-логику в хранимые процедуры в 3rd tier, мы можем получить большой выигрыш в производительности. Если же эти хранимые процедуры написаны на Java, то перенести их в 2nd tier будет несложно. А вот бизнес-логика на 1st tier распространена повсеместно(как уже упоминалось), и, обычно, связана с неудачной архитектурой. Вопрос о бизнес-логике в ASP-страницах мы рассмотрим позднее.

<



    Теперь, попытаемся выявить основные критерии идеальной распределенной архитектуры:

Каждый уровень распределенного приложения может взаимодействовать только со смежным уровнем.

Это означает, что: 1st tier не должен иметь прямого доступа к 3rd tier и наоборот; 2nd и 3rd tiers не должны иметь прямого интерфейса с пользователем; обращение к источнику данных из 1st tier происходит только через объекты 2-nd tier;

Вся сложная бизнес-логика находится в объектах 2nd tier.

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

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

Это означает, что распределенная архитектура не зависит от способа развертывания (deployment) приложения - все уровни могут быть размещены физически как одном компьютере, так и на разных, в условиях заданной сетевой структуры;

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

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

    Проблема ASP заключается в том, что смесь скрипта бизнес-логики, HTML и SQL представляет собой 2-х уровневую архитектуру (клиент-сервер), которая с задачами Web-приложений не справляется. Поэтому мы предложим способ как разделить ASP на три составляющие - ASP-код с бизнес-логикой, HTML и SQL.

Response.Write() - проклятие для дизайнера

Мы можем записать команду генерации динамического HTML в ASP двумя способами:

1) <%=sShopKey%>

2) Response.Write(sShopKey);

Работают они, с внутренней точки зрения, одинаково. Однако они записываются с несколько различным синтаксисом. Сравните два варианта записи:

1) <a href="javascript: alert('Name: <%=obj.getName()%>');">

2) <% Response.Write("<a href=\"javascript: alert('Name: "+obj.getName()+"');\">"); %>

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

Списки

Пунктами списка в HTML могут быть блочные элементы, элементы на уровне текста, и

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

address. Данное ограничение накладывается в HTML 3.2 DTD в записи %flow.

Списки определений

<!ELEMENT DL - - (DT|DD)+> <!ATTLIST DL compact (compact) #IMPLIED -- more compact style -- > <!ELEMENT DT - O (%text)*> <!ELEMENT DD - O %flow;>

Списки определений имеют вид:

<DL> <DT> название термина

<DD> определение термина

... </DL>

Заметим, что элементы DT можно использовать только как контейнеры для элементов текстового уровня. Но в то же время внутри DD можно использовать блочные элементы (исключение составляют заголовки и элементы address).

Пример списка определений:

<DL> <DT>Первый термин<dd>Определение первого термина. <DT>Второй термин<dd>Определение для второго термина. </DL>

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

Первый терминОпределение первого термина. Второй терминОпределение для второго термина.

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

Статус данного документа

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

Полный список рекомендаций, поддерживаемых организацией W3C, а также другие документы технического характера можно найти по адресу http://www.w3.org/pub/WWW/TR/.

Структура документов HTML

Документы в языке HTML 3.2 начинаются с декларации <!DOCTYPE>, затем следует элемент HTML, внутри которого содержатся и затем : <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <TITLE>Изучение динамики популяций</TITLE> ... другие элементы заголовка

</HEAD> <BODY> ... тело документа

</BODY> </HTML>

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

Каждый документ, отвечающий требованиям HTML 3.2, должен начинаться с декларации <!DOCTYPE>, которая необходима для того, чтобы отличить документ, составленный по спецификации HTML 3.2, от документов, написанных для других версий языка HTML. Спецификация HTML не конкретизирует объекты хранения. Как следствие, отсутствует ограничение, чтобы декларация для типа документа находилась в том же самом элементе хранения, что и сам документ (то есть находилась в том же файле). Web сайт может автоматически дополнять предоставляемые HTML-файлы такой декларацией для типа документа, если известно, что все имеющиеся на сайте HTML файлы соответствуют спецификации HTML 3.2.

Каждый документ, согласно спецификации HTML 3.2, должен также содержать описательный элемент title. В итоге, минимальный документ HTML 3.2 выглядит следующим образом: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<TITLE>Изучение динамики популяций</TITLE>

Замечание: Теперь в декларации слово "Final" заменяет "Draft", поскольку спецификация языка HTML 3.2 была одобрена организациями-членами W3C.

STYLE and SCRIPT

<!ELEMENT STYLE - - CDATA -- место под информацию стиля --> <!ELEMENT SCRIPT - - CDATA -- место под описания скриптов -->

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

Тип контекста для данных элементов определяется как CDATA. Поэтому эти элементы могут содержать внутри себя только объекты-символы SGML. Все элементы разметки или разделители браузером игнорируются и передаются приложению как исходные данные. Исключение составляют разделители ETAGO ("</"), за которыми сразу следует какая- либо буква из названия [a-zA-Z]. Это значит, что распознается завершающий тэг соответствующего элемента (или тэг того элемента, в который он был вложен), однако фиксируется ошибка, если разделитель ETAGO был указан неправильно.

Таблицы

В версию 3.2 языка HTML включен хорошо разработанный набор элементов из

спецификации , который может использоваться для разметки

табличных материалов, либо при осуществлении еще более сложных вариантов разметки.

Заметим, что в последнем случае обычно возникают проблемы при работе с браузерами,

ориентированными на голосовой интерфейс, а также с браузерами, работающими

исключительно в текстовом режиме.

<!ENTITY % Where "(left|center|right)">  <!ENTITY % cell.halign "align (left|center|right) #IMPLIED" >  <!ENTITY % cell.valign "valign (top|middle|bottom) #IMPLIED" > <!ELEMENT table - - (caption?, tr+)> <!ELEMENT tr - O (th|td)*> <!ELEMENT (th|td) - O %body.content> <!ATTLIST table -- table element -- align %Where; #IMPLIED -- table position relative to window -- width %Length #IMPLIED -- table width relative to window -- border %Pixels #IMPLIED -- controls frame width around table -- cellspacing %Pixels #IMPLIED -- spacing between cells -- cellpadding %Pixels #IMPLIED -- spacing within cells -- > <!ELEMENT CAPTION - - (%text;)* -- table or figure caption --> <!ATTLIST CAPTION align (top|bottom) #IMPLIED > <!ATTLIST tr -- table row -- %cell.halign; -- horizontal alignment in cells -- %cell.valign; -- vertical alignment in cells -- > <!ATTLIST (th|td) -- header or data cell -- nowrap (nowrap) #IMPLIED -- suppress word wrap -- rowspan NUMBER 1 -- number of rows spanned by cell -- colspan NUMBER 1 -- number of cols spanned by cell -- %cell.halign; -- horizontal alignment in cells -- %cell.valign; -- vertical alignment in cells -- width %Pixels #IMPLIED -- suggested width for cell -- height %Pixels #IMPLIED -- suggested height for cell -- >

В общем случае таблицы имеют следующий вид:

<TABLE BORDER=3 CELLSPACING=2 CELLPADDING=2 WIDTH="80%"> <CAPTION> ... заголовок таблицы ... </CAPTION> <TR><TD> первая клетка таблицы <TD> вторая клетка
<TR> ... ... </TABLE>
У элемента TABLE нет обязательных атрибутов. По умолчанию таблица
печатается без рамки. Разметка таблицы в общем случае осуществляется автоматически в
соответствии с объемом содержащейся в ней информации, однако у автора всегда имеется
возможность самому выбрать ширину таблицы, воспользовавшись атрибутом
WIDTH. Дополнительный контроль над процессом разметки (таблицы)
достигается также через атрибуты BORDER, CELLSPACING и
CELLPADDING. Заголовки таблицы (CAPTION) выравниваются по
верхнему или нижнему краю таблицы в зависимости от атрибута ALIGN.
В таблице каждый ряд ячеек содержит открывающий тэг элемента TR, хотя
соответствующий закрывающий тэг всегда может быть опущен. Отдельные клетки таблицы
размечаются элементом TD, если это данные, и элементом TH,
если это заголовки. Как и в случае с TR, эти элементы являются
контейнерами и могут быть записаны без указания закрывающего тэга. Элементы
TH и TD могут иметь несколько атрибутов: ALIGN
и VALIGN для выравнивания содержимого ячейки, ROWSPAN и
COLSPAN для нестандартных ячеек, простирающихся на несколько рядов или
колонок. В отдельной ячейке таблицы можно размещать самые разнообразные элементы
разметки как блочного, так и текстового уровня, включая поля заполняемых форм и даже
целые новые таблицы.
Для элемента TABLE всегда необходимо указывать как начальный, так и
конечный тэги. При этом разрешается использовать следующие атрибуты:
align
Данный атрибут принимает одно из следующих значений: LEFT,
CENTER или RIGHT (используемый при этом регистр значения не
имеет). Указывает для текущей таблицы, каким образом при разметке осуществляется ее
горизонтальное выравнивание. По умолчанию выполняется выравнивание таблицы по левой
границе листа, однако это правило можно переопределить посредством элементов

href="#div">DIV или .
width
В отсутствии данного атрибута ширина таблицы определяется автоматически в
соответствии с объемом содержащегося в ней материала. Однако посредством атрибута
WIDTH вы можете сами задать ширину таблицы либо в пикселах (например
WIDTH=212), либо как процент от расстояния между левой и правой границами
экрана (например WIDTH="80%" ).
border
Этот атрибут позволяет задавать для таблицы ширину внешней рамки - в пикселах
(например, BORDER=4). Данному атрибуту может быть также присвоено
значение нуль, чтобы полностью отказаться от внешней рамки. Рамка таблицы не рисуется
также, если атрибут border вообще отсутствует в разметке. Заметим, что
некоторые из браузеров способны воспринимать также конструкцию <TABLE
BORDER>, считая ее семантически эквивалентной атрибуту
BORDER=1.
cellspacing
В традиционных настольных издательских системах смежные ячейки в таблице имеют
общую границу. В языке HTML это не так. Каждая ячейка имеет собственную границу,
отделенную промежутком от границ соседних ячеек. Ширину этого промежутка в писелах
можно устанавливать посредством атрибута CELLSPACING, (например
CELLSPACING=10). То же самое значение определяет расстояние между общей
границей таблицы и границами крайних ячеек.
cellpadding
Данный атрибут устанавливает для каждой ячейки в таблице расстояние в пикселах
между рамкой ячейки и содержащимся в ней материалом.
Элемент CAPTION может иметь только один атрибут - ALIGN,
который может принимать два значения: ALIGN=TOP или
ALIGN=BOTTOM. Посредством этого атрибута можно выбирать, помещать ли
заголовок над таблицей или, соответственно, под ней. Большинство браузеров по
умолчанию ставит заголовок над таблицей. Для элемента CAPTION необходимо
всегда указывать начальный и конечный тэги. Содержание заголовка должно ограничиваться
простым текстом и элементами текстового уровня, задаваемыми объектом %text.
Использование блочных элементов в этом случае недопустимо.
Для TR - элемента, начинающего новый ряд таблицы - необходимо

указывать начальный тэг, однако всегда можно опустить конечный тэг. Элемент
TR выступает в роли контейнера для ячеек таблицы и может иметь два
атрибута:
align
Устанавливает стиль горизонтального выравнивания для содержимого ячейки, который
будет использоваться по умолчанию. Атрибут может принимать одно из следующих значений
(независимо от используемого регистра): LEFT, CENTER или
RIGHT и выполняет ту же самую роль, что и атрибут ALIGN при
разметке параграфов.
valign
Данный атрибут может использоваться при выборе правила, согласно которому - если
нет других указаний - будет осуществляться вертикальное выравнивание во всех ячейках
данной строки. Атрибут может принимать одно из следующих значений (независимо от
используемого регистра): TOP, BOTTOM или
MIDDLE. При этом содержимое ячейки будет, соответственно, выравниваться
по ее верхнему или нижнему краю, либо посередине.
Для разметки таблицы на уровне ячеек предусмотрено уже два элемента: элемент
TH используется для разметки заголовков, а TD - для ячеек с
данными. Такое разграничение позволяет программам пользователей оформлять заголовок
таблицы и данные разными шрифтами, а кроме того улучшает работу браузеров,
использующих речевой интерфейс. Для элементов TH и TD всегда
необходимо указывать начальные тэги, конечные же всегда могут быть опущены. При
разметке ячеек таблицы могут использоваться следующие атрибуты:
nowrap
В присутствии этого атрибута блокируется автоматический перенос слов в пределах
текущей ячейки (например в случае <TD NOWRAP>). Действие этого
атрибута эквивалентно использованию в ячейке объектов  ,
создающих неотменяемые пробелы.
rowspan
Данный атрибут имеет значением положительное целое число, определяющее количество
рядов, на которые простирается данная ячейка. Этому атрибуту по умолчанию
присваивается значение 1.
colspan
Данный атрибут имеет значением положительное целое число, определяющее количество
колонок, на которые простирается данная ячейка. По умолчанию атрибуту присваивается

значение 1.
align
Определяет выполняемое по умолчанию правило горизонтального выравнивания для
содержимого текущей ячейки, тем самым отменяя действие атрибута ALIGN,
задаваемого при общей разметке текущего ряда ячеек. При этом используются все те же
самые значения: LEFT, CENTER и RIGHT. Если
атрибут ALIGN для данной ячейки не был указан, то по умолчанию для
элементов <td> выполняется выравнивание по левому краю, а для
элементов <th> - центрирование. Напомним, что вы можете отменить
это правило, задав трубуемый атрибут ALIGN в элементе TR.
valign
Определяет способ вертикального выравнивания для содержимого текущей ячейки,
отменяя тем самым действие атрибута VALIGN, заданного при общей разметке
данного ряда таблицы. Использует при этом те же самые значения: TOP,
MIDDLE и BOTTOM. Если для данной ячейки атрибуту VALIGN вы
не присвоили какого-либо значения, то по умолчанию для нее осуществляется выравнивание
по центру. Те не менее вы можете изменить такое правило, задав нужный атрибут
VALIGN в элементе TR.
width
Задает ширину площадки, отводимой под содержимое данной ячейки, в пикселах и без
учета ширины границ. Как правило, при разметке будет использоваться предложенное здесь
значение за исключением тех случаев, когда оно начинает вступать в противоречие с
минимальной шириной остальных ячеек в той же самой колонке.
height
Задает высоту площадки, отводимой под содержимое данной ячейки, в пикселах и без
учета ширины границ. Как правило, при разметке будет использоваться предложенное здесь
значение за исключением тех случаев, когда оно начинает вступать в противоречие с
минимальной высотой других ячеек в той же самой колонке.
Таблицы обычно рисуются в виде некой рельефной поверхности, приподнимающейся над
поверхностью листа и имеющей внешние скошенные края. Далее на этой поверхности
размещаются уже отдельные ячейки таблицы. Границы вокруг конкретной ячейки рисуются
только в том случае, если она имеет некое содержание. Пустые ячейки в разметке не

участвуют за исключением случаев, когда в них используется объект  .
Описанные алгоритмы, используемые для автоматического определения размеров таблиц,
должны учитывать минимальные и максимальные требования к ширине со стороны каждой
ячейки. Эти ограничения затем используются при определении минимальной и максимальной
ширины каждой колонки и далее - для всей таблицы в целом.
Ячейки, охватывающие несколько колонок, вносят вклад в ширину каждой из них. При
этом один из возможных алгоритмов состоит в том, чтобы равномерно распределить
минимальную и максимальную ширину данной ячейки между этими колонками, другой
заключается в распределении пропорционально вкладам в ширину колонок от остальных
обычных одинарных ячеек.
В некоторых пользовательских программах бывает необходимо или может быть желательно
делать перенос строки посреди слова. В подобных случаях должна ставиться видимая
метка, уведомляющая о том, что это произошло.
Минимальная и максимальная ширина вложенных таблиц дает вклад в минимальную и
максимальную ширину ячейки, куда они помещены. Как только ширина для таблицы верхнего
уровня становится известной, в ней может быть произведен расчет колонок. Далее
появляется возможность назначить ширину для вложенных таблиц и, следовательно,
рассчитать ширину колонок и для них. Если это возможно, всем колонкам должна
назначаться по крайней мере их минимальная ширина. При этом предлагается, что
оставшееся после этой процедуры свободное место будет также распределено между
колонками, но уже пропорционально разнице между максимальной и требуемой минимальной
шириной каждой из них.
Заметим, что указываемые в пикселах ширина и высота относятся к изображению на
экране и должны умножаться на определенный множитель при подготовке к печати на
устройствах с очень высоким решением (таких как лазерные принтеры). Например, если
программа пользователя выводит изображение на дисплей с разрешением 75 пикселов на
дюйм и при этом печатает его же на лазерном принтере с разрешением 600 точек в дюйм,
то в последнем случае значения в пикселах, заданные в атрибутах разметки HTML, должны
быть умножены на 8.

TITLE

<!ELEMENT TITLE - - (#PCDATA)* -(%head.misc)>

Согласно спецификации HTML 3.2, каждый документ обязан иметь ровно один элемент TITLE в поле HEAD. С его помощью программе конечного пользователя сообщается название-уведомление данного документа, которое может быть выставлено в заголовке над окном соответствующей программы и т.д. Модель используемого контекста - PCDATA. Следовательно, в контексте могут использоваться объекты, обозначающие символы из второй половины кодовой таблицы, а также заменяющие такие специальные символы, как & и <. Внутри TITLE нельзя использовать элементы разметки.

Пример элемента TITLE: <TITLE>Изучение динамики популяции</TITLE>

Упорядоченные (нумерованные) списки

<!ELEMENT OL - - (LI)+> <!ATTLIST OL -- ordered lists -- type CDATA #IMPLIED -- numbering style -- start NUMBER #IMPLIED -- starting sequence number -- compact (compact) #IMPLIED -- reduced interitem spacing -- > <!ELEMENT LI - O %flow -- list item --> <!ATTLIST LI type CDATA #IMPLIED -- list item style -- value NUMBER #IMPLIED -- set sequence number -- >

Упорядоченные (или нумерованные) списки имеют следующий вид:

<OL> <LI> ... первый пункт списка

<LI> ... второй пункт списка

... </OL>

В элементе OL может использоваться атрибут START, задающий первое число, с которого начнется нумерация пунктов в таком списке (по умолчанию нумерация начинается с первого номера - 1). Вы можете в любой момент изменить порядок нумерации, записав другой атрибут VALUE в любом из элементов LI. Предполагается, что оба из эти атрибута будут иметь значением целое число. Вы не можете запрограммировать разметку так, чтобы каким-либо образом автоматически продолжить текущую нумерацию в следующем списке, либо пропустить несколько номеров (т.е. не задавая явным образом в элементах OL или LI требуемый номер).

Для того, чтобы заставить программу пользователя печатать списки в более компактном стиле, можно воспользоваться атрибутом COMPACT. Атрибут TYPE в элементе OL дает вам возможность выбрать стиль, каким будет осуществляется нумерация списка:

Тип Стиль нумерации

1	арабские числа	1, 2, 3, ...
a	прописные буквы	a, b, c, ...
A	заглавные буквы	A, B, C, ...
i	маленькие римские числа	i, ii, iii, ...
I	большие римские числа	I, II, III, ...

VBScript

К немногим преимуществам (весьма неоднозначным) VBScript можно отнести то, что он прост для использования VisualBasic-программистами. Если объекты 2nd tier пишутся как COM-объекты на VisualBasic, это может служить оправданием использования VBScript. Т.к. образуется некий "корпоративный стандарт". Язык Basic, сам по себе, является прекрасным языком для обучения программированию, на котором выросло не одно поколение программистов. Однако, непосредственно VBScript, не способствует появлению хорошего стиля программирования и потому стимулирует крах проектов средней и большой сложности. Наверное худшим ограничением является отсутствие возможности объектно-ориентированного программирования, что очень критично для крупных проектов. Если, все-таки, решено использовать VBScript, следует уделить тщательное внимание аккуратности при написании кода, комментариям, отступам, понятным названиям процедур, функции и переменных, хорошему документированию. Это важно при любом программировании, но для VBScript это актуально вдвойне. Не следует также пользоваться независимостью от регистра языка VBScript.

является спецификацией языка разметки

Стандарт HTML 3. 2 является спецификацией языка разметки гипертекста, предложенной организацией W3C и разработанной в начале 1996 года в кооперации с такими поставщиками, как IBM, Microsoft, Netscape Communication Corporation, Novell, SoftQuad, Spyglass, и Sun Microsystems. Версия 3.2 языка HTML дополнена такими широко распространенными элементами, как таблицы, апплеты и обтекание текстом изображений. При этом обеспечивается полная обратная совместимость с ныне существующим стандартом HTML 2.0.

W3C совместно с упомянутыми фирмами продолжает работу над расширением возможностей элементов языка HTML, таких как feagures, объекты мультимедиа, скрипты, типы стилей, разметка (layout), формы, математические символы, и над интернационализацией языка. W3C планирует включить результаты этой работы в следующие версии языка HTML.

Вынесение цельной HTML-страницы в отдельный файл

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

HTML-форматирование. Файл будет включать в себя (SSI) второй файл, который будет цельной HTML-страницей с минимальным количеством четко выделенного ASP-кода. Второй файл, по сути, будет тем же HTML-шаблоном, только вместо, например "[header]" будет написано "<%=obj.getHeader()%>", что не затруднит работу дизайнера. Но в нем также будет возможность выводить более сложные программные структуры. Идея в том, чтобы код во втором файле (где HTML) был действительно минимален и четко выделен. Т.е. все крупные куски кода инкапсулируются в функции и объекты, которые создаются в первом файле (чистый ASP-скрипт). Второй файл (HTML) лишь запускает эти функции и методы объектов. В этом плане JavaScript дает несомненные преимущества. Не пожалейте часа-двух, и изучите разные способы создания объектов в JavaScript - это позволит вам создавать удивительно красивые по своей простоте и логике архитектурные конструкции.

Общая схема разделения ASP/HTML
file1.asp	file2.htm.asp
Business Logic Level: Чтение/Обработка данных. Создание объектов (например объекта objExample), которые будет использовать Файл #2 (file2.htm.asp).	<html>... <h1><%=objExample.getHeader()%></h1> <% while (!objExample.eof()) { %> Text: <%=objExample.getText()%> <% objExample.next(); } %> ...</html>
Presentation Level: <!--#include file="file2.htm.asp"-->
Finalization Level: Закрытие DB-connections, etc.

Отметим также, что в случае перехода на JSP, такой HTML-шаблон можно совсем не менять.

Сформулируем основные принципы вышеописанного подхода:

ASP-страница состоит из 2х файлов

1й файл содержит чистый серверный скрипт, и в нужном месте включает 2й файл, (например через SSI)

1й файл не посылает информацию клиенту

1й файл не содержит команд HTML

1й файл инкапсулирует весь код в функции и/или методы объектов, которые затем могут быть вызваны из 2-го файла

2й файл содержит полную HTML-страницу, от <html> до </html>

2й файл содержит минимально возможный ASP-код. любой код бизнес-логики сокрыт в методах и/или функциях первого файла, и вызывается нужный метод или функция

1й и 2й файлы не содержат команд Response.Write() (по причинам, описанным ниже)

1й файл имеет расширение .asp, т.к. это чистый ASP-файл

2-му файлу можно дать расширение .htm.asp, чтобы подчеркнуть, что это все-таки HTML по содержанию. Имя 2-го файла может быть то же что у 1-го, или с каким нибудь префиксом, для удобства поиска. Например: shopinfo.asp

и _t_shopinfo.htm.asp.

К побочным эффектам подобного разделения можно отнести достаточно простую возможность поддержки генерации не-HTML страниц. Например - WAP или XML. Для этого надо только написать другой файл шаблона (файл #2). Файл с серверным скриптом (#1) останется тем же.

Теперь остановимся еще на двух часто встречающихся деталях.

Заголовки

<!ELEMENT ( %heading ) - - (%text;)*> <!ATTLIST ( %heading ) align (left|center|right) #IMPLIED >

Элементы H1, H2, H3, H4,

H5 и H6 используются в документе для разметки заголовков.

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

размеченные элементами H1, главенствуют над заголовками, размеченными

элементами H2, и так далее вплоть до элементов H6,

определяющих в документе заголовки самого нижнего уровеня. В общем случае более

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

Для выравнивания текста в рамках заголовка вы можете использовать атрибут

ALIGN, например.

<H1 ALIGN=CENTER> ... центрированный заголовок ...

</H1>

По умолчанию заголовки в документе выравнивается по левому краю листа, однако это

правило можно переопределить посредством включения в документ элементов

href="#div">DIV или .