В этой статье вы узнаете как получить для вашего сайта короткое имя.
Если у вас есть домен вида: мой_сайт.ru то эта статья не для вас.Она предназначается тем не счастливым людям которые до сих пор пользуються именами вида: халявный.хостинг.далеко.в.зимбабве.com/host/~vasya/pupkin.html. Для этих юзверей и существуют службы редиректа.Принцип работы редиректа прост: потенциальный клиент набирает в строке браузера имя сайта например - pupkin.host.ru, дальше робот службы перенаправляет клиента на наш горе-сайт с именем: халявный.хостинг.далеко.в.зимбабве.com/host/~vasya/pupkin.html.
Таких служб во всеми любимой всемирной паутине очень много.А вот и список служб (далеко не полный):
Новая и очень хорошая служба редиректа. Вам дают ваше_имя.vir.ru. Самое главное отличие этой системы от других, что за такую услугу не вставляеться никакой рекламы! В строке браузера постоянно остаётся ваше_имя.vir.ru
ваше_имя.da.ru. Одна из первых служб, Такого рода. Поэтому самые популярные имена вероятно уже заняты. Хотя попробовать стоит. Внизу страницы будет небольшой фрейм.
Хотел я продолжить беседу о JavaScript, да вовремя одумался. Прежде чем повести серьёзный разговор о программировании поведения элементов интерфейса, стоит рассмотреть ещё один очень важный вид этих элементов, а именно -- формы.Что такое формы?
Против ожидания, речь пойдёт не о нежных профилях и манящих изгибах. ;-) Пользуясь казарменным языком, можно сказать, что формы -- элементы интерфейса веб-страниц, позволяющие пользователю осуществлять ввод данных. После чего мы можем развлекаться уже по полной программе: обрабатывать эти данные при помощи JavaScript, чтобы менять страницу «на лету», или генерировать новую страницу, содержащую или учитывающую результаты ввода; можно (что чаще всего и делается) передавать информацию серверу, который поступит с ней так, как мы пожелаем.
Все эти кнопочки, списки, текстовые поля и прочая дребедень, с которой мы ежедневно сталкиваемся в гостевых книгах, чатах, форумах, и есть формы. Точнее -- ЭЛЕМЕНТЫ ФОРМ, так как сами формы, как мы в этом скоро сможем убедиться, являются просто-напросто контейнерами для элементов, а потому невидимы.
Свойства форм
В самом общем виде контейнер FORM записывается так:
<FORM name ="имя_формы" target="имя_окна" action="URL" method="GET или POST" enctype="тип_кодировки_данных" OnSubmit="обработчик"> ... элементы управления ... </FORM>
А теперь поговорим подробнее о каждом параметре.
1. Параметр name задаёт имя формы. Если вы не будете его использовать, то и писать его не обязательно. Нужен он только в том случае, если вы собираетесь впоследствии сылаться на форму из сценария JavaScript, да и то, строго говоря, не обязателен.
2. Параметр target полностью соответствует аналогичному для тега <A> (ссылка). Если ответ сервера (результат обработки формы) должен отобразиться в специально выбранном для этой цели окне, присвойте этому параметру имя окна или одно из значений по умолчанию (_blank, _top и т. д.). В случае, если ответ должен отображаться в том же окне, в котором находится форма, параметр не обязателен.
3. Параметр action значительно более важен. Он содержит адрес (URL) серверного расширения, которое будет обрабатываеть данные, содаржащиеся в форме. Если данные из формы обрабатываются локально и не передаются серверу, этот параметр тоже можно не указывать.
4. Параметр method определяет метод передачи данных серверу. Он может принимать одно из двух значений: GET и POST. При локальной обработке данных не нужен. Да и при удалённой иногда опускается. ;-)
5. Параметр enctype используется нечасто. Для информации: он определяет тип MIME передаваемых данных. При локальной обработке формы не задаётся.
6. Параметр OnSubmit задаёт имя обработчика события Submit, самого главного в жизни любой формы. Когда вы в чате или гостевой книге после ввода текста нажимаете на Enter или на специальную кнопку («Отправить», «Послать» или ещё что-нибудь в этом духе), происходит событие Submit, то есть данные из формы передаются соответствующей программе для обработки. Как правило, этот параметр опускается, т. к. одним из типовых элементов формы является специальная кнопка, нажатие на которую инициирует событие Submit без использования дополнительного кода. Если же вы обрабатываете данные локально, например, проверяете правильность заполнения полей формы перед передачей её серверному приложению, или вовсе не отправляете ничего на сервер, имя обработчика не задаётся.
Как вы поняли, из приведённых параметров опустить можно почти все, а при локальном использовании формы -- абсолютно все. В этом случае контейнер будет выглядеть следующим образом:
<FORM> ... элементы управления ... </FORM>
Скажу больше: и сам тег FORM не обязателен, можно было бы использовать элементы управления напрямую, безо всякого контейнера, но... не тут-то было. Как только на арену выходит Netscape, чтоб он был здоров, ни о какой свободе действий не приходится и мечтать: этот браузер просто не отобразит на странице ни один элемент, если он не заключён в контейнер FORM. Вот так-то.
Тем не менее, самый распространённый вариант использования контейнера выглядит примерно так:
<FORM action="http://host.com/cgi-bin/script.pl" method="POST"> ... элементы управления ... </FORM>
Это означает, что по событию Submit содержащиеся в форме данные будут переданы серверному скрипту script.pl, написанному на языке Perl.
Виды элементов форм
Мы неоднократно упоминали элементы форм: давайте теперь рассмотрим их виды.
1. Button. Видел я этот баттон... кнопка-кнопкой! ;-) Выглядит вот так:
В зависимости для того, какую функцию должна выполнять кнопка, параметр type может принимать три разных значения. Если type="submit", кнопка предназначена для передачи данных обработчику события, по умолчанию -- серверному скрипту, путь к которому определён полем action формы, содержащей элемент. Напоминаю, что такое поведение не нужно специально программировать, оно «встроено» в свойства кнопки типа submit. Если type="reset", после нажатия такой кнопки все элементы формы будут возвращены в исходное состояние, текстовые поля опустошены и т. д. Этот тип поведения тоже не нужно программировать, достаточно использовать для определения типа ключевое словов reset. Последний вариант -- type="button" -- означает, что после нажатия кнопки ничего не произойдёт, и любую желаемую реакцию интерфейса придётся программировать.
Ключевое слово checked, использованное в коде, соответствует второму переключателю, делая его включенным по умолчанию на момент загрузки страницы.
3. Radiobutton. Ещё один переключатель. Особено часто используется тогда, когда нужно организовать возможность выбора из нескольких вариантов. Примерно так:
Ключевое слово checked в этом случае использовано в описании первой кнопки. Заметим, что для связывания кнопок в группу, внутри которой нажатой может быть только одна кнопка из нескольких (при включении другой предыдущая автоматически выключается) достаточно дать всем нужным кнопкам одно и то же имя.
4. Listbox. Список. Также даёт пользователю возможность выбора, но может иметь два вида, первый из которых помогает экономить место на веб-странице, и несколько богаче возможностями.
Принципиально обе разновидности отличаются только наличием параметра size, присваивание которому значения > 1 сразу меняет внешний вид элемента. Код будет выглядеть так:
Использование ключевого слова multiple, обозначающее возможность выбора нескольких пунктов одновременно (например, с использованием клавиш Shift или Control), относится только ко второму виду списков, т. к. для первого осуществить такой выбор просто невозможно.
Скроллер появляется автоматически в случае необходимости.
5. Text. Однострочное текстовое поле. Используется для ввода простейшей информации: имена, адреса и пр. Выглядит так:
А вот и код:
<FORM> <input type="text" name="имя_поля" value="Начальное значение поля" size="30" maxlength="255"> </FORM>
Параметр value задаёт исходный текст, параметр size -- размер поля в символах, а maxlength определяет, какое максимальное количество символов это поле может содержать.
6. Textarea. Многострочное текстовое поле. Отличий от предыдущего элемента не так уж много:
Код будет таким:
<FORM> <textarea name="имя" cols="30" rows="2" wrap="off"> Ещё текст, но строк может быть несколько. </textarea> </FORM>
Параметры rows и cols определяют видимый размер многострочного поля редактирования, а wrap задаёт способ свёртки текста, принимая одно из следущих значений: off (строки отображаются так, как вводятся), virtual (свёртка включена, но новые строки не формируются) и physical (при свёртке в текст вставляется символ перевода строки).
7. Password. Поле для ввода пароля. Ничем не отличается от однострочного текстового поля (кроме типа, разумеется: type="password"), но все вводимые символы отображаются звёздочками, сохраняя истинное значение для обработчика. Выглядит так:
8. Hidden. Скрытое поле. Самое загадочное. Не выглядит, разумеется, никак, а пишется вот так:
Зачем оно нужно? Когда данные из формы передаются серверу, каждый элемент представляется в виде пары имя / значение (name / value). Скрытое поле, которое пользователь не видит, может тем не менее содержать информацию, необходимую серверному скрипту для нормальной работы.
Немного о событиях
Уже несколько раз в тексте урока встретился термин ОБРАБОТЧИК СОБЫТИЯ. Что же это за великое событие, которое приходится всё время обрабатывать?
Нынешние программы ленивы. В отличие от тех простеньких задачек на бейсике, которые вам приходилось решать в школе, они оператора не исполнят без хорошего пинка.
Когда вы писали программу на бейсике и хотели, чтобы она реагировала на нажатие клавиш, иногда приходилось закручивать бесконечный цикл, условием выхода из которого было как раз это самое нажатие: что-то сделав, программа возвращалась к циклу и снова ждала.
Теперь всё работает значительно интереснее: в программировании чаще всего используется схема объект-событие-обработчик, при котором код начинает выполняться только в том случае, если с каким-то ОБЪЕКТОМ произошло то или иное СОБЫТИЕ. Объекты бывают разные. В нашем случае в роли объекта обычно выступает ссылка (<A>), а точнее -- элемент веб-страницы, который ею помечен, или какой-то из компонентов форм.
События тоже бывают разные. Щёлкнули по кнопке -- с ней случился onclick. Курсором мыши провели над ссылкой -- она испытала mouseover. Увели мышь за пределы ссылки -- произошёл mouseout. События могут инициироваться пользователем или задаваться программно, но нас с вами по большей части будет интересовать первый вариант.
Если с объектом происходит событие, запускается обработчик этого события: кусочек кода, например -- подпрограмма-функция. Если, конечно, это событие предусмотрено и обработчик существует. Если нет -- грустить интерфейсу и дальше.
Ссылка на обработчик события вставляется в описание элемента точно так же, как любой друго его параметр. Скажите, в чём разница между target="_blank" и onmouseover="DoSomething()"? Да нет её.
Ссылку на JavaScript-код можно сделать несколькими способами. Самый простой из них выглядит так: в описание элемента мы вставляем строчку наподобие onmouseover="DoSomething()", и это означает, что в том случае, если с нашим элементом случится событие onmouseover, т. е. по нему тихо поползёт курсор, будет запущена подпрограмма-обработчик этого события, которая хранится где-то в блоке заголовка страницы в контейнере <SCRIPT> и которая выполнит всё, что мы заранее договорились сделать на случай этого самого разнесчастного mouseover'а.
Всё понятно?
Заключение
Отвечаю на вопрос, который мне задал ещё в процессе написания урока один настырный молодой человек, имеющий доступ прямо к черновикам: нет, порядок перечисления параметров форм и их элементов значения не имеет. ;-)
Любая человеческая деятельность подразумевает приверженность определенным стереотипам поведения в конкретных ситуациях. Процесс планирования и разработки Интернет-проекта не является исключением из правил и сопряжен с использованием ряда функциональных возможностей, в некотором роде ставших стандартными практически для любого веб-сайта. Карта сайта - один из наиболее красноречивых тому примеров.
Вопросы целесообразности
Прежде всего, дадим формулировку понятию "карта сайта". Карта сайта - это функциональный компонент Интернет-проекта, предназначенный для четкой логической структуризации содержания веб-сайта. Другими словами, с помощью карты сайта можно значительно облегчить труд посетителя по исследованию составных документов Интернет-проекта. Возможно, вы спросите: "А как же навигационная система? Ведь именно она создается в качестве некоего путеводителя по разделам сайта?" Безусловно, роль системы навигации сложно переоценить: не будь на сайте интуитивно понятной и удобной навигации, пользователь вовсе не стал бы находиться на таком ресурсе и более того - сформировал бы в своем сознании стойкий негативный имидж проекта.
Отсюда следует первое важное заключение, многократно подтвержденное практикой: "Наличие карты сайта - следствие многоуровневой системы навигации". Поэтому в данном случае целесообразность разработки карты сайта зависит именно от того, насколько сложной структурой обладает система навигации.
Многоуровневая навигация
Мы нередко встречаем веб-сайты, использующие двух-, трех- и более уровневую вложенность навигационного меню. В большинстве случаев такой подход продиктован большим объемом информации, который необходимо донести до потенциального клиента или пользователя - причем, в простой и понятной форме. Один из вариантов - разбить конкретный информационный раздел на несколько частей, присвоив им соответствующие наименования и смысловую направленность. Это второй уровень навигации. Теперь попробуем усложнить ситуацию. Допустим, у нас есть раздел "Контакты", который включает в себя еще три подраздела: "Телефоны", "Карта проезда" и "Обратная связь". Последний, в свою очередь, содержит ссылки на почтовую форму, форум и ICQ-аккаунт менеджера-консультанта. Таким образом, получается третий уровень навигации. В ряде случаев вложенность может быть гораздо больше (например, в описании товаров и/или услуг: "Товары > Программное обеспечение > Freeware > Интернет-приложения > Почта" и т.п.), что приводит к добавлению дополнительных пунктов навигационного меню.
Все это уводит посетителя с начальной точки путешествия по сайту: уже через пару минут он может попросту "заблудиться" в закоулках Интернет-ресурса. Во избежание подобной ситуации на сайте в обязательном порядке должны присутствовать следующие вспомогательные функциональные возможности:
Навигационная "крошка"
Присутствие в верхней части окна браузера (в видимой посетителю части экрана) гипертекстовой навигационной строки, например:
Данный пример показывает, что посетитель находится в подразделе "Почта", но в любой момент может воспользоваться соответствующей ссылкой (на примере выделены подчеркиванием) и перейти на нужный ему уровень навигации родительского раздела (которым в нашем случае будет являться "Товары").
Дублирование верхних уровней меню и остальных разделов первого уровня
Совмещение навигационной "крошки" (возможности быстро перемещаться между уровнями навигации родительского раздела) и остальных пунктов навигационного меню первого уровня, например:
ДРУГИЕ РАЗДЕЛЫ:Услуги :: Прайс-лист :: Заказ online :: Помощь :: Контакты
Запутанная навигация
Второе (не менее важное) заключение можно сделать с помощью следующего примера. Существует некий абстрактный сайт, который содержит три раздела: "Товары", "Услуги" и "Заказ online". При определенных обстоятельствах вспомогательные подразделы, входящие в состав названных разделов первого уровня, могут пересекаться и более того - дублировать друг друга:
Раздел "Товары":
Раздел "Услуги":
Раздел "Заказ online":
» Общая информация » Каталог товаров » Прайс-лист » Бланк заказа
» Общая информация » Каталог услуг » Прайс-лист » Бланк заказа
» Каталог товаров и услуг » Корзина » Оформление заказа
При таком построении системы навигации посетитель может запутаться в предназначении тех или иных пунктов меню, схожих по смыслу, но логически относящихся к разным разделам первого уровня. Подобная запутанная структура меню, конечно, не делает чести разработчикам, однако, надо признать, что в ряде случаев такое пересечение может быть вызвано различными соображениями или требованиями, обсуждение которых находится за пределами компетенции исполнителя Интернет-проекта (например, пожелание заказчика, требование инвестора и пр.).
Отсюда можно сделать второе важное заключение относительно целесообразности присутствия карты сайта: "Наличие карты сайта - следствие запутанной системы навигации".
Обобщая сказанное выше, можно сделать следующий вывод: присутствие карты сайта может быть обусловлено двумя характерными особенностями структуры навигационного меню: многоуровневым строением и дублирующимися (пересекающимися) пунктами меню смежных разделов. В иных ситуациях карта сайта абсолютно не нужна и только отвлекает внимание посетителя, который ищет в разделе "Карта сайта" дополнительную функциональность.
Приведем простой практический пример, иллюстрирующий данное утверждение. Навигационное меню официального веб-сайта петербургской строительной компании "Экострой" содержит следующие разделы (в скобках указаны разделы второго уровня): "Услуги" ("Поставка комплектующих", "Экспертиза проекта", "Разработка проекта", "Строительно-монтажные работы", "Шеф-монтаж", "Оформить заявку"), "Фасады" ("Общая информация", "Вентилируемые фасады", "Мокрые" фасады"), "Мансарды", "Строительный магазин", "Полезная информация" ("Теплофизика", "Разное", "Интернет-ссылки"), "Вопросы и ответы". Как видно, структура меню достаточно простая, пересекающихся пунктов меню нет, уровень вложенности минимальный. Помимо этого, навигация построена по технологии Dynamic HTML и представляет собой открывающиеся перечни ссылок при наведении курсора на раздел первого уровня. Также предусмотрено постоянное присутствие навигационной "крошки". Все это позволяет посетителю быстро перемещаться по всем пунктам меню из любой точки сайта. Однако, несмотря на высокую функциональность и гибкость навигационного меню, на сайте есть раздел "Карта сайта", содержание которого на 95% повторяет совокупность пунктов меню всех вместе взятых разделов, доступных пользователю без перезагрузки страниц проекта (оставшиеся 5% частично компенсируют недостаточность карты сайта некими дополнениями отдельно взятых разделов). В целом, реализация карты сайта выполнена на чрезвычайно низком уровне и не может удовлетворять потребности посетителей в функциональности (согласно статистике сервера, "Карта сайта" входит в тройку наиболее посещаемых разделов).
В заключении хочется добавить, что утверждение о двух исключительных ситуациях, когда необходима карта сайта, разумеется, не претендует на статус аксиомы, не требующей доказательства: это мое личное мнение, сформированное практическим опытом, посему любой желающий вправе
Рано или поздно каждому веб-мастеру приходит в голову идея улучшить свой сайт. И хорошо еще, если эти изменения касаются только "косметики" - изменения цвета, текста, добавления картинки или еще одной странички. Но значительно чаще хочется добавить какую-то новую функциональность - счетчик, настройку "под пользователя" или еще что-то подобное. И тут, увы, вполне может оказаться, что хостер не поддерживает требуемые функции. Поэтому сегодня мы попробуем обсудить различные технологии, применяемые в веб-сайтах и понять для чего они могут потребоваться.
Самый простой вид сайта - это набор статичных HTML страниц. Его поддерживают все хостеры и каких-либо сложностей при работе с таким сайтом не наблюдается. Единственное, на что стоит обратить внимание - это на то, в какой кодировке выкладываются страницы, чаще всего это будет KOI8-R или 1251. Если вы создаете страницы на своей домашней Windows-машине, а хостер требует их выкладывать в KOI8-R, то не забудьте их перекодировать, иначе ваши посетители увидят непонятные кракозябли, вместо тщательно вами подготовленного рассказа о коте Мурзике.
Через некоторое время возникает идея, например, убрать меню с окна браузера при открытии страницы, вывести текущее время или сделать еще что-нибудь похожее. Для подобных "невинных шалостей" вам понадобится скриптовый язык типа JavaScript или VBScript. Скрипты, написанные на этих языках никак не связаны с хостингом - они выполняются на компьютере клиента и единственная проблема с которой вы можете столкнуться - это посетитель со старым браузером, не поддерживающим скрипты. Или же неправильно с ними работающим...
Кстати, в эту же категорию можно отнести и флаш-анимацию: она тоже от хостера не зависит, так что если вы чувствуете в себе таланты аниматора, то можете начинать создавать свои мультфильмы, не боясь, что гадкий хостер будет драть с вас три шкуры за их распространение...
После того, как сайт несколько разовьется и обрастет относительно большой кучей страниц, вы обнаружите, что многие части страниц (например, "шапка" с логотипом) выглядят одинаково. И если вдруг вам захочется поменять что-то в "шапке", то это потребует переписывания всех страниц, что неудобно. Можно, конечно, попытаться задействовать фреймы, но очень быстро выяснится, что при изменении разрешения экрана (или размера окна браузера) у ваших посетителей все начинает "ехать", появляется полоса прокрутки и вообще все смотрится совсем не так, как задумывалось.
Тут вам на помощь придет SSI (Server Side Include) - специальные указания серверу, что в таком-то месте страницы он должен вставить другой файл. Теперь вы можете создать один файл с "шапкой", а во всех страницах просто указать, что "сюда надо вставить такой-то файл" и как только вы обновите "шапку" эти изменения сразу же станут видны на всех страницах. Не все хостеры поддерживают SSI - дело в том, что эта функция дает дополнительную нагрузку на сервер (ему приходится читать и анализировать все запрашиваемые страницы), кроме того там могут быть и другие ограничения: хостер может поддерживать SSI только для каких-то определенных расширений файлов (чаще всего .shtml), может разрешать или запрещать вложенный include (когда подключаемый файл тоже должен подключить какой-то другой файл) и т.п. Все это надо узнавать у хостера перед тем, как готовить сайт с использованием SSI. Кстати, SSI не ограничивается только включением каких-то файлов - возможности этой технологии несколько шире, но include является, пожалуй, наиболее важной и часто используемой директивой.
Но, как известно, нет предела совершенству, и довольно скоро вы выясните, что простого включения файлов в статичные страницы вам уже не хватает. Хочется сделать так, чтобы пользователи регистрировались на сервере, хочется добавить поиск, форумы, дать пользователю возможность выбирать нужные данные... Все это потребует скриптов. Но кардинальное отличие этих скриптов от, например, JavaScript заключается в том, что выполняться они должны на сервере, а не на компьютере клиента. Такие скрипты называются CGI (Common Gateway Interface) и могут писаться на разных языках (самыми популярными являются PHP и Perl). Поддержка скриптов, ограничения по их использованию и допустимые языки программирования полностью зависят от хостера. На бесплатном хостинге скрипты чаще всего запрещены полностью, а на платном обычно есть ограничения по суммарному времени выполнения скриптов и по загрузке процессора. Кроме того, многие хостеры не разрешают вам выкладывать свои скрипты напрямую, а требуют, чтобы сначала вы их переслали в администратору сервера для проверки.
CGI-скрипты по сути являются ничем иным как программами, которые что-то там делают на сервере, а потом выводят HTML код страницы, которую, в свою очередь, веб-сервер передает в браузер посетителя. При этом никто не заставляет вас писать именно скрипты (которые пишутся в виде исходного кода и при вызове специальной программой-интерпретатором "перводятся" в нолики и единицы, понятные компьютеру) - если вы знаете, например, C, то вполне можете написать CGI на нем и затем вызывать откомпилированную программу. Но скрипты писать намного проще, поэтому в 99% случаев используются именно они.
Кстати, вы можете объединить SSI и CGI, т.е. включать в написанную страницу текст, который генерируется скриптом - для этого вам не надо делать ничего сложного - просто в качестве ссылки для включения файла указать свой CGI-скрипт (есть еще директива EXEC, но хостеры ее обычно блокируют).
Теперь у вас есть динамический сайт, который вполне успешно манипулирует разными данными, выдает пользователю информацию в соответствии с его запросами и настройками, создает для вас отчеты о посетителях и делает всякие другие полезные вещи. Но вот беда, довольно быстро обнаруживается, что выборки данных и их сортировку выполнять достаточно неудобно, а при наплывах посетителей эти операции вдобавок занимают кучу времени... И тут возникает идея использовать базу данных. Правда, у тех, кто с базами не работал эта идея долго загоняется в дальний угол подсознания, т.к. они считают, что дело это исключительно сложное и непонятное...
На самом деле, если вы уже используете CGI на своем сервере, а хостер предоставляет доступ к базе, то (почти) никаких сложностей при ее использовании не возникает, а вот удобств она приносит массу. Все что от вас потребуется это изучить SQL (а его основы учатся за час) и посмотреть функции, работающие с базой в том языке, на котором вы пишете свои скрипты. По большому счету, вся работа строится по очень простому алгоритму: подключился к базе, отправил SQL-запрос, прочитал ответ, выдал данные пользователю и отключился.
За счет того, что БД специально разработана для манипуляций данными, всевозможные выборки и сортировки выполняются намного быстрее, чем чтение данных из файлов и дают значительно большую гибкость при написании скриптов и обновлении содержимого сайта. Кроме того, если хостер разрешает подключаться к базе не только с самого сервера, но и по сети, до довольно легко можно состыковать, скажем, ваш офисный компьютер, содержащий прайс-лист и список имеющихся в наличии товаров с базой на сервере, при этом все изменения "офисной" базы будут сразу же видны и на сервере.
Следующая безумная мысль, которая приходит в голову, это начать отдавать файлы по FTP, организовать real-audio или видео вещание, начать рассылку новостей своим подписчикам и т.д. и т.п. Для всех этих действий (за исключением рассылки) требуется, чтобы у хостера были установлены соответствующие серверы. С рассылками проще - доступ к sendmail'у предоставляют все хостеры, но тут очень много своих "подводных камней", так что, наверное, более разумной альтернативой будет использование какой-то службы, специализирующейся на этом сервисе, например, Subscribe.ru.
И теперь, когда на вашей новой и динамической домашней страничке все скрипты написаны исключительно на C для пущей скорости, фотографии вашей поездки в деревню Гадюкино затолканы в базу, а крики вашего попугая тщательно цифруются и доступны для прослушивания, вас огорчает только одно - цифры на счетчике посещений упорно колеблются где-то в районе нуля.
Но тут настало утро и Шахрезада прекратила дозволенные речи...
HTML - это сокращение от Hyper Text Markup Language, т.е. язык разметки гипертекстовых документов. На этом языке пишутся документы, выкладываеые на веб-сайты. И, также как и для любого другого языка, существует довольно много редакторов, ориентированных на подготовку HTML страниц. Сегодня мы поговорим о типах таких редакторов.
Довольно часто ко мне обращаются знакомые или знакомые знакомых с просьбой помочь им сделать WWW-страничку. Почему-то это считается жутко сложным делом, требующим каких-то неимоверных знаний... И мои советы купить какой-нибудь справочник по HTML и потратить 20-30 минут на то, чтобы разобраться как оно работает воспринимаются с изрядной долей недоверия. А зря...
На самом деле, HTML - штука очень простая. И разобраться с 90% используемых тэгов можно за пару часов. Другое дело, что дальше всплывают проблемы с разной интерпретацией тэгов разными браузерами, но... эти проблемы тоже описаны в большинстве справочников. Так что, через совсем небольшое время после приобретения книжки вы вполне сможете творить. Но какие инструменты использовать для творчества?
HTML-редакторы можно разделить на 4 типа: WYSIWYG, полу-WYSIWYG, не-WYSIWYG и notepad. Экстремисты от веб-дизайна твердо уверены что notepad (в данном случае, под этим словом подразумевается любой примитивный текстовый редактор) - лучшее средство. Иногда это так и есть - в тех случаях, когда надо чуть-чуть подправить код - но создавать достаточно сложную страницу в notepad-е... Можно, конечно, но это отнюдь не самое лучшее времяпровождение...
Не-WYSIWYG редакторы недалеко ушли от notepad-а. В принципе, это все тот же простенький текстовый редактор, снабженный функциями подсветки синтаксиса HTML и, возможно, некоторыми функциями, автоматизирующими создание HTML-страничек. Такие редакторы могут быть специально созданы для работы с HTML (например, WEB-ED или HTML notepad) или же это могут быть какие-то "программистские" редакторы, с подключенными модулями для работы с HTML, например, UltraEdit. Пользоваться такими редакторами довольно удобно, но они требуют хорошего знания языка для успешной работы.
Типичным (и наиболее известным) полу-WYSIWYG редактором является HomeSite. Его успех обеспечен, на мой взгляд, очень удобным совмещением возможности писать код руками и наличием большого количества различных "мастеров" помогающих написать те или иные тэги. Немаловажным оказалось и наличие очень хорошего справочника по HTML, и возможность работы с проектами (сайтами), и удобный интерфейс, в котором тэги грамотно разбиты на группы... Недаром именно этот редактор послужил прообразом для множества последователей, скажем, бесплатного 1st Page 2000 или русскоязычного SNK Visual HTML Workshop. На мой взгляд, именно полу-WYSIWYG редакторы наиболее удобны для создания страничек. Они не коверкают ваш код, позволяя писать именно то, что нужно вам, а не то, что считают правильным они; помогают "довести до ума" отдельные тэги с помощью развитых контекстных меню и справочников; дают возможность в любой момент посмотреть на результат своей работы во встроенном или внешнем браузере; и вообще, хорошо адаптированы именно к тем действиям, которые чаще всего приходится проделывать веб-дизайнеру. Помимо уже названных программ этого класса можно назвать AceExpert, Arachnophilia, HotDog Professional Webmaster Suite...
Ну и, наконец, WYSIWYG редакторы. Обычно, "профессионалы" их отметают, считая детскими игрушками. В чем-то они, конечно, правы, но... Экстремизм всегда не очень объективен. WYSIWYG-и могут быть весьма полезны новичкам, изучающим HTML или профессионалам, когда нужно просто сделать набросок странички (или показать этот набросок заказчику и дать ему возможность что-нибудь поменять). Код, полученный с помощью таких редакторов практически никогда не бывает оптимальным - он содержит множество ненужных тэгов, может быть неправильно отформатирован (скажем, содержать переносы строки вместо параграфов или наоборот) и содержать еще кучу глупостей - но это уже основа с которой можно работать. Причем получение этой основы занимает значительно меньше времени, чем при использовании других редакторов. Наиболее известными WYSIWYG редакторами являются FrontPage и Macromedia DreamWeaver.
Ну а окончательное решение об использовании того или иного редактора остается за вами...