AboutPC

Раздел "Веб-мастеру". Рассылка от ведущего раздела:

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

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

TBE - Сегодня делится на 2 версии (Версия 4.0 и Версия 5.0). Версия 5.0 отличается от 4.0 усовершенствованным механизмом показа баннеров, оптимизация всех подсистем, а также еще более гибкой настройкой дизайна страниц.

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

1. Функции фокусировки показов (таргетинг)
- по тематике сайтов
- по времени суток
- по дням недели
- по конкретным сайтам (для коммерческих участников)
- задание кол-ва показов конкретного баннера
- задание кол-ва показов баннера уникальному пользователю

2. Управление настройками фокусировок по средствам профайлов

3. Функции обратной фокусировки (обратный таргетинг)
- Выборочное запрещение аккаунтов
- Запрещение/разрешение сайтов по тематике

4. Система графической статистики для динамики показов на сутки / семь дней.

5. Рейтинг участников по разделам с возможностью поиска и сортировки

7. Система оповещений пользователей по электронной почте

8. Возможность быстрого перевода ПО на другой язык

Гибкая система безопасности и защиты от накруток сможет гарантировать вам 100% показ ваших банеров!

tbe продается вместе с установкой. Это значит, что вам совершенно не нужно иметь никаких навыков по администрированию серверов либо программированию. Наши специалисты сделают все за вас! От вас требуются только данные для доступа к серверу и MYSQL БД, их вы получите от вашего хостинг-провайдера. По Вашему желанию, Вы можете отказаться от этой услуги.

Для заказа tbe, либо обсуждения условий сделки и возможностей программы напишите по адресу sales@native.ru или выберите удобный для Вас способ связи в разделе контактов сайта. Система будет установлена на вашем сервере в кратчайшие сроки. Оплатить покупку tbe вы можете одним из следующих способов:
- Банковский перевод на наш счет из любого отделения СберБанка.
- Перевод через систему WebMoney.
- Перевод через систему Яндекс.Деньги.
- Наличными в Санкт-Петербурге
- Через систему Western Union

О чем же мы будем говорить? Это очень интересный вопрос, но ответить на него не так-то просто. Сегодня я решил взять для рассмотрения тему так называемого "бесплатного хостинга". Собственно, поговорим на тему такой "бесплатности".

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

Значит, откинем вообще все предложения с оплатой реальными деньгами и будем рассматривать только "бесплатный" сервис. Нет, никаких обзоров халявы вы не увидите, даже и не мечтайте. Возьмем любой "бесплатный" хостинг, к примеру, http://fedya.ru. Что мы видим. Нам предлагают "бесплатно" дисковое пространство под сайт, скажем 50 мб, исполнение CGI и PHP скриптов, поддержку SSI, доступ по FTP и т.д.(Не будем вникать в тонкости серверного ПО, речь сейчас не об этом). За все это нас просят поставить баннер, причем обязательно вверху страницы и только заданного формата, в большинстве случаев 468х60, а иногда и не просят, а нагло автоматически влепят его, куда захотят. Особенно противны рекламные блоки в виде слоев, которые при скроллинге постоянно болтаются вверх-вниз, а еще хуже поп-ап окна, которые просто-таки откровенно бесят некоторых людей, в том числе и меня.

Ну и где же бесплатность, которую все так пропагандируют? Где? Сами знаете где.

"Если вам будет угодно, за отдельную плату мы предоставим вам доступ к MySQL". Эта фраза или подобная ей встречается очень часто, и не только она. Предлагают поддержку доменов второго уровня, увеличение дискового пространства, рор3-ящики, реже раскрутку сайта, дополнительные модули, вроде Cron, поддержки JavaScriptlet и другие услуги за "отдельную плату". Иногда предлагают оплатить дополнительный траффик, особенно это актуально для хорошо посещаемых сайтов, причем популярным сайтам зачастую выдвигают ультиматум по принципу "Или плати или уходи".

Все это наводит на мысли, что на нас, простых пользователях пытаются заработать любым доступным способом. Но не вс так просто, как кажется.

Во-первых, у тех фирм или частных лиц, которые занимаются предоставлением "бесплатного" хостинга есть определенные затраты на аренду или содержание серверов, на обслуживающий персонал, например, сис. админ(ы), на траффик, который съедает львиную долю затраченных средств на поддержание сервиса. Да еще мало ли что, винт полетел, сис. админ заболел, пожар начался(не дай бог!). И все эти затраты идут из общего бюджета фирмы или кармана владельца сервиса. При этом он не получает ничего взамен, никакой прибыли. А кто сейчас занимается благотворительностью? Единицы. И эти самые единицы найдут более высокие цели, более важные задачи для решения проблем тех, кто действительно нуждается в их деньгах. Поэтому можно сказать, что тем, кто занимается предоставлением "бесплатного хостинга" должны иметь прибыль, которая из воздуха никак не возникнет. Вот поэтому и приходится им вешать баннеры, навязывать платные, порой очень нужные услуги, иногда спамить и т.д.

И глупо обвинять "бесплатных" хостеров в их продажности, жажде наживы. Проще говоря, хостинг с баннерами является может и не совсем бесплатным сервисом, но все-таки за него не надо платить деревянных рублей или зеленых Франклинов, поэтому можно сказать, что "бесплатный хостинг" является именно бесплатным хостингом.

Эту статью написал небезызвестный веб-разработчик Петер-Пауль Кох (Peter-Paul Koch), который поддерживает один из лучших ресурсов по JavaScript http://www.xs4all.nl/. Его взгляды на XHTML во многом совпадают с моими личными взглядами на этот язык разметки. По прошествии двух лет можно сказать, что PPK был совершенно прав, тем интереснее будет читать...

Быть веб-разработчиком нелегко. Мало того, что вам надо каждый день обходить ловушки и западни популярных браузеров, так еще надо хотя бы вполглаза следить за технологиями, которые могут повлиять (или не повлиять), на вашу работу. Пока вы совершенствуете свое мастерство в работе с таблицами стилей и DHTML, на новые технологии не остается времени. Какие из них важны в настоящий момент? Какие можно пока проигнорировать?

