Разработка структуры вэб-представительства

Различия между браузерами проявляются прежде всего в наборах обрабатываемых тегов – команд HTML. Существует набор тегов, стандартизированный консорциумом WWW (W3) – организацией, контролирующей развитие Всемирной Паутины. Разработчики программного обеспечения в принципе должны следовать рекомендациям и стандартам консорциума – это необходимо для поддержания преемственности и совместимости прогр

амм и систем разных поколений. Но не всем удается точно выполнить все, что требует стандарт. Некоторые наоборот, стремятся внести в HTML что-либо свое – новые теги, параметры, функции. Иногда такие нововведения принимаются другими производителями и становятся стандартом, иногда они остаются свойствами конкретной программы. Такие различия приводят к тому, что возможности браузеров даже в воспроизведении стандартных тегов могут значительно различаться. Это создает большие проблемы для дизайнеров и web-программистов – им приходится при разработке страницы учитывать возможности и характеристики всех браузеров, которые могут оказаться у потенциального пользователя. Так как учесть все существующие программы невозможно, я ориентировался на самые распространённые браузеры: Microsoft Internet Explorer 6.0, поставляемый с операционной системой Windows XP, Microsoft Internet Explorer 7.0, поставляемый c операционной системой Windows Vista (возможна установка на Windows XP) и на Mozilla Firefox v2.1, Opera и Google Chrome.

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

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

Потребности администраторов – это как можно более комфортная, быстрая и безопасная работа с базой данных.

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

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

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

1.1.4 Выводы

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

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

2. Необходимо спланировать архитектуру веб-приложения.

3. Требуется принять дизайнерские решения.

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

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

6. При этом не забывать постоянно проверять работу сайта в разных браузерах и при различных разрешениях монитора.

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

8. Создать редакторы для изменения, удаления и сохранения новых записей. Учесть, что многие записи взаимосвязаны и имеют определённые ограничения.

9. Тестировать работу административной подсистемы и сайта.

9. Запустить сайт в работу.

1.2 Конструкторская часть

1.2.1 Структура входных и выходных данных

Работа с сайтом осуществляется по ставшему стандартом для Internet протоколу HTTP.

HTTP (HyperText Transfer Protocol – протокол передачи гипертекста) был разработан как основа World Wide Web.

Работа по протоколу HTTP происходит следующим образом: программа-клиент устанавливает TCP-соединение с сервером (стандартный номер порта-80) и выдает ему HTTP-запрос. Сервер обрабатывает этот запрос и выдает HTTP-ответ клиенту.

Структура HTTP-запроса

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

Заголовок запроса состоит из главной (первой) строки запроса и последующих строк, уточняющих запрос в главной строке. Последующие строки также могут отсутствовать.

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

Метод (иначе говоря, команда HTTP):

GET – запрос документа. Наиболее часто употребляемый метод; в HTTP/0.9, говорят, он был единственным.

HEAD – запрос заголовка документа. Отличается от GET тем, что выдается только заголовок запроса с информацией о документе. Сам документ не выдается.

POST – этот метод применяется для передачи данных CGI-скриптам. Сами данные следуют в последующих строках запроса в виде параметров.

PUT – разместить документ на сервере. Насколько я знаю, используется редко. Запрос с этим методом имеет тело, в котором передается сам документ.

Ресурс – это путь к определенному файлу на сервере, который клиент хочет получить (или разместить – для метода PUT). Если ресурс – просто какой-либо файл для считывания, сервер должен по этому запросу выдать его в теле ответа. Если же это путь к какому-либо CGI-скрипту, то сервер запускает скрипт и возвращает результат его выполнения. Кстати, благодаря такой унификации ресурсов для клиента практически безразлично, что он представляет собой на сервере.

Версия протокола – версия протокола HTTP, с которой работает клиентская программа.

Таким образом, простейший HTTP-запрос может выглядеть следующим образом:

GET / HTTP/1.0

Здесь запрашивается корневой файл из корневой директории web-сервера.

Строки после главной строки запроса имеют следующий формат:

Параметр: значениe.

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

Перечислю некоторые наиболее употребительные параметры HTTP-запроса:

Connection (соединение) – может принимать значения Keep-Alive и close. Keep-Alive («оставить в живых») означает, что после выдачи данного документа соединение с сервером не разрывается, и можно выдавать еще запросы. Большинство браузеров работают именно в режиме Keep-Alive, так как он позволяет за одно соединение с сервером «скачать» html-страницу и рисунки к ней. Будучи однажды установленным, режим Keep-Alive сохраняется до первой ошибки или до явного указания в очередном запросе Connection: close.

close («закрыть») – соединение закрывается после ответа на данный запрос.

User-Agent – значением является «кодовое обозначение» браузера, например:

Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)

Accept – список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером, например для моего IE5:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

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

 Скачать реферат