Что нужно. Организация структуры

Что нужно. Организация структуры

4.

И ASP это выглядит примерно так же; на PHP — <?=require "header. php"?>,наJSP — <%@ include file="header. jsp" %> или <jsp: include page="/header. jsp" flush="true"/> и т. п.). Это удоб­но, потому что при изменении включенного файла изменения (для по­сетителя сайта) произойдут сразу на всех страницах сайта. Но может возникнуть ситуация, когда включаемый файл придется переместить либо (по каким-то причинам) переименовать. В этом случае нужно бу­дет переписать инструкцию включения во всех файлах (а их могут быть сотни) и снова загрузить их на сервер, что не настраивает на оптимизм.

Логичнее вообще исключить указание на рабочие моменты из смысловых файлов. Если есть возможность, то собирать страницы из конструктора лучше на стороне. Например, при использовании сер­вера Apache это можно делать при помощи файла. htaccess. В нем до­статочно написать две строчки, чтобы до и после каждого вызываемого файла в страницу включались нужные файлы. Так, чтобы перед смыс­ловым файлом обязательно включался файл header. htm, а после него footer. htm (расширения файлов могут быть любыми, т. к. все внутренние директивы будут обрабатываться только после включения в файл), со­держимое файла. htaccess должно быть таким:

Php value auto prepend file header. htm

Php value auto append file footer. htm

Естественно, сами файлы header. htm и footer. htm не обязаны лежать в корневой директории сайта (там обязан лежать только файл. htaccess. Кстати, если в дочернюю директорию положить еще один. htaccess, но с указанием других файлов, то они также будут включаться в смысловые файлы — что не отменяет действия «корневого» .htaccess).

В этом случае достигается корректное разделение формы и содер­жимого. И если особых требований к адресам страниц нет, то этот ва­риант оптимален. Во-первых, стилевое единообразие сайта достигается тремя файлами, во-вторых, в два файла можно записать все от первого тэга страницы до стандартных элементов оформления (меню, логотип, форма поиска, необходимые сведения, адрес, комментарии, дата обнов­ления сайта, e-mail, авторские права). Недостаток только один: метод недостаточно гибкий. То есть при работе мы жестко привязаны к тому количеству смысловых файлов, которые есть на сервере.

И тут на помощь приходит логика обратного включения. То есть включения, при котором не вспомогательные файлы помещаются в смысловые, а наоборот: есть один или несколько рабочих (системных) файлов, в которые передаются данные о том, что именно нужно вклю­чить в качестве смысловой части. При этом совершенно неважно, что будет анализироваться в качестве входных данных: записи из базы дан­ных или файлы. Рассмотрим основные возможности такого подхода.

Что нужно. Организация структуры

/images, и адреса архивов, хранящихся в директории /arch), то запись в файле. htaccess будет слегка модифицирована:

RewriteEngine on RewriteBase /

RewriteCond %{REQUEST URI} !A/images.* RewriteCond %{REQUEST URI} !A/arch.* RewriteRule Л(.*[Л/])$ $1/

RewriteCond %{REQUEST URI} !A/images.* RewriteCond %{REQUEST URI} !A/arch.* RewriteRule (A$|A[-/ a-zA-Z0-9]*/$) index. php? query=$1 [QSA]

В этом случае изображение, на которое будет стоять ссыл­ка Http://Domain.Ru/Images/Logotype.Jpg, будет доступно по это­му (фактическому адресу); если же адрес будет звучать как Http://Domain.Ru/Abc/Images/Logotype.Jpg, то сервер обратится к файлу Http://Domain.Ru/Index.Php и передаст ему в переменной Squery строку abc/images/logotype. jpg/ (я еще не придумал, для каких целей это мож­но использовать, но что можно, знаю точно).