В этой статье я выражаю свой взгляд на язык, который W3C разработало под видом улучшения HTML: XHTML. Согласитесь вы со мной или нет, в любом случае статья заставит вас задуматься и поможет принять решение.

Вначале я объясню, что такое XHTML, затем дам четыре правила для написание корректного XHTML, и в заключении скажу несколько слов о том, зачем вам может понадобится XHTML.

XHTML - это HTML, записанный в соответствии с синтаксическими правилами XML. Таким образом, для понимания XHTML мы должны понять XML. О нем уже написано много статей, так что ограничимся кратким описанием:

XML - это обобщенный язык разметки. В отличие от HTML, XML позволяет создавать собственные теги и таким образом формировать собственную структуру документа. Вам нужен тег <color-of-hat>? Добавьте его в ваш документ, убедитесь что программа знает, что обозначает этот тег, и все готово.

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

В противоположность XML, HTML гораздо более строго определенный язык разметки с ограниченным набором тегов. В любом случае, общий характер XML позволяет рассматривать HTML-документы как XML-документы с набором тегов для отображения в веб-браузерах. Однако, старые стандарты HTML не до конца совместимы с XML. Например, в HTML необязательно закрывать тег <P>, то есть тег </P> можно опускать. Веб-браузеру на это плевать, так как он запрограммирован, но XML-парсер выдаст ошибку о том, что ваш HTML-документ не является "правильно сформированным" (well-formed).

Чтобы устранить разрыв между этими двумя языками разметки и был разработан XHTML. По существу это обычный HTML, в который добавили синтаксические правила XML для создания well-formed документов. Так что веб-страницы станут XML-совместимыми, а веб-разработчики познакомятся с синтаксисом XML.

На практике, в HTML надо добавить четыре правила, чтобы получился XHTML:

Хорошая новость в том, что у браузеров практически нет проблем с XHTML. Вообще говоря, правила 1, 2 и 4 уже есть в HTML, но не являются обязательными, тогда как правило 3 является обязательным, хотя браузеры в большинстве случаев игнорируют ошибки вложенности. Единственное действительно новое правило - это правило 2а. Однако, это правило приводит к проблемам со старыми браузерами только в том случае, когда вы записываете слэш без пробелов, вот так <br/>. Браузер думает, что это тег br/, а такого он знать не знает, так что никак на него не отреагирует. Если вставлять пробел, то проблема будет решена. Если вы напишите <br />, то браузер увидит тег br с неизвестным атрибутом /. Тег br будет отработан корректно, а неизвестный атрибут / тихо проигнорирован.

Плохая новость в том, что многим придется изменить свои привычки кодирования. Лично мне не нравится правило 1. Во-первых, я не могу понять, почему XML теги могут быть только в нижнем регистре, во вторых, я всегда пишу теги в верхнем регистре, потому что тогда они лучше выделяются в тексте. Почему я должен отказаться от этого, если это удобно? В любом случае, я не изменю своих привычек без веской на то причины.

Итак, зачем использовать XHTML вместо старого доброго HTML? Консорциум W3C выделяет следующие причины:

"Разработчики документов и разработчики браузеров откроют новые пути выражения своих идей через новую разметку. В XML относительно легко вводить новые элементы или новые атрибуты. Язык XHTML разработан для согласования этого расширения посредством специальных XHTML-модулей, которые можно разрабатывать совершенно самостоятельно. Эти модули позволят комбинировать существующие и новые возможности при разработке новых документов и новых браузеров."

"Постоянно появляются новые альтернативные способы доступа в интернет. [:] XHTML разрабатывался с учетом общей совместимости пользовательских браузеров (user agents). Так чтобы новые пользовательские браузеры, сервера и прокси могли достичь наилучшей трансформации контента. В конечном счете, можно будет разработать XHTML-конформный контент, который будет доступен из любого XHTML-конформного пользовательского браузера"

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

Я не считаю, что этих двух причин достаточно для того, чтобы мы, веб-разработчики, перешли с HTML на XHTML.

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

Вторая причина пока тоже не важна. В настоящее время нет чистых XHTML-конформных браузеров, которым необходим XHTML. Да и вообще неизвестно, появятся ли они когда-либо. В конце концов, если вы создадите браузер, который отображает только XHTML, он не будет корректно отображать HTML-страницы. Производители браузеров этого совсем не хотят.

У примеру, Эдди Конечный-Пользователь заходит на свой любимый сайт новым, требующим XHTML, только что установленным браузером Ультра-Бразуер X7 и видит только множество сообщений об ошибках, касающихся валидности XHTML-кода. Что он подумает: "Проклятые веб-разработчики! Вы должны были использовать XHTML!" или "Хренов браузер с кучей багов!"?

Так что, если новый браузер выйдет, разработчики все равно позаботятся о поддержке старого доброго HTML. Новые браузеры на каких-то новых платформах возможно и будут требовать XHTML (хотя я так не думаю), но Netscape и Explorer никогда, потому что они должны быть консервативными в выборе языка.

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

А что с новыми браузерами? Что можно сказать о новых областях Интернет, таких как WAP? Как насчет изучения XML используя XHTML? Читайте дальше:

Конечно, новые браузеры на новых платформах могут требовать XHTML. Но тогда они столкнутся с той же проблемой, что и старые браузеры на старых платформах: они не смогут корректно отображать существующие HTML-страницы, а это означает крайнее недовольство конечных пользователей. Во избежании этого, новые браузеры должны поддерживать HTML.

Конечно, XHTML может стать стандартом для новых областей Интернет, как WML стал стандартным языком для WAP. Это одна из причин, по которой W3C разрабатывал XHTML. Но, откровенно говоря, я в это не верю. Новые области Интернет требуют действительно новых языков, потому что они отличаются от WWW, тогда как XHTML хорошо подходит только для традиционных WWW-страниц.

Конечно, XHTML может уменьшить разрыв между HTML и XML и познакомить веб-разработчиков с синтаксисом XML. Однако я сомневаюсь, что XML настолько важен для истинных веб-разработчиков. Я не считаю, что каждый веб-разработчик должен знать XML, потому что не знаю широко используемых браузеров, которые корректно отображали XML на стороне клиента. XML на стороне сервера, конечно, другое дело.

