GetInfo.Ru – Компьютерная библиотека
Последние поступления
Как выбрать систему управления базы данных
Базы данных03/09/14
Этапы загрузки UNIX (в схеме)
Unix27/03/12
Gatewall Antispam: тотальный контроль электронной почты
Спам21/04/11
Мастер-класс: создаем Интернет-магазин (Часть 1)
Обзоры ПО20/04/11
CorelDRAW Graphics Suite X5: Что нового?
Обзоры ПО20/07/10
Добавить статью
Самые читаемые материалы
Не отключайте правую кнопку мыши!(18275)
Разработка пиктограмм для веб-сайтов(12989)
Функциональное тестирование(11153)
Что такое юзабилити?(9436)
WEB vs GUI - точка зрения разработчика(9417)
Всего статей: 793Всего авторов: 364Подразделов: 47Добавлено за сутки: 0
Статьи  СТАТЬИ Форум  ФОРУМ Рейтинг  РЕЙТИНГ Поиск  ПОИСК Контакты  КОНТАКТЫ
» Главная » Usability » Каждому хосту — по ГОСТу

Каждому хосту — по ГОСТу


Артемий Ломов
artemy@lomov.ru
http://www.lomov.ru/

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

К примеру, механизм CGI - классический представитель серверных технологий. Любой CGI-скрипт выполняется на сервере, и результат работы такого сценария ни в коей мере не зависит от особенностей клиентского программного обеспечения. Скажем, вопрос такого рода: <Поддерживает ли Internet Explorer 3.0 CGI-скрипты?> лишен всяческого смысла. В то же время, успех исполнения CGI-скрипта всецело и полностью подчинен конфигурации сервера: разрешено ли вообще выполнение скриптов, какие права доступа установлены для файла сценария, что за версия интерпретатора Perl (или другого языка) используется на сервере, имеются ли в наличии все необходимые подключаемые модули и т. д.

Язык HTML - основа Web - столь же классический пример клиентской технологии. Обработка кода web-страницы, вне зависимости от того, является ли последняя статической, созданной раз и навсегда автором сайта, или же динамически сгенерированной при помощи сервера, ложится на плечи браузера.

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

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

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

Дележ <сфер влияния>
В связи с высказанным выше тезисом о том, что серверные технологии таят в себе меньше головной боли для разработчика, чем клиентские, возникает вопрос: а почему бы не отказаться от обработки каких бы то ни было компонентов сайта на стороне клиента вообще?

И вправду, история развития web-технологий демонстрирует тенденцию переноса все большего количества задач со стороны клиента на сервер. На заре становления Web серверных технологий не было вообще. Во времена HTML 2.0 сценарии CGI, за редким исключением, были чрезвычайно простыми и использовались лишь для обработки полей HTML-форм. Сегодня же мир серверных технологий красочен и разнообразен - это SSI, ASP, Java-сервлеты, разнообразные клиент-серверные СУБД, модный нынче конгломерат различных идей под торговой маркой .NET (изобретение Microsoft) и множество других вещей. На крупных сайтах в наше время статические страницы - большая редкость. Почти все документы, отсылаемые браузеру, тем или иным способом формируются на сервере с использованием динамической информации.

В то же время, любой web-сервер (по крайней мере, на нынешнем этапе развития Web, основой которого является протокол HTTP) <умеет> только лишь принимать от клиента запрос и отправлять ему данные. Рендерингом таблиц и отрисовыванием кнопок на экране монитора занимается прикладное ПО на стороне клиента (пресловутый браузер), использующее вычислительные ресурсы локальной машины. Эту задачу вряд ли вообще принципиально возможно возложить на сервер.

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

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

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

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

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

Речь идет о закрытых клиентских технологиях. HTML, CSS, XHTML, XML, XSL и все прочие технологии W3C являются открытыми, то есть подразумевают свободное использование в продуктах многих сторонних производителей. Сколько существует в мире браузеров, XML-парсеров, визуальных HTML-редакторов - только Богу известно. Каждая из этих программ имеет свои особенности, свои <глюки>, и учесть их все ни один разработчик просто не в состоянии. Другой полюс - Flash. Никто, кроме фирмы Macromedia, не имеет права выпускать Flash-редакторы и плагины для воспроизведения Flash-роликов. В результате никакие несовместимости не могут возникнуть принципиально. Возможны только две ситуации: либо Flash-заставка исправно работает и выглядит в точности так, как на компьютере разработчика, либо она не работает вообще и требует обновить версию плагина. Третьего не дано.