Почему при обычной древовидной структуре нужно искать «до­полнительные сложности»? Во-первых, потому что легкие пути нам не нужны, а во-вторых — потому что в этом случае приобретается особая гибкость в работе с файлами и базами данных. Если говорить о фай­лах, то возможен такой подход: все файлы и вложенные директории (допустим, кроме изображений и архивов) собираются для удобства в отдельной директории (к примеру, /files), и тогда сценарию толь­ко остается включить файл, находящийся по адресу: /files/sometext/17/ (прибавить расширение файлу, убрать при необходимости завершаю­щий слэш и проверить наличие этого файла вы сможете сами). Нако­нец, теперь при адресе domain. ru/webdesign/links/2006/ (допустим, по этому адресу будут расположены ссылки на лучшие веб-дизайнерские работы за 2006 год) серверу не обязательно искать нужный файл по ад­ресу /files/webdesign/links/2006/ — дело в том, что при помощи анали­зирующего сценария можно проверять, нет ли в переменной $query заранее определенных слов, и при их наличии давать значения еще некоторым переменным. К примеру, сценарий проверяет, нет ли в пе­ременной $query подстроки webdesign/links/число, и если та­кая подстрока находится, то управление передается сценарию по адре­су /files/webdesign/links. php, которому в качестве значения переменной $year («год») передается значение «2006». А уже этот сценарий выби­рает из базы данных либо из файлов информацию о ссылках за 2006 год. Преимущество — в динамическом формировании страницы, в сокра­щении количества физически существующих файлов, в легкости преоб-

Что нужно. Организация структуры

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

Рассмотрим пару возможностей организации данных на сайте. (В скобках отмечу, что организация данных на сайте — процесс очень творческий. Если сайт не сделан раз и навсегда для вечного и неиз­менного использования, то рано или поздно часть данных нужно будет удалить, часть — переместить, немного добавить, часть переименовать. В этом случае разработчик просто вынужден делать структуру сайта ди­намической. А уже как это реализовать — зависит от вкуса, опыта, же­лания, добросовестности и наличия фантазии. И самое главное — от поставленных задач.)

Итак, возможность первая — использование БД, непосвящен­ными называемой базой данных. При упоминании этой возможности в голову приходит как минимум три способа реализации: максималь­но абстрактная единственная таблица в БД; максимально конкретные различные таблицы в одной БД; текстовые БД. Кардинальное разли­чие между первым и вторым подходом в том, что в первом случае одни и те же поля могут в разных случая соответствовать разной семантике, а в случае с несколькими таблицами в каждой таблице поля строго се­мантически ориентированы. Второй подход по смыслу похож на тре­тий, где вместо БД используются текстовые файлы, где набор значений или строк разделяется текстовыми разделителями вроде |. Базы данных очевидно удобнее использовать тогда, когда количество страниц и раз­делов постоянно увеличивается (например, это интернет-аналог газе­ты), но при этом структура уже сформирована, и добавление страницы сводится к добавлению записи в БД и отнесению ее к определенному классу (рубрика, раздел и т. п.). Текстовые файлы удобнее использовать при небольших массивах разнородной информации: в серверных язы­ках программирования достаточно средств, чтобы работать с текстовы­ми файлами как с базами данных.

При помощи БД с единственной таблицей достаточно прос­то сделать абстрактную модель, из которой данные будут выбираться сценарием в зависимости от меток. «Горизонтально» таблица делит­ся на несколько полей, из которых часть несет конкретную семантику (идентификационный номер записи, от которого никуда не денешься; заголовок записи или материала — для <Ы> и <^^е>; сам матери­ал; дата добавления записи; другие необходимые поля, например, ав­тор записи или ключевые слова; здесь же можно сделать поле, которое будет отвечать за англоязычное название страницы, запрашиваемой пользователем, хотя это необязательно), а часть — абстрактную. Учи­тывая, что глубина вложенности директорий (разделов) на сайтах ред­ко составляет число, большее пяти, создаем пять абстрактных полей от «аЬБ^1» до «аЬБ^5». В первое поле для каждого материала вносит-

Что нужно. Организация структуры

Www. altavista. ru | AltaVista | Моя первая поисковая система

C помощью нехитрого сценария разбиваем файл на строки; иг­норируем пустые строки; каждую непустую строку заносим в массив; каждый элемент массива преобразуем во вложенный массив с тремя элементами (адрес, название сайта, комментарий). Затем на выводе с помощью циклов форматируем массивы в пригодном для нас виде:

<?

$allfile = File("links. txt");

Foreach($allfile as $value)