"В конечном счете, можно будет разработать XHTML-конформный контент, который будет доступен из любого XHTML-конформного пользовательского агента"

Это не кажется вам знакомым? Разве HTML разрабатывался не для всех типов пользовательских агентов? Мы все знаем, что случилось с этим планом:

Итак, если HTML останется, зачем переходить на более сложный язык, который изменит ваши привычки кодирования, но ничего не даст? Я не вижу ни одной причины начать использовать XHTML. Я с наслажденьем продолжу писать теги в верхнем регистре и буду пропускать иногда теги </P>, если почувствую, что все будет хорошо и без них.

Как и все спецификации W3C, XHTML - это интересная теоретическая конструкция, которая может развиться и сыграть важную роль в Интернете. Но пока она бесполезна на практике. Разработчики браузеров должны сделать первый ход. Они должны внедрить поддержку XHTML конструктивным способом, чтобы пользователи не отвернулись от их продуктов. Только в этом случае за ними потянется остальная часть веба.

А те фанатики, которые считают, что каждое слово W3C имеет силу Божьей Заповеди и смотрят на всех, кто не использует XHTML, как на еретиков, которых надо сжечь на костре и чем раньше, тем лучше, просто ошибаются. XHTML - это не о настоящем, XHTML - это о будущем.

Русская часть Интернета растет день ото дня. За последние год-два суммарный объем русскоязычных страниц увеличился более чем в два раза. Сегодня в России уже никого не удивишь словосочетанием <домашняя страничка> или английским словом <homepage>. Если раньше создание web-страниц было уделом избранных и на просторах Рунета царили лишь признанные <киты> web-дизайна, то теперь даже мой десятилетний сынишка в свободное от учебы время мастерит потихонечку собственную страницу, собираясь разместить ее на каком-нибудь бесплатном сервере (вроде narod.ru или boom.ru), которых за последний год тоже развелось в Рунете множество. Web-конструированием сегодня не занимается, наверное, только не подключенный к Сети или ленивый. Множество людей, поблуждав по просторам Интернета, рано или поздно задумываются о создании собственной странички. Для них-то и написана эта статья.

