Vrml-файл представляет собой обычный текстовый файл, интерпретируемый браузером. Поскольку большинство браузеров не имеет встроенных средств поддержки vrml, для просмотра Vrml-документов необходимо подключить вспомогательную программу - Vrml-браузер, например, Live3D или Cosmo Player.
Как и в случае с HTML, один и тот же vrml-документ может выглядеть по-разному в разных VRML-браузерах. Кроме того, многие разработчики VRML-браузеров добавляют нестандартные расширения VRML в свой браузер.
Существует немало VRML-редакторов, делающих удобней и быстрее процесс создания Vrml-документов, однако несложные модели, рассматриваемые в данной статье, можно создать при помощи самого простого текстового редактора.
Языки программирования серверов
С помощью сценариев для сервера можно получить доступ к файлам, базам данных и другим ресурсам, хранимым на сервере, а также к централизованным ресурсам сервера, таким как электронная почта или факс-служба.
Функционирование в непротиворечивой и управляемой среде - еще одно преимущество выполнения сценариев на сервере. Ваш код выполняется только на одной версии единственного сервера, а не на множестве версий множества броузеров.
Однако и для использования сценариев на стороне сервера имеется три основных препятствия.
• Запуск скриптов на сервере зачастую требует получения специальных прав от Web-мастера или системного администратора.
• Для взаимодействия со сценариями, выполняющимися на сервере, пользователь должен щелкнуть мышкой на ссылке или на кнопке на странице, а затем ожидать, когда сервер выполнит сценарий и перешлет ответ. Взаимодействие с использованием динамического HTMLпроисходит быстрее.
• Для тестирования сценариев для сервера требуется иметь собственный WWW-сервер, предпочтительно того же типа, что и промышленный вариант.
Программирование на стороне сервера в настоящее время является необходимым условием для решения широкого спектра задач. Оно позволяет:
a) получать и обрабатывать на сервере данные, введенные пользователем при помощи формы;
b) динамически создавать web-документы, не зависящие ни от платформы, ни от браузера клиента;
c) обеспечивать динамический доступ к данным, находящимся на сервере, в частности, к серверным базам данных (при таком способе доступа HTML-документ автоматически изменится, как только изменятся хранящиеся на сервере данные);
d) использовать серверные компоненты, предназначенные для решения типовых задач (таких, например, как циклическая смена рекламных баннеров и др.);
e) осуществлять аутентификацию пользователя;
f) получать информацию о браузере клиента;
g) создавать и читать ключики на стороне клиента;
CGI: Технология «клиент-сервер»
Большое количество World Wide Web приложений основано на использовании внешних программ, управляемых Web сервером. Использование данных программ позволяет строить Web приложения с динамически обновляемой информацией, хранящейся в базах данных или генерирующейся в зависимости от бизнес-правил решаемых задач. Для связи между Web сервером и вызываемыми программами широко используется Common Gateway Interface (CGI), имеющий реализации как для Windows-ориентированных программ, так и для приложений, функционирующих в среде Unix.
CGI - Common Gateway Interface является стандартом интерфейса (связи) внешней прикладной программы с информационным сервером типа HTTP, Web сервер.
Обычно гипертекстовые документы, извлекаемые из WWW серверов, содержат статические данные. С помощью CGI можно создавать CGI-программы, называемые шлюзами, которые во взаимодействии с такими прикладными системами, как система управления базой данных, электронная таблица, деловая графика и др., смогут выдать на экран пользователя динамическую информацию.
Т.о., программа-шлюз запускается WWW сервером в реальном масштабе времени. WWW сервер обеспечивает передачу запроса пользователя шлюзу, а она в свою очередь, используя средства прикладной системы, возвращает результат обработки запроса на экран пользователя. Программа-шлюз может быть закодирована на языках C/C++, Fortran, Perl, TCL, Unix Schell, Visual Basic, Apple Script. Как выполнимый модуль, она обычно записывается в поддиректорий с именем cgi-bin WWW сервера.
Интернет вообще и WWW в частности работает по технологии «клиент-сервер», то есть все программное обеспечение разделяется на клиентскую и на серверную части. Также между ними разделены и функциональные обязанности. Важным для понимания моментом является то, что клиент не знает и не обязан знать принципы работы и реализацию внутренних алгоритмов сервера, а сервер не вмешивается в дела клиента. Для взаимодействия этих частей разработан специальный протокол (в частном случае — протокол HTTP), и все взаимодействие между клиентом и сервером осуществляется исключительно в рамках данного протокола. Вашему броузеру все равно, какое программное обеспечение стоит на сервере, какая там операционная система, где физически лежат запрашиваемые документы на сервере (и лежат ли вообще, ведь они могут и генерироваться на лету специальными программами). Сервер тоже не вмешивается в дела вашего броузера, серверу абсолютно все равно, что сделает клиент с переданной информацией, как он ее будет отображать, сохранит на диске или проигнорирует — серверу до этого дела нет. Взаимодействие клиента и сервера происходит по принципу «запрос-ответ». Клиент посылает запрос, сервер обрабатывает его и посылает ответ (рис. 1.1-1):
1. Формирование запроса клиентом. (Броузер формирует запрос из URL, набранного пользователем, из щелчка на ссылке либо из данных формы.)
2. Установка соединения с сервером. (Если установить соединение не удается, то на этом HTTP-транзакция закончится и клиент выдаст пользователю сообщение об ошибке.)
3. Посылка запроса и ожидание ответа от сервера. (Все, что требуется от клиента, это чтобы запрос был в корректном формате.)
4. Сервер принимает запрос. (Об этом и следующем этапе клиенту ничего не известно.)
5. Сервер обрабатывает запрос.
6. Генерация ответа.
7. Прием ответа клиентом.
8. Разрыв соединения.
9. Обработка данных клиентом. (Вывод или сохранение данных.)
Обычно под запросом к серверу понимается URL (это унифицированная форма «заказа» данных на сервере). К собственно URL могут еще «прилагаться» некоторые данные, чаще всего это данные форм (вспомните, как вы вводите ключевое слово в поисковике). Формирование HTTP-запроса будет детально рассмотрено в одном из следующих уроков.
При установке соединения с сервером сначала происходит трансляция символьного доменного имени, такого, как www.siemens.com, в IP-адрес, а затем осуществляется непосредственно создание TCP/IP-соединения с данным IP. Когда данные HTTP-запроса посланы серверу, клиент просто ожидает, пока не придет ответ.
Пока нет обращений от клиентов, сам HTTP-сервер просто «спит» в ожидании запросов. Когда клиент устанавливает соединение, сервер «просыпается» и, приняв данные запроса, приступает к их обработке. Что именно сервер делает с запросом — известно только самому серверу. Единственный результат всех хитрых манипуляций — это выдача ответа, которого и ожидает клиент.
После того как сервер выдал ответ, он разрывает соединение и вновь «погружается в сон». Естественно отметить, что в случае возникновения ошибки HTTP-транзакция может закончиться на любом из этих этапов.
Все девять этапов HTTP-соединения показаны на рис. 1.2.
Если документ не найден или если для доступа к нему у вас нет прав (доступ к ресурсу может быть ограничен), то выдается код ошибки. А если все нормально, то информация, содержащаяся в документе, включая сопутствующие данные о его типе, выдается в виде ответа.
Схема взаимодействия «клиент-сервер» для случая, когда URL указывает на CGI-обработчик, показана на рис. 1.3.
Технология SSI
SSI (Server Side Includes, включения на стороне сервера) - это директивы, вставляемые в HTML-код и служащие для передачи указаний серверу.
SSI позволяют "вставлять" фрагменты одних документов в другие. Конечно, это можно сделать непосредственно в текстовом редакторе, но если, например, в несколько документов вставляется один и тот же фрагмент, к тому же часто изменяемый, использовать SSI-вставки много удобнее.
Сервер интерпретирует SSI-директивы и выполняет соответствующие действия. Использование SSI-вставок позволяет динамически формировать странички в зависимости от различных параметров(например, типа браузера).
Преимущества SSI проявляются тем сильнее, чем больше по объему сайт, имеющий повторяющиеся элементы кода на разных страничках.
Для того, чтобы сервер знал, что страничка не обычная, а содержит SSI-директивы, используется специальное расширение: shtml или shtm. (Вообще-то, конфигурация сервера может быть настроена и на другое расширение, но shtml воспринимается всегда (если только на сервере не отключено применение SSI вообще).
Для того, чтобы указать серверу, какой блок нужно вставить и в каком месте странички, используется специальная форма записи в виде комментария:
<!--#команда параметр="значение" --> |
При просмотре сформированного исходника HTML-файла пользователь не увидит никаких признаков SSI, т.к. браузер получает уже готовый HTML-код.
Первое преимущество SSI с точки зрения дизайнера заключается в том, что при таком подходе web-мастеру, занимающимуся поддержкой сайта, можно не бояться случайно испортить дизайн. Элементы сложной верстки скрыты за счет использования SSI, и поддержка содержимого страничек становится гораздо более легким и приятным делом. Второе, не менее важное преимущество, - это возможность мгновенной замены дизайна сайта, не требующая переделывания страничек. Для смены дизайна достаточно переписать SSI-вставки, формирующие внешний вид сайта.