{

If($value!=false)

{

List($lnk, $nm, $dscr) = explode("|", $value);

// Удаление из адреса фрагмента http://, который и так будет подставлен сценарием

$lnk = str replace("http://", "", $lnk);

$lnk = str replace("HTTP://", "", $lnk);

// При отсутствии названия в его роли будет адрес сайта

$nm = ($nm=="") ? $lnk : $nm;

Echo '<p><a href="http://'.$lnk.'" target=" blank"><b>'.$nm.'</b></a>'; echo '<br />'.$lnk;

Echo '<br />'.nl2br($dscr).'</p>';

}

}

?>

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

Безусловно, наибольшую логику в применении баз данных мож­но найти в создании электронных магазинов, каталогов и прочих сайтов, где в единообразном виде выводится большое количество однотипных данных, где требуется разнообразная сортировка по различным призна­кам, где понятия «запрос» и «отчет» не теряют своего первоначального смысла. В прочих случаях можно рекомендовать использовать постро­ение сайта на файлах либо «смешанную технику», когда БД и тексто-

Что нужно. Организация структуры

Люстрация и ссылки на страницы со следующей и предыдущей иллюс­трациями. На некоторых страницах под иллюстрациями должны быть комментарии, но не на всех. Поступаем творчески:

1. Собираем все иллюстрации в одну директорию.

2. Пишем файл, содержащий только ассоциативный массив, где ключами являются названия файлов иллюстраций, к которым есть комментарии (тексты комментариев — значения элементов массива).

3. Пишем сценарий, который, во-первых, «читает» директорию, со­держащую изображения, записывает их имена в массив, выстраи­вает в порядке хронологии добавления файлов в директорию (для построения навигации: ссылок на предыдущее и следующее изоб­ражения), а во-вторых, принимает входной параметр из адресной строки, и если в строке запроса находится подстрока, совпадаю­щая с именем файла какого-либо из существующих в этой папке изображений, то данное изображение выводится в браузер (перед этим с помощью сценария высчитываются его ширина и высота). Если та же подстрока является ключом какого-либо из элементов массива в файле с комментариями, то значение данного элемента выводится как комментарий к иллюстрации. Файл сценария за­нимает чуть больше одного килобайта (примерно как этот абзац). Возможен вариант: чтобы ускорить работу сценария, который, в общем-то, даже при сотне-другой файлов изображений работа­ет очень быстро, список файлов можно поместить в отдельный файл, обновляющийся вручную или сценарием, допустим, раз в сутки или при добавлении новой иллюстрации.

В итоге получается, что вместо 150 картинок со 150 файлами «аль­бома» мы имеем 150 картинок с двумя-тремя файлами «альбома». Для чего здесь понадобилась бы база данных, сложно представить. Рациона­лизаторская мысль торжествует.

В принципе, можно организовать структуру сайта так, что все данные будут в одном файле, при этом страниц на нем будет не меньше трех десятков. Другой вопрос — нужно ли это, удобно ли и стоит ли игра свеч? Гораздо чаще удобно бывает сделать так, чтобы одна страница со­биралась из трех-четырех файлов (хотя при этом число файлов на сер­вере все же меньше, чем кажется пользователю): ядерный сценарий, включаемый файл с основным содержанием страницы, файл с шабло­ном оформления раздела, стилевой файл.

Одной только структурой сайта программирование не ограничи­вается. Следующий уровень — написание локальной поисковой сис­темы. Даже если сделать структуру сайта очень логичной, все равно найдутся люди с логикой, отличной от вашей. Либо некоторые разделы

4

Программирование

По каким-то соображениям захочется запрятать поглубже и не выносить на главную страницу. Либо посетителю потребуется поискать на вашем сайте нечто, что он забыл, как называется, но на букву «щ». В любом случае, поиск по сайту — очень нужная вещь.

При разработке поисковой системы по сайту используется два подхода: поиск по заранее созданной и регулярно обновляемой базе данных и поиск «на лету».