Речь здесь пойдет о <правильном> HTML для новичков, а именно - о некоторых дополнительных возможностях, официально утвержденных интернет-консорциумом (http://www.w3.org/). В частности, о некоторых возможностях, предоставляемых динамическим HTML (DHTML). А еще точнее - о том, как с помощью CSS (cascade style sheets, или каскадных таблиц стилей) сделать страничку, которая будет выглядеть лучше, чем страницы, созданные посредством <классического> HTML, при этом занимать меньше места и, соответственно, быстрее грузиться.

Мало кто из людей, впервые решившихся на создание собственного web-представительства, вооружается notepad'ом или другим текстовым редактором вроде HomeSite. Обычно новичок думает следующим образом: <Все свои привычные документы я создаю посредством программ WISIWYG (<что вижу, то и получаю>) - тексты я создаю в MS Word, презентации - в MS PowerPoint, так возьму-ка я и для создания web-странички подобную программу - MS FrontPage...> Приняв такое решение, новоявленный web-ваятель дважды обкрадывает себя.

Первый раз - в смысле рационального использования web-пространства. Дело в том, что все визуальные редакторы web-страниц, к которым относится и упомянутый MS FrontPage, вставляют в создаваемые страницы <отсебятину> - множество лишних ненужных тегов. Исключением, пожалуй, является Macromedia Dreamweaver (за что он снискал себе заслуженную популярность как среди новичков, так и среди профессионалов). Но даже он в этом плане не идеален - любит засорять исходный текст кавычками (в большинстве случаев совершенно ненужными), а также вставлять символы неразрывного пробела в самых неподходящих для этого местах. Справедливости ради стоит отметить, что все визуальные редакторы предоставляют пользователю возможность работать с исходным кодом создаваемой страницы, но столь любимый многими FrontPage вновь переделает все по-своему, стоит вам только переключиться снова в визуальный режим.

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

Ну, а теперь перейдем непосредственно к делу - к созданию красивых и небольших web-страниц с помощью каскадных таблиц стилей (в дальнейшем тексте я буду употреблять их сокращенное название - CSS). Предполагается, что вы, дорогие читатели, прочтя вступление, согласились со мной, отказались от визуальных редакторов, добыли книгу по HTML, изучили хотя бы небольшое количество основных тегов и атрибутов и горите желанием узнать, что же такое CSS и с чем его едят.

Классический HTML версии 3.2, наиболее распространенный на данный момент в Сети, предоставляет нам средства физического форматирования документов, для чего имеются специальные теги (например, теги <font>, <b>, <i>) и множество различных атрибутов (size, color, height, width и т. п.). Особенности web-форматирования принуждают нас снова и снова прописывать эти теги и атрибуты для каждого нового абзаца, что, конечно, сильно увеличивает размер кода страниц. Кроме того, при таком способе форматирования в случае анализа структуры документа остается непонятным, почему данное слово выделено жирным начертанием - просто для красоты или же чтобы обратить на себя особое внимание конечного пользователя? Если живой человек еще в состоянии худо-бедно разобраться в логических построениях страниц на классическом HTML, то о поисковых машинах или, к примеру, голосовых броузерах этого не скажешь. Им вынь да положь чистую логику в структуре страницы. Именно из-за такой <неподвластности> логическому анализу данный способ форматирования был назван физическим форматированием. В противовес ему при создании новой спецификации HTML 4.0 во главу угла было поставлено логическое форматирование, то есть такое форматирование, при котором структура и оформление документа были бы четко разделены. Этот способ форматирования рекомендован к применению интернет-консорциумом, так как предоставляет расширенные возможности поиска информации в Сети, позволяет более точно структурировать и анализировать информацию посредством поисковых машин, а также существенно уменьшает размер страниц и время их полной загрузки. Реализуется разделение структуры и оформления документа как раз с помощью CSS.

Стоит отметить тот факт, что зачатки логического форматирования присутствовали и в классическом HTML - теги <h1>, <h2>, <blockquote>, безусловно, способствовали разделению документов на некоторые логические блоки. Но многие авторы страниц использовали, да и по сей день продолжают использовать эти теги не по назначению: в связи со скудостью средств для оформления страницы теги заголовков, например, использовались для выделения таких элементов на странице, которые на самом деле заголовками не являлись. CSS же предоставляют достаточное количество средств оформления, что позволяет более точно следовать правилам логического форматирования и действительно отделять структуру страницы от ее визуального представления.

Назначение стилей отдельным элементам страницы

CSS позволяют назначить собственный стиль визуального представления любому тегу HTML, в том числе тегу <body>. Если стиль задан для тега <body>, он наследуется всеми элементами (абзацами, заголовками и т. д.), помещенными внутри этого тега-контейнера, в случае отсутствия собственных стилей для этих элементов. Таким образом, нам уже не нужно прописывать теги <font> и атрибуты color, size и т. п. для каждого абзаца на странице - достаточно задать некий стиль для тега <body>, и все абзацы на странице будут отображены в соответствии с этим стилем. Как же это сделать?

Допустим, мы хотим, чтобы все абзацы отображались шрифтом Times New Roman размером 12 пунктов темно-зеленого цвета. Для этого следует прописать атрибут style тега <body>, присвоив ему соответствующее значение. Синтаксис такой:

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

Обратите внимание - когда мы задавали начертание шрифта, после названия Times New Roman мы указали начертание serif, что обозначает любой шрифт с засечками. Если на машине конечного пользователя не установлен шрифт Times New Roman, броузер подставит вместо него любой из имеющихся шрифтов с засечками, и отображение страницы будет максимально приближено к тому, что вы задумали. Причем приведенный пример будет понятен и для IE (4.0 и выше), и для NN (4.0 и выше). Хотя надо сразу оговориться, что Netscape Navigator поддерживает далеко не все возможности, предоставляемые CSS и DHTML, и это, безусловно, не увеличивает числа его поклонников.

В приведенном примере используется встраивание стиля непосредственно в тег документа - так называемый inline-стиль. Этот способ связывания CSS с HTML-файлом рекомендуется в единичных случаях - если данный стиль планируется применить только к одному элементу только на одной странице сайта. Если же стиль должен быть применен к нескольким элементам на одной странице или к нескольким страницам сразу, рекомендуются другие способы связывания CSS и HTML, о которых мы поговорим далее.

Назначение стилей нескольким элементам одной страницы - создание внедренной таблицы стилей

Пока речь у нас шла о задании только одного стиля для одного элемента. А теперь мы научимся создавать именно таблицы стилей.

Допустим, мы хотим, чтобы все абзацы на странице выглядели, как в предыдущем примере, все заголовки первого уровня отображались шрифтом Arial зеленого цвета полужирного начертания размером 16 пунктов, а все заголовки второго уровня - шрифтом Helvetica размером 14 пунктов полужирного курсивного начертания желто-зеленого цвета. Для этого нам понадобится создать в <голове> страницы (в любом месте между тегами <head> и </head>) внедренную таблицу стилей, в которой мы пропишем несколько правил сразу. Для этого создаем тег-контейнер таблицы стилей, начинающийся открывающим тегом <style> и заканчивающийся закрывающим тегом </style>. Внутри этого тега-контейнера мы вольны задать любое количество правил CSS, состоящих из селектора (названия тега HTML, к которому будет применяться правило) и его определения (непосредственно набора средств форматирования), заключенного в фигурные скобки. Синтаксис для приведенного выше примера такой:

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

Назначение стилей одновременно для нескольких страниц сайта

Помимо встраивания и внедрения для связи CSS и HTML используются способы импортирования и связывания таблиц стилей. Это, безусловно, наилучшие способы для придания единого стилевого оформления нескольким (или даже всем) страницам одного сайта. При этом вся таблица стилей хранится в одном файле (расширение файла должно быть стандартным - .css).

Вот пример содержимого такого файла (например, my.css):

Обратите внимание: теги <style> и </style> внутри файла таблицы стилей не используются - расширение .css явно указывает броузеру на то, что файл является таблицей стилей. Один такой файл может быть связан сразу с несколькими страницами (или импортирован сразу в несколько страниц). В html-файле для связывания нужно прописать в любом месте между тегами <head> и </head> следующую строку:

В этой строке указывается, что связываемый файл является таблицей стилей (rel="stylesheet"), формат этого файла - .css1 (type="text/css") и находится он в той же директории, что и файл html, либо имеет другой URL-адрес (href="my.css"). Очевидно, что эту строку мы можем прописать в любом (либо во всех) из наших html-файлов. Таким образом, единое стилевое оформление будет прописано для нескольких страниц сразу.

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

Для импортирования файла таблицы стилей (в том числе с другого сервера) мы должны прописать в любом месте между тегами <head> и </head> внутри тега-контейнера <style> следующую строку:

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

Таким образом, зная, в какой последовательности броузер анализирует таблицы стилей, мы можем задать одну общую связанную таблицу для всех страниц сайта и при этом гибко управлять стилями отдельных страниц и отдельных элементов на странице. Именно с этой особенностью и связано слово <каскадные> в названии CSS (cascading style sheets) - несколько таблиц стилей, присоединенных к html-файлу, прокатываются через анализатор (броузер) неким <каскадом> в порядке их приоритетности.

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

Допустим, мы хотим создать страницу, на которой будет два вида абзацев <p>, причем оба вида будут постоянно чередоваться и часто повторяться. Типичный пример такой страницы - интервью, в котором чередуются вопросы журналиста и ответы интервьюируемого. Естественно, при создании такой страницы мы захотим визуально отделить вопросы и ответы друг от друга. Если бы нам пришлось это делать теми средствами CSS, которые мы рассмотрели выше, то пришлось бы создавать две различные таблицы стилей. К счастью, в этом нет необходимости. Мы можем создать в одной таблице стилей два различных класса абзацев с помощью селектора класса. Это будет выглядеть так:

В приведенном примере вопросы журналиста будут отображаться шрифтом Arial серого цвета, полужирным, курсивного начертания, размером 10 пунктов с отступом 15 пикселов от левого края страницы. Ответы же будут отображены шрифтом Times New Roman размером 12 пунктов черного цвета. Важно не забывать прописывать параметр class различным классам абзацев непосредственно в коде html. Вы можете создавать любое количество классов для любых элементов страницы.

Возьмем другой случай. Предположим, вы хотите создать на странице какие-либо уникальные элементы, к которым в дальнейшем планируете обращаться из программ JavaScript. Возможно, эти элементы будут повторяться на других страницах, и вы хотели бы задать им единое оформление посредством CSS. На этот случай в каскадных таблицах стилей имеется возможность присвоения уникальным элементам идентификаторов (id). Наиболее часто идентификаторы используются для элементов форм, которые в спецификации HTML 4.0 имеют полную либо ограниченную поддержку CSS (в зависимости от элемента). Вот пример назначения идентификатора и правил CSS таким элементам:

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

Допустим, мы создали таблицу стилей, согласно которой все заголовки первого уровня на странице отображаются красным цветом на сером фоне, все абзацы - зеленым цветом на желтом фоне, а все выделенные посредством тега <em>1 слова внутри абзацев - черным цветом на серебристом фоне. Код таблицы стилей, как вы уже догадались, при этом выглядит так:

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

А вот пример кода страницы с использованием этого контекстного селектора:

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

В российских компаниях в последнее время заметно растет внимание к качеству интерфейсов разрабатываемого ПО. Если два года назад среди объявлений о поиске персонала встретить вакансию проектировщика интерфейсов было практически невозможно, то сегодня подобные объявления появляются не реже чем два-три раза в месяц. О росте интереса также свидетельствует и главный юзабилити-форум рунета. Если раньше там общался очень узкий круг профессионалов, в основном знающих друг друга лично, то теперь все чаще появляются новички. Налицо вполне позитивная тенденция, можно говорить о том, что усилия по популяризации юзабилити в России начинают приносить первые плоды.

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

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

Итак, главные функции дизайнера интерфейсов таковы:

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

Может ли программист заменить юзабилиста

Часто среди объявлений о поисках дизайнера интерфейсов можно встретить подобные:

«Компания-разработчик ПО ищет разработчика GUI. Основные требования: опыт работы в качестве программиста не менее трех лет, хорошее знание Object Oriented Programming/Object Oriented Design, C++, MS Visual C++, Win 32 API, XML…»

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

Принципиальное отличие дизайнера интерфейсов от программиста состоит в том, что программист привык иметь дело с машинами, а дизайнер интерфейсов — с людьми. Проектирование интерфейсов — дисциплина не техническая, а скорее общественная. Вот почему я считаю глубоко порочным такой подход к формированию штата IT-компании, когда работодатель ищет разработчика интерфейсов и специалиста в Object Oriented Programming в одном лице. В этом случае самое лучшее, что он может получить, это квалифицированного программиста, имеющего некоторое представление о юзабилити. Возможно, этот человек прочитал книгу о проектировании интерфейсов, или целых две. Возможно, закончил курсы. Все это, безусловно, полезно для специалиста в программировании и помогает эффективной коммуникации с юзабилистами. Точно так же, как юзабилист может получить представление об основах программирования. Не для того, чтобы сделать программирование своей основной деятельностью, но для того, чтобы лучше понимать программистов-профессионалов, работая с ними в одной команде над одним проектом.

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

Может ли графический дизайнер заменить юзабилиста?

Довольно часто можно слышать мнение, что проектирование интерфейса лучше доверить графическому дизайнеру, потому что речь идет о том, как система будет выглядеть. В основном этот миф касается не разработки ПО, а создания веб-сайтов. Это неправильно.

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

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

Кроме того, даже в случае создания сайта, а не ПО речь на самом-то деле не только о том, «как система будет выглядеть», а в первую очередь о том, какова будет ее структура и логика взаимодействия с пользователем.

Некоторые дизайнеры с недоверием относятся к юзабилити-специалистам, поскольку считают, что те призваны ограничить их творчество. Это не вполне правильное представление о роли юзабилиста. Некоторый конфликт интересов на самом деле присутствует, однако это нормально. Процесс разработки информационной системы всегда состоит из множества компромиссов, связанных с ограничениями бюджета, временными рамками проекта, необходимостью учитывать вопросы брендинга, определенными техническими ограничениями и так далее. Часто приходится искать компромисс между эстетикой и эргономикой. Потому очень редко можно встретить систему, которая была бы одновременно привлекательной в той степени, как это планировал визуальный дизайнер, и настолько эргономичной, какой ее разрабатывал юзабилист. Однако приемлемый результат невозможен без одновременной работы и дизайнера и разработчика интерфейсов.

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

Кирилл Вятчин — специалист по юзабилити, разработчик пользовательских интерфейсов. Сотрудник компании Usethics. Среди профессиональных интересов — концепция использования шаблонов в дизайне взаимодействия. В данный момент оканчивает обучение в магистратуре факультета социологии и психологии Киевского национального университета им. Шевченко.

"Includes" (англ. "включать") означает, что SSI добавляет что-то на ваши страницы.

"Server Side" означает то, что SSI обслуживаются сервером, а не браузером. В то время как сервер посылает вашу страницу в браузер посетителя, он сканирует страницу, ища специальные теги, которые сообщают о том, что надо включать вместо них. Когда он находит такие теги, он включает блоки кода вместо этого тега и отсылает результат.

Где Вы бы не использовали один и тот же код на страницах сайта (такой как панели навигации, формы подписки и т.д.), используйте SSI и Вам придется поменять только один файл, чтобы внести изменения на все страницы, где используется SSI.

Но если это так просто, то почему не каждый использует SSI? Ответов два: 1) эта процедура занимает несколько наносекунд у Вашего сервера на сканирование и добавление; 2) не каждый знает о том как использовать SSI.

