В этой статье я расскажу и, естественно, покажу пример создания облака тегов для сайта (блога). Основные инструменты – PHP и фреймворк CodeIgniter (подойдет любой другой).

Но, прежде всего, хочу поблагодарить Delchyve за идею.

Итак, переходим к делу.

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

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

Если ваш сайт (блог) использует какую-нибудь CMS, например, WordPress, Joomla и т.п., то вы без труда найдете плагины, которые сами создадут облако тегов на основе ваших данных, а вам останется только разместить его в шаблоне сайта.

Но мы рассмотрим ситуацию, когда сайт пишется «с нуля» и вам нужно сформировать облако ручками .
Читать дальше »

Приветствую всех!

Это заключительная статья о разработке web приложения, выполняющего проверку URL.

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

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

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

И вот здесь возникает проблема. Мы не можем из командной строки вызвать метод ping, т.к. для этого нужно создать экземпляр класса контроллера (Main) и заодно инициализировать ядро фреймворка.

Вообще при работе с CodeIgniter все запросы отправляются скрипту index.php, а уже он в зависимости от полученных параметров инициализирует объекты и вызывает нужные методы.

Проблему можно решить несколькими способами.
Читать дальше »

Приветствую!

Сегодня мы продолжаем разработку web приложения, выполняющего проверку URL. На данном этапе чтобы получить работоспособное приложение нам осталось только создать представления.

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

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

Все файлы представлений должны находиться в папке application/views/.

Рассмотрим их подробнее.
Читать дальше »

Сегодня я продолжу рассказ о разработке web приложения, выполняющего проверку URL.

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

Примечание. Ссылки на все предыдущие статьи находятся здесь.

Теперь самое время заняться контроллером.

Т.к. приложение довольно простое нам вполне хватит одного контроллера, назовем его main. Кстати, при настройке CodeIgniter в файле routes.php мы указали, что этот контроллер должен загружаться по-умолчанию.

Со структурой приложения и его функциями мы уже определились, переходим к написанию методов контроллера.
Читать дальше »

В этой статье я продолжу рассказывать о создании web приложения для проверки URL. Сегодня мы займемся разработкой моделей.

Примечание. Ссылки на предыдущие статьи этого цикла находятся здесь.

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

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

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

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

Теперь рассмотрим их подробнее.
Читать дальше »

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

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

Итак, структура приложения.

Исходя из перечня функций, нам хватит двух страниц.

Главной (mainpage) – здесь будет размещена таблица с краткой информацией о результатах проверок, ссылки «Удалить» для каждого URL, форма добавления нового URL и кнопка «Пинговать все!», запускающая одновременную проверку всех URL.

Страницы со сведениями по выбранному URL (urldetails). Здесь будет таблица с подробной информацией о результатах проверок (время/дата, результат, размер полученной страницы, время и скорость загрузки). Кроме того, мы добавим ссылки для удаления любого из результатов и кнопу «Пинг».

Посмотреть как выглядят эти страницы можно на скриншотах.
Читать дальше »

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

В случае web приложений ситуация только усложняется.

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

Кроме того, существуют два способа отправки данных формы:
1) обычный (с перезагрузкой страницы);
2) асинхронный (ajax запрос, без перезагрузки страницы).

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

Например. jQuery Validation Plugin, о нем, кстати, написана очень хорошая статья Проверка данных форм.
Для prototype тоже есть несколько аналогичных библиотек: Dexagogo и JSValidate.

Принцип их работы примерно одинаков. Создаете форму с правилами (обычно они указываются в атрибутах class полей формы), подключаете библиотеку, если нужно, пишите свои собственные правила.
Читать дальше »

В комментариях к одной из предыдущих статей меня попросили показать пример загрузки файлов на север с помощью технологии AJAX и фреймворка CodeIgniter.

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

Механизм отправки

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

Тем не менее, можно организовать процесс загрузки так, что с точки зрения посетителя загрузка будет выглядеть асинхронной. Т.е. посетитель укажет имя файла и нажмет кнопку «Загрузить». После этого, увидит умную надпись вроде «Подождите, идет загрузка…» или какую-нибудь анимацию. А после окончания загрузки – сообщение с результатами. Страница, которую он видит, перезагружена не будет.

Но при этом отправка файла будет выполнена обычным способом.

Идея заключается в использовании невидимого фрейма (iframe), атрибута формы target и JavaScript.
Читать дальше »

В этой заметке я покажу, как использовать встроенный роутер CodeIgniter‘а для решения одной несложной задачи.

Прежде всего, пару слов о том, что это такое и зачем нужно.

Как вы, наверное, знаете CodeIgniter – это php фреймворк, одними из основных достоинств которого являются простота использования и низкая ресурсоемкость. Тем не менее, его возможности практически не уступают более «тяжелым» аналогам.

Одной из таких возможностей и является роутер. Он позволяет с помощью несложных правил настроить внутреннюю адресацию сайта по своему вкусу.

Любой запрос браузера передается роутеру, а уже потом – контроллеру. Таким образом, можно изменить любой из параметров запроса. Например, перенаправить запрос другому контроллеру или добавить/удалить параметры.

Делается это достаточно просто. В файле /application/config/routes.php нужно задать правила в виде:

$route[‘выражение’] = "новый_адрес";

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

Теперь переходим к нашей задаче.
Читать дальше »

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

В этой статье мы посмотрим, как создать несложную CAPTCHA, добавить ее к форме, и проверить правильно ли посетитель ввел ее значение. Посмотреть действующий пример можно здесь.

Сразу хочу отметить, что речь пойдет именно о работе с CAPTCHA, а не о создании рисунка для нее.

Поэтому мы используем готовую библиотеку для создания рисунка CAPTCHA. Библиотека называется достаточно незамысловато – captcha и может использоваться вместе с фрэймворком CodeIgniter. В описании библиотеки приведен пример ее использования на обычной странице, поэтому мы рассмотрим вариант проверки с применением технологии ajax.

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