Смысл первого подхода в том, что сценарий периодически обходит все страницы сайта и собирает информацию о них: адрес страницы, заго­ловок, ключевые слова (если указаны), статистически самые частотные слова (кроме служебных), даты создания и последнего обновления, раз­мера и т. п. Иногда вместо ключевых слов в базу заносится целый текст страницы (нередко — предварительно обработанный, т. е. без служебных слов, без мультимедийной информации, без тэгов). В процессе сбора информация заносится в таблицу базы данных или в текстовые файлы, по которым и производится поиск. Плюс такого подхода — в большой скорости поиска, а также в том, что поисковую базу можно использовать не только для собственно поиска, но и для разнообразного учета, для пре­доставления информации о страницах и проч. Минус — в недостаточной своевременности обновления поисковой базы: обычно переиндексация производится, допустим, раз в сутки, и только что опубликованную ин­формацию подчас невозможно найти через поисковую систему (с другой стороны, система управления сайтом в состоянии вызывать переиндекса - цию при любом изменении на сайте, но если такие изменения происхо­дят достаточно часто, то это не очень удобно). Далее, если в базе хранятся не копии страниц, а ключевые слова, то я не смогу найти какой-то текст, в котором я помню случайную фразу из середины.

Поиск «на лету» перебирает страницы в режиме реального вре­мени и, расценивая каждую страницу как строку, ищет в ней подстроку совпадения с поисковым запросом и в случае нахождения таковой вы­дает результат. При добавлении свежей информации на сайте она стано­вится доступной поисковой системе мгновенно (и доступна по любому слову, содержащемуся в тексте). Однако поиск, особенно при несколь­ких тысячах страниц на сайте, производится медленнее, чем при поиске по базе.

В любом случае типичные требования к поисковой системе тако­вы: учет морфологии (если человек ввел слово «девушка», то ему нужно найти и «девушек»), ранжирование результатов (ближе к началу долж­ны располагаться результаты, наиболее точно отвечающие запросу либо наиболее свежие), возможность настраивать систему поиска, указание контекста встретившихся искомых слова или фразы и наличие допол­нительной информации о странице.

С разработкой структуры сайта и поисковой системы тесно связа­на разработка системы управления содержанием сайта (CMS, от Content

268

Что нужно. Организация структуры

Management System). Каждая такая система ориентирована на опреде­ленную веб-архитектуру. Достаточно сложно создать CMS, с помощью которой можно было бы редактировать сайты, разработанные заранее по специфической схеме (особенно на основе смешанной техники БД с файлами).

Системы управления сайтом бывают двух типов: встроенные (ра­ботают как раздел сайта) и программные. Программные CMS — это целые пакеты приложений, которые необходимо устанавливать на ком­пьютер. Если работа по обновлению и поддержке сайта ведется центра­лизованно, например, с одного рабочего места, это удобно и достаточно безопасно. С другой стороны, оперативно внести изменения на сайт, если до офиса еще далеко, невозможно. В этом плюс встроенных CMS: на любом компьютере с доступом в интернет можно открыть раздел администрирования, ввести пароль и тут же обновить сайт. С другой стороны, встроенная система управления — потенциальная «дыра» в безопасности сайта. Ссылок на страницу администрирования делать не нужно ни на какой-либо другой странице; следует исключить этот раздел из области индексации поисковой системы; назвать раздел сто­ит не логичным именем (вроде /admin, /adminka, /cms, /edit, /red и т. п.), а таким, чтобы его было трудно подобрать логически (/coffecup, /arsenal, /deepforest, /717296_r и все буйство вашей фантазии).

Основные требования, предъявляемые к CMS разного типа, та­ковы: возможность создания, изменения (редактирования), переиме­нования, перемещения и удаления разделов и отдельных страниц в них; возможность подключения и отключения модулей (новостной блок, средство отправки почты без почтового сервера, поиск по сайту, фото­галереи, системы голосования, книга отзывов, форум, чат, блог, элект­ронный магазин, каталог ссылок и другие); доступ к статистике; файл- менеджер (особенно полезно для загрузки пользовательских файлов); средства форматирования текстов; выбор шаблонов оформления стра­ниц; система помощи в работе с CMS. Из дополнительных возможнос­тей стоит отметить поддержку версий страниц, возможность неполного удаления (временного скрытия) страниц и создания черновиков стра­ниц; разделы для внутреннего пользования (календарь событий, запис­ной файл); визуальное редактирование и т. п.