Большинство хостинговых компаний позволяет использовать SSI. Обычным требованием в таком случае является расширение .shtml для таких страниц. Это вызвано тем, что использование SSI занимает часть ресурсов сервера и определенный период времени. Таким образом Вы будете использовать .shtml расширение для SSI-страниц и расширения .html and .htm для всех остальных.

Если Вы не знаете поддерживает ли сервер SSI, проделайте простой тест.

Создайте 2 файла. Назовите первый mytest.shtml а второй - myssi.txt

Загрузите эти два файла на сервер и посмотрите файл mytest.shtml в браузере. Если Вы видите фразу "It goes here. Here I am!", то это значит, что сервер поддерживает SSI.

Заметьте, что теги SSI находятся внутри тегов комментария. Некоторые серверы будут работать нормально если есть пробел после  . Но некоторые серверы будут давать ошибку. Пример:

возможно будет работать на некоторых серверах, но не на всех. Чтобы быть уверенным в работоспособности SSI пишите так:

А теперь мы покажем примеры того, как правильно использовать SSI:

Замените подчеркивание на имя файла который Вы хотите включить на страницу. Имя файла может быть любым (обычно расширения таких файлов .txt .html), но это должен быть текст. Это может быть простой текст, код HTML, JavaScript, и т.п. Однако нельзя использовать графические и звуковые файлы.