Вообразить, что W3C объявит свои технологии закрытыми и выпустит в свет <единственно правильный> браузер, совершенно нереально, ибо тогда Консорциум превратится в монополиста, сравняв с землей свои изначальные предназначение и цели. Это, конечно, недопустимо. Стало быть, должны быть и более мягкие пути решения проблемы несовместимостей.

Делай, что хочешь, только хорошо!
Требования W3C имеют статус рекомендаций. То есть, фактически, производители и разработчики могут их придерживаться, а могут и нет - никто не заставляет.

В статье <Это сладкое слово - интерактивность...> мы проследили, насколько добросовестно основные производители браузеров подчинялись рекомендациям W3C за все время эволюции Web. А ведь от этого напрямую зависят удобство пользователей и производительность труда разработчиков...

Почему бы не ужесточить слегка статус требований W3C? Ведь Консорциум сегодня - уже достаточно влиятельная организация, и он вполне мог бы придать своим рекомендациям статус стандартов, обязательных к выполнению, подобно ISO, IEEE или IEC. Производители же при этом будут поставлены перед необходимостью сертификации своих решений в области web-технологий, будут вынуждены либо улучшить свои продукты до состояния соответствия стандартам, либо уйти с рынка.

До принятия того или иного документа в качестве рекомендации W3C он проходит три стадии <шлифовки>. Это рабочий проект (working draft), который бесчисленное количество раз обсуждается и совершенствуется; кандидат на рекомендацию (candidate recommendation) - нечто вроде бета-версии, более детально <обкатываемой> и выдерживаемой в течение определенного срока; и предлагаемая рекомендация (proposed recommendation) - документ, полностью готовый к утверждению в качестве рекомендации. В состав W3C входит порядка полутысячи участников (в их числе, конечно же, и весь свет производителей клиентского и серверного программного обеспечения web-технологий), и все они активно способствуют внесению корректив в будущие рекомендации. Все вышесказанное призвано проиллюстрировать серьезность и зрелость рекомендаций W3C, их состоятельность для возможного объявления международными стандартами.

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

HTML является достаточно вольным языком - даже при наличии ошибок в коде страница обрабатывается, причем браузер может интерпретировать ошибку как угодно. В связи с этим подавляющее большинство web-страниц современного Интернета, созданных на базе HTML, не соответствует рекомендациям W3C и содержит ошибки. Это касается даже сайтов, выпускаемых известнейшими web-студиями. К примеру, Студия Артемия Лебедева, несмотря на непререкаемый авторитет и общеизвестность, пока начисто игнорирует рекомендации W3C.


Код главной страницы сайта www.artlebedev.ru. Ошибка в первой строке: мир никогда не узнает, какому DTD соответствует данный документ. Свою студию Лебедев чтит больше, нежели W3C


Попытаемся проверить главную страницу сайта www.artlebedev.ru как соответствующую DTD HTML 4.01 Transitional. Показан только конец отчета - онлайновый валидатор W3C находит по несколько ошибок в каждой строке (из рисунка, в частности, видно, что в 182-й строке не менее трех ошибок)


Такой текст будет показан в окне браузера Internet Explorer 5.0, когда синтаксический анализатор msxml обнаружит ошибку в коде XML-документа

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

Резюме
Перспективы развития WWW сегодня выглядят не столь туманными, как 5 - 6 лет назад, что вселяет определенный оптимизм и веру в будущее. Период неустроенности, характерный для всего нового, постепенно проходит. Будем же верить, что совсем скоро труд web-разработчиков перестанет, наконец, быть неблагодарным занятием...

Статья опубликована в журнале CHIP, № 2, 2003

 
03.03.2003
Версия для печати Версия для печати Запомнить ссылку Запомнить ссылку
Ваша оценка:  1   2   3   4   5     

 О проектеПерепечаткаАвторамПартнерыО нас пишут
Наверх
©2003—2007. GETINFO.RU. ВСЕ ПРАВА ЗАЩИЩЕНЫ.