Написание удобной CMS, пригодной для использования в поход­ных условиях, не требующей изучения как самостоятельной програм­мы, корректно обрабатывающей ошибки пользователя, — дело слож­ное, но увлекательное. Полноценную систему обновления содержимым можно уместить в файл размером от 20 до 50 Кб.

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

4

Программирование

Требования к сайту не превышают стандартных. Условно их можно раз­делить на три группы по степени доступности использования (что не отменяет разделения на встроенные и программные).

Первая группа — это «фирменные» CMS, которые поставляются организацией (или веб-мастером) вместе с готовым сайтом для управ­ления им. Такие системы управления разрабатываются самой студией и, как следствие, максимально совместимы с теми сайтами, которые производит студия. Например, Студия Лебедева (Www.Artlebedev.Ru) поставляет со своими сайтами систему «Imprimatur II», студия «Defa» (Www.Defa.Ru) — систему управления контентом «DeFormer», сту­дия «Кубик» (Www.Kubic.Ru) — CMS «Медиабокс», студия «Атилект» (Www.Atilekt.Ru) — систему «Back Office Atilekt» («boAtilekt»), а автор этой книги (Www.Erlang.Com.Ru) разработал для создаваемых им сайтов систе­му управления «Umaster». Такие CMS не распространяются бесплатно и даже не продаются.

Вторая группа систем управления содержимым разрабатывается как раз на продажу. Это либо самостоятельные программы, либо (чаще всего) набор сложных сценариев, которые необходимо загрузить на сер­вер, запустить инсталляцию (установку как программы) и настраивать по своему вкусу. После этого с помощью заданного набора шаблонов страниц, а также формируя собственные шаблоны оформления, мож­но создавать веб-страницы, редактировать их, публиковать на сервере и совершать другие обыденные действия. В качестве примеров таких CMS можно назвать системы «InDynamic», «a-cms. net», «Amiro. CMS», «UMI CMS», «HostCMS Infinity», «ABO. CMS», «Битрикс» и множество других. Некоторые из разработчиков предоставляют бесплатные версии своих систем с очень ограниченной функциональностью (например, объем сайта ограничен десятью страницами). Стоимость коммерческих сис­тем управления сайтами в среднем колеблется в пределах от 1OOO рублей до 1OOO евро.

Третья группа — бесплатные или условно-бесплатные (бесплат­но предоставляется ограниченная функциональность, за плату — тех­ническая поддержка и неограниченные возможности использования) системы. Установочные файлы систем такого рода можно загрузить с сайтов разработчиков (и не только разработчиков) или купить на дис­ке, содержащем свободно распространяемые программы (в этом случае в цену входит только стоимость диска и записи на диск), и пользовать­ся без существенных ограничений. Одним из давних лидеров является система «Drupal», поддерживаемая разработчиками со всего мира. Пос­тоянно выходят не только новые версии этой системы, но и новые мо­дули, позволяющие расширять систему практически до бесконечнос­ти. «Drupal» является встроенной системой, написанной на языке PHP, работает на сервере Apache или функционально сходном и в качестве хранилища информации использует базу данных (MySQL, PostgreSQL

27O

Что нужно. Организация структуры

И некоторые другие), таким образом представляя собой почти универ­сальное решение, так как большинство хостинг-провайдеров предо­ставляют для размещения сайтов на виртуальном хостинге именно эти возможности. Как гласит описание системы на русскоязычном сайте, «Drupal является свободным программным обеспечением, распростра­няемым под лицензией GNU GPL. Это означает, что используя Drupal вы получаете полные исходные тексты на которых он построен и може­те вносить в них собственные изменения. Вы можете беспрепятственно использовать Drupal в коммерческих проектах, соблюдая условия ли­цензии GNU GPL, которой защищены исходные тексты Drupal» (пун­ктуация сохранена). Среди популярных систем управления стоит также отметить «eZ publish» (поддержка нескольких сайтов из одной системы управления, система триггеров — установка действий на событие или дату; 9 Мб), «Joomla» и «Mambo» (первый проект в свое время отделил­ся от второго; большое количество дополнительных модулей, удобный веб-интерфейс; 2 Мб), «PHP Nuke» (целое семейство систем с разным функционалом, огрехи в безопасности; 6 Мб), «WebGUI» (на языке Perl, принцип «все в одном»; 3,5 Мб), «Typo3» (на этой системе, к примеру, работают сайты компаний «Epson» и «Philips»; 7 Мб), «Xoops» (расши­ряемая система с поддержкой различных языков; 1,1 Мб), «Xaraya» (для сайтов средних размеров на основе XML; 3,8 Мб), «Twilight CMS» (пол­нофункциональная программная система; 7,5 Мб). Часть систем управ­ления рассчитана исключительно на создание блогов: «WordPress» (один из самых компактных при достаточной функциональности; 0,5 Мб), «MovableType» (на языке Perl; 1,9 Мб), «b2evolution» (поддержка не­скольких блогов; 2 Мб), «Textpattern» (возможность подключения мо­дулей; 300 Кб). В случае с блогами это не только CMS, но и веб-архи­тектуры, то есть так называемые «движки», правда, не универсальные. В зависимости от версий CMS размеры установочных файлов, естест­венно, варьируются; в скобках указаны размеры установочных файлов наиболее популярных версий систем на момент подготовки книги.