Файл который Вы включаете может иметь HTML код для графики и звука, но вы не можете вставлять их напрямую. Файл должен находится в той же директории что и .shtml страница.

Тоже самое что и file="__________" за исключением того что файл может находится в другой директории.

Замените подчеркивание на имя CGI-скрипта. Имя файла может быть любым, но не допускается наличие адреса http://... . CGI-скрипт должен возвращать текст, но этот тектс может быть JavaScript или HTML-код для графики и звука или другого кода, который обрабатывается браузером

Используя эти 3 простых тега у Вас будет один кусок кода который будет включен на все страницы вашего сайта.

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

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

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

Сперва необходимо скачать сам скрипт и познакомиться со всеми возможностями скрипта на локалке (для переноса скрипта с локального компьютера на виртуальный сервер Вам нужно лишь изменить переменную $config_http_script_dir в data/config.php). Самое главное, что понравится почти всем, это то, что CuteNews нуждается только в PHP. Никаких mySQL и т.п. НЕ НУЖНО! Вся информация хранится в текстовых файлах, что не менее удобно, чем БД.

Итак, создаем папку (например, news) и закачиваем содержимое архива в эту папку. Выставим теперь CHMOD (права доступа): для news/index.php - 777 и для news/data/ и всем файлам и папкам в data/ - тоже 777.

Теперь можем приступить к инсталляции. Открываем браузер, пишем в адресной строке путь к индексному файлу (http://localhost/news/index.php). Перед Вашими глазами предстанет страничка на которой Вам будет предложено установить скрипт. Жмем на кнопку "Proceed Installation >>" (вот, наверное, единственная вещь, которая может отбить желание использовать этот скрипт. CuteNews имеет только англоязычный интерфейс. Однако он на столько прост, что будет понятен даже человеку, знающему только МАНЕЙМ ИЗ ВАСЯ ПУПКИН. Сразу скажу, что CuteNews понимает русский язык в полной мере, поэтому с публикацией новостей проблем не будет). Затем, если правильно выставлены все права, то Вы увидите таблицу, в которой приведен список файлов и их CHMOD. Снова жмем на кнопку "Proceed Installation >>" и попадаем на страничку настроек. Здесь необходимо вписать УРЛ (определяется автоматически), админский логин и пароль, а также Ник, который будет отображаться при публикации новостей (очень удобно поставить короткий логин, чтобы подолгу не вводить его, а использовать имя на любом языке). (рис. 1)

Вот и все! Теперь в целях безопасности можем удалить файл ./inc/install.mdu, отвечающий за инсталляцию.

Снова открываем страничку index.php и вводим свои данные. Попадаем в т.н. "админку", где можно добавлять/редактировать/удалять новости, менять все настройки и т.д. Теперь обо всем поподробнее.

Здесь мы можем увидеть общее кол-во новостей, комментариев, юзеров и т.л.

На этой странице мы можем добавить новости. Здесь присутствуют несколько полей:

- Title (Заголовок новости) показывается всегда и везде. Самое важное поле :)
- Avatar URL (картинка новости) работает опционально. Т.е. если Вы захотите, чтобы вместе с новостью показывалась Ваша фотография или еще что-нибудь, то вводите адрес картинки и она вставится на страничку с новостями. Ели же Вам это не нужно, то просто не заполняете поле.
- Short Story (краткое содержание) будет показываться тогда, когда Вы хотите опубликовать не всю новость, а только часть с добавлением ссылки, вида "Read More..."
- Full Story (статья целиком) работает также опционально. Можем оставить пустой и видеть только Short Story, но без ссылки на продолжение.
- Ссылка [options] (опции). Здесь можно выбрать конвертирование пустых строк на <br>, а также использование HTML (стоит по умолчанию и рекомендуется мною, т.к. Вы сможете добавлять в текст и ссылки, и рисунки, и списки, и т.д.)
- Ссылка [quick tags] для быстрого добавления тэгов, таких же, которые используются в форумах (phpBB, exBB и т.д.). Можно делать текст жирным, наклонным, менять шрифт, его цвет и т.п.
- Ссылка [insert image] для вставления рисунков. Очень удобная опция, т.к. по нажатию на ссылку открывается окошко, в котором имеется форма для загрузки изображений с компа на сервер. После загрузки изображения, вам достаточно кликнуть по имени файла и в поле, где Вы вводил текст, автоматически вставится ссылка на файл.

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

Самая интересная вкладка. Интересна тем, что здесь Вы можете сделать практически все, что пожелаете:

- Personal Options (Личные настройки). Тут можно поменять пароль, ник, а также добавить свой аватар и включить опцию скрытия своего мыла.
- System Configurations (Системные настройки). Во-первых, здесь можно изменить УРЛ движка (например, если Вы решили сменить хостинг). Также можно поменять внешний вид админки (изначально в пакет входят три скина. Мне больше всего нравится simple, который не перегружен картинками и смотрится очень приятно. Однако Вам никто не мешает создать свой скин и использовать его на сайте. Просто покопайтесь в стандартных скинах, скачайте еще, посмотрите принцип действия и все...). Также Вы здесь можете настроить поведение комментариев, даты, аваторов и т.д.
- Add/Edit Users (Добавить/редактировать пользователей). Одной из главных отличительных особенностей скрипта является многопользовательская поддержка. Вы можете как сами добавлять юзеров, так и скачать отдельный плагин для автоматической регистрации пользователей. Вы можете выбрать уровень доступа каждого пользователя отдельно (4 уровня: комментатор, журналист, редактор и администратор).
- Manage Uploaded Images (Управление загруженными изображениями). То, о чем говорил ранее, при добавлении новостей. Вы можете загрузить/удалить необходимые картинки и посмотреть размер изображения (килобайты, длина и ширина).
- Edit Categories (Редактирование категорий). Скрипт позволяет сделать любое количество категорий и использовать их как отдельные разделы (при добавлении новостей появится выпадающий список категорий).
- Block IP's from posting comments (Забанить IP). Наверное, любой администратор сталкивался с людьми, которым нечего больше делать, как добавлять дурацкие ремарки в комментарии и т.п. Вот здесь Вы можете вписать IP такого пользователя и он больше не сможет побеспокоить Вас (правда, если он использует анонимный прокси, то такой способ не пройдет). Есть и радикальное решение - просто отключить функцию комментариев вообще ;)
- Edit Templates (редактирование шаблонов). Самых необходимая функция скрипта. Здесь можно создать свой шаблон или отредактировать стандартные. Для чего все это нужно? А для того, чтобы новости не выводились как попало на странице, а в специально определенном порядке и виде. Например:

Такой простецкий скрипт вставит на Вашу страничку 5 новостей из второй категории с использование шаблона YOUR_TEMPLATE, который в свою очередь может использовать такие переменные:

{title} - Заголовок
{avatar} - Отображение аватора
{short-story} - Краткое содержание
{full-story} - Полное содержание
{author} - Автор и ссылка на его e-mail
{author-name} - Имя автора без e-mail
[mail] and [/mail] - Генерирует ссылку на e-mail автора, но можно вставить любой текст вместо имени
{date} - Дата публикации
[link] and [/link] - Ссылка на полное содержание
{category-icon} - Показывает иконку категории

Тогда самый простой шаблон будет выглядеть так (можно использовать любые HTML-тэги):

А в итоге он будет отображаться таким образом:

Все очень удобно. Можно сделать так, как захотите. Например, вставить рисуночки. Т.е. вместо {author} например [mail]<img src=MAIL.GIF>[/mail], тогда какая-нибудь вращающаяся "собачка" будет ссылкой на Ваш e-mail. Фантазируйте в свое удовольствие!!!

- Archives Manager (Управление архивами). Удобно, например, сделать, чтобы не все новости выводились, а делились по месяцам. Можно в конце месяца заархивировать необходимые новости, и делать ссылку на архив. Здесь нужно быть только предельно внимательным, т.к. после отправки в архив, стандартными средствами восстановить те новости в обычным списке невозможно. Поэтому делайте резервные копии. Вот об этом чуть ниже.
- Backup Tool (Резервное копирование). Эта функция просто сохранит все Ваши новости и комментарии в отдельной папке с возможностью дальнейшего восстановления.

Вот и все основные возможности. Остались лишь вкладки Help (Помощь) и Loginout (Выход). В первой вкладке Вы сможете познакомиться вкратце с возможностями скрипта (опять же на английском языке). Ну, а с последней, я думаю, все понятно :)

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

Посмотреть скрипт в деле Вы можете на этих сайтах (причем второй полностью построен только на CuteNews):
http://ultra-music.com
http://italy.pressballmanager.net

Кстати. В дистрибутив системы входят два примера, уже готовых к употреблению. В общем, на базе второго из них (рис. 2) я и построил сайт http://italy.pressballmanager.net.

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

А вот ссылки, необходимые для Вас:
http://cutephp.com/ - сайт CuteNews, где Вы сможете найти еще много различных плагинов
http://cutephp.com/forum/ - форум поддержки
http://web.langame.net/air/cutenews.1.3.1.zip - прямой линк на версию 1.3.1 (114 кБ)
http://www.photothumb.com/CuteDateEdit/CuteDateEdit.zip - программа, меняющая дату публикации новостей (все даты запоминаются в UNIX формате, так что не вздумайте что-либо ручками менять, лучше используйте эту прогу) (285 кБ)
http://www.xs4all.nl/~cvdtak/cuteinstaller.zip - установочный скрипт плагина XFields, который добавляет новые поля (используйте после установки главного скрипта) (8 кБ)
http://cutephp.com/cutenews/addons/xfields.rar - плагин XFields, который нужно настроить ручками (безопасней и кое-чему учит) (4 кБ)

Еще раз скажу, что Вы не найдете скрипт, лучше этого. Тем более, бесплатный, с отличной службой поддержки и огромным количеством дополнительных возможностей! CuteNews настолько универсален, что его можно использовать в качестве настоящего портала, не требующего БД, или как маленький новостной скриптик для домашней странички.

Итак, нам нужно засечь время, потраченное на выполнение SQL запросов? Это не очень легко, но и не сложно. Начнем с определения задачи. Необходимо выдать полное время, затраченное на генерацию страницы и время, затраченное на выполнения SQL запросов, еще было бы здорово вывести процент от общего времени.

Сначала напишем функцию, которая выдает время, затраченное на выполнение своего кода:

Для конкретно нашей задачи, нужно модифицировать эту функцию так, чтобы выполнялись SQL запросы:

Теперь у нас есть функция, которая считает запросы и выдает время экзекуции :) Вот как она должна быть использована:

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

Функция проверки орфографии на PHP (на входе проверяемый текст, на выходе список слов с ошибками):

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

Сразу скажу, что сделать это невозможно только средствами браузера. Для реализации подобных вещей существует множество специальных языков. Самой большой популярностью пользуются perl и PHP. В чем их сходство и различие?

Часто путают понятие CGI и perl. CGI (Common Gateway Interface) - протокол обмена данными с программами. А perl - специальный язык высокого уровня, на котором и реализуются необходимые фукции взаимодействия с операционной системой на сервере. В общем случае с помощью CGI можно запустить любое приложение на сервере и все, что будет из него (приложения) выведено на стандартный поток вывода, попадет в браузер. Параллельно приложение может произвести вывод данных в файл на сервере, послать на емэйл или поместить (извлечь) что-то в базу данных.

Коренное отличие PHP от CGI заключается в том, что PHP является препроцессором HTML. Т.е. его работа построена по следующей схеме:

Т.е. до того, как сервер "отдаст" файл браузеру, его просматривает препроцессор-интерпретатор. Что это значит? Файлы, которые подвергаются обработке препроцессором, должны иметь определенное расширение (обычно это .phtml или .php3, но эти значения можно поменять) и содержать (хотя это не обязательное требование) код для препроцессора. Код этот может быть оформлен следующими способами:

Далее я подробнее остановлюсь на функциях языка PHP, так как считаю его более понятным (синтаксис его близок к языку C++) и удобным (это мое личное мнение, так что вы вольны выбрать то, что вам нравится больше). Кроме того, если нам необходимо вставить в обычную HTML страницу результат работы несложной функции, то это удобнее сделать именно с PHP, так как код может содержаться прямо в HTML коде страницы. Для CGI, в такой ситуации, нам придется либо выводить всю страницу из скрипта, либо использовать технологию Server Side Include.

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

И так что мы можем сделать с помощью PHP? Самый простейший пример:

Посмотрите результат работы этого фрагмента: test53.phtml.

Исходный текст документа в браузере выглядит так:

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

Как вы могли заметить, страницы на большинстве серверов содержат неизменную часть: навигационные панели, логотипы, кнопки и пр. Довольно трудно переписывать эти вещи каждый раз, когда что-то добавляешь на свой сайт. Раньше, мне приходилось каждый раз создавать новый "опыт" из шаблона, который, зачастую, занимал больше места, чем сам опыт. К счастью, в PHP есть функция подключения внешних файлов. Таких функций две (на самом деле, их три, но функция "virtual" используется только для сервера Апач, и является заменой стандартной директивы <!--virtual ...): include() и require(). Основное отличие этих функций состоит в том, что вторая включет текст файла в любом случае, а первая - только, если он еще небыл включен. Например следующий текст мы поместим в файл header.inc.php3:

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

Не забудьте посмотреть сайт языка PHP: http://www.php.net/. Там вы сможете найти дистрибутив и полную документацию. Дистрибутивы имеются для всех ведущих платформ. У меня на компьютере, на котором я и пишу эти опыты, установлен PHP версии 3 и сервер Apache. Все работает нормально и очень удбоно отлаживать страницы, не посылая их на удаленный сервер. Советую вам установить у себя такую связку.

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

Структуру данных лучше взять общепринятую - в записи сообщения или рубрики форума содержится идентификатор родителя. Для организации вывода дерева напрашивается рекурсивная функция. Именно так сделано в Phorum'е [http://phorum.org]. Файл include/multi-threads.php содержит функцию thread, которая строит вызывается для каждого корневого сообщения и рекурсивно вызывает себя для ответов на них:

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

Для построения дерева достаточно знать последовательность вывода рубрик и их уровень в дереве. Добавим два поля с этими данными в таблицу: level (TINYINT(4). 127 уровней - хватит?) и sortorder (VARCHAR(128)).

Всё, что нам нужно для построения дерева - это идентификатор рубрики и её родителя. Допустим, мы имеем в каталоге несколько рубрик такого содержания:

Структура дерева, подобие которой мы хотим получить такова:

Правда, данный алгоритм позволит нарисовать дерево, но без веток виде линий, как сделано на этом рисунке. Структура дерева будет нарисована при помощи отступов слева.

Вернёмся ещё раз к таблице id-parent. Это рубрики, уже отсортированные по некоторому признаку, по которому мы хотим сортировать элементы одинакового уровня. Например, по убыванию числа сайтов. Кроме id и родительской рубрики мы знаем и номер каждой из них в данном списке. Выровняем эти номера до нужной длины, добавив слева нули. После этого для каждой рубрики сделаем текстовую строку с номерами всех её родителей от самого корня:

При сортировке по полю sortorder мы получим именно то, что нам нужно:

Важно так же отметить, что нам не нужно ничего сортировать в самом скрипте. Для формирования полей sortorder и level нужно заблокировать таблицу от записи (чтобы не произошло изменения структуры веток), выбрать из базы идентификатор рубрики и её родителя, отсортировав по нужному признаку, и записать их в простой двухмерный массив. Затем обработать массив последовательно от первого до последнего уровня и записать поля sortorder и level в таблицу.

Для формирования sortorder не нужно рекурсии (хотя можно, и, вероятно, она работать будет даже быстрее). Достаточно пройтись по массиву одним и тем же циклом. В нём, если рубрика не обработана, для неё формируется поле sortorder из поля sort и родительского sortorder. Если родительская рубрика ещё не обработана, поднимается флаг $unprocessed_rows_exist и цикл запускается ещё раз.

Отмечу, что данный алгоритм не зацикливается при наличии строк с битым полем parent и не пропускает их, а делает корневыми. Рекурсивный алгоритм их просто пропустит.

После выполнения этого цикла мы имеем массивы "id => level" и "id => sortorder". Отправляем в базу всего один запрос, пользуясь внутренними функциями MySQL ELT и FIND_IN_SET:

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

В форумах чаще всего используется сортировка по дате написания сообщения. Поэтому поле sortorder можно смело делать из своего и родительского timestamp'а, выровненного функцией str_pad [http://www.php.net/manual/en/function.str-pad.php] до 11-значной длины.

Баннерные сети

Бесплатно не бывает!

Оценка XHTML

Основы CSS

И жнец, и швец, и на дуде игрец

"Server Side Includes" - Основы и приемы использования

CuteNews 1.3.1

Время выполнения SQL запросов

Функция проверки орфографии на PHP

Серверные скрипты

Работа с MySQL. Деревья