Наконец, особую подгруппу составляют так называемые Wiki-системы со специфическим синтаксисом оформления материалов, с многопользовательским (и иногда даже свободным) доступом к редак­тированию сайта, с поддержкой версионности страниц.

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

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

Статистика на сайте — вещь не первостепенной важности, но по­лезная. Общее количество посещений говорит о популярности ресурса. Количество уникальных посетителей (оно всегда меньше общего коли­чества посещенных страниц) нужно для того, чтобы выяснить, сколько

4

Программирование

Страниц на сайте в среднем посещает 1 человек за время визита. Же­лательно установить такую статистику не только для целого сайта, но и для всех (либо для самых важных) его страниц. В этом случае удастся, например, отследить некоторые стратегически важные моменты: вы возлагали большие надежды на посещение какого-либо раздела, а ока­зывается, что он совсем непопулярен. В этом случае, возможно, стоит сделать более заметной ссылку на этот раздел на главной странице.

Идеальная статистика учитывает: количество посетителей сайта вообще, а также в среднем (и максимум с минимумом) в минуту, в час, в день, в неделю, в месяц и в год, составляет графики изменения ди­намики посещений, считает, сколько посещает страниц пользователь в среднем, максимум и минимум за один сеанс (за одно посещение сайта в целом), на какой странице сколько времени проводит, сколь­ко щелчков мышкой производит и сколько водит по странице мышью, чем смотрит сайт (браузер, язык программного обеспечения, ОС, какое разрешение экрана, используется ли javasсriрt), фиксирует, в какой день и во сколько точно произошло, допустим, тысячное или миллионное посещение и т. п. Можно учитывать также регион, откуда сам пользо­ватель будет, а также сайт, с которого он перешел на данный. И куда он уходит. И числовую статистику: сколько пользователей пришло с поис­ковиков, сколько по ссылкам с других сайтов, а сколько людей просто набирали «www...» в адресной строке. И представить все это не только в абсолютных величинах, но и в процентных.

Безусловно, для такой подробной статистики требуется исполь­зование базы данных, тогда как для простой статистики (количество посещений) достаточно одного или двух текстовых файлов.

Статистика на сайте — это, как правило, сбор информации без ве­дома самих посетителей (он зашел, а сайт его посчитал, да еще отследил его перемещения по сайту). Но подобный сбор доступен и при участии посетителей: это различного рода голосования, когда посетитель читает вопрос, отмечает один из вариантов и нажимает кнопку «Проголосо­вать». Как правило, такой метод сбора информации дает менее объек­тивные результаты («Интернетом пользуются сто процентов населения России. Таковы результаты опроса, проведенного в интернете»), пос­кольку не каждый посетитель заметит форму для голосования, а если и заметит, то не всегда пожелает затратить усилия на нажатие кнопки, которые прямо сейчас ему ничего не дадут. Поэтому нужно продумать, что сделать, чтобы кнопка была нажата хотя бы несколькими процен­тами посетителей: что-то пообещать полезное (и не обмануть ожида­ний), сделать так, чтобы страница не перезагружалась при голосовании (посетитель не любит просто так расходовать трафик), оформить опрос необычно.

Наконец, программисту очень важно решить вопрос безопаснос­ти работы сайта.

272