Постоянные читатели этого блога, наверное, помнят, что некоторое время назад (прошло почти 10 месяцев ) я опубликовал несколько постов о разработке TODO скрипта под названием CircleTasks. Там же были выложены исходники и ссылка на демо версию.

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

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

И, совсем недавно, я узнал, что оказывается не я один пользуюсь этой системой

Читатель этого блога Radioact предложил не только очень полезные изменения, но и реализовал их.

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

Кроме того, он поделился исходниками и демо версией.

Логин: demo@demo.com
Пароль: demodemo

Перечислю реализованные изменения

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

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

3. Сортировка по дате по умолчанию выполняется в убывающем порядке – новые вверху. Вообще, если вы правильно организовываете свою работу, то список невыполненных задач не должен быть большим

4. Повторный клик по статусу задачи закрывает список. Это важный момент, на который я не обращал внимания. Дело в том, что я отлично помню все иконки и статусы (т.к. сам их рисовал). Но новый пользователь сразу все не запомнит и будет открывать список только для того, чтобы посмотреть, что в нём есть.

Кроме того, Radioact сделал несколько предложений по дальнейшему развитию проекта. Все желающие могут присоединиться к обсуждению.

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

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

3. Доработать оформление списка записей. Например, добавить в шапку треугольники для сортировки.

Все пожелания и замечания пишите в комментариях! Обсудим!

Интересно почитать.

Интернет маркетинг – покер и видео сайты

Недавно ко мне обратился читатель с просьбой помочь отправить сообщение в LiveJournal через XML-RPC протокол. При этом использовать нужно было библиотеку фреймворка CodeIgniter.

Честно говоря, когда я вижу такие вопросы, то сразу пробую найти готовое решение. Этот случай исключением не был и подходящая инструкция быстро нашлась. XML-RPC и кросспостинг в ЖЖ. Константин Лихачев в ней подробно рассказывает об отправке сообщений, единственное но – используется Incutio XML-RPC Library, а не встроенная библиотека CI.

Раз работает код с использованием Incutio XML-RPC, то сервис 100% рабочий и нужно просто правильно передать параметры в библиотеке CodeIgniter'а.

Думаю: «Почему бы не помочь человеку? Опыт работы с CI у меня есть, с документацией JiveJournal разбираться не нужно, т.к. список всех нужных параметров есть в статье Константина. Минут за 20 сделаю…»

Мне пора бы привыкнуть, что когда я так думаю, эти 20 минут часто превращаются в 2-3 часа.

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

И пропустить один из них (что я и сделал) или вставить лишний очень легко.

По-идее, именно для таких ситуаций предусмотрен режим отладки. Но в этом режиме библиотека CI выводит только XML ответ сервера, а мне нужно было посмотреть на XML строку, которая отправляется в запросе.

Примечание. Ответ сервера:

Can't use string ("Array") as a HASH ref while "strict refs" in use at /home/lj/cgi-bin/Apache/LiveJournal.pm line 1779.

лично мне ни о чем не говорит (на perl я не программирую). Кстати, тот же WordPress в таких случаях возвращает «parse error. not well formed» – на мой взгляд, более понятный ответ, хоть и не очень информативный.

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

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

Чтобы вывести запрос я добавил строку

echo '<pre>'.htmlspecialchars($op).'</pre>';

в методе sendPayload перед

if ( ! fputs($fp, $op, strlen($op)))

Не очень элегантное решение, но зато сразу стало ясно, в чем проблема.

Привожу рабочий код отправки сообщения в livejournal.

class LiveJournal extends Controller {

	private $LJ_url = 'http://www.livejournal.com/interface/xmlrpc';
	private $LJ_login = 'your login';
	private $LJ_pass = 'your pass';

	function LiveJournal()
	{
		parent::Controller();

		//подключаем XML-RPC библиотеку
		$this->load->library('xmlrpc');
	}

	function index()
	{
		$this->xmlrpc->server($this->LJ_url);

		//отправляем challange-запрос
		$this->xmlrpc->method('LJ.XMLRPC.getchallenge');

		if (!$this->xmlrpc->send_request()) {
			echo $this->xmlrpc->display_error();
		}
		else {
			//если получен ответ с challenge-строкой, читаем его и отправляем запись
			$challenge_response = $this->xmlrpc->display_response();

			//формируем массив с данными для создания записи
			$request = array(
			array(
				array(
					'username'=>array($this->LJ_login,'string')
					,'auth_method'=>array('challenge','string')
					,'auth_challenge'=>array($challenge_response['challenge'],'string')
					,'auth_response'=>array(md5($challenge_response['challenge'].md5($this->LJ_pass)),'string')
					,'ver'=>array('1','string')
					,'event'=>array('Заголовок записи','string')
					,'subject'=>array('Текст записи ...','string')
					,'year'=>array(2009,'int')
					,'mon'=>array(11,'int')
					,'day'=>array(12,'int')
					,'hour'=>array(5,'int')
					,'min'=>array(27,'int')
					,'props'=>array(
						array(
							'opt_backdated'=>array(true,'boolean')
							,'taglist'=>array('tag 1, tag 2, tag 3','string')
						)
						,'struct')
					,'security'=>array('public','string')
				)
				,'struct'
			)
			);

			//отправляем запрос серверу
			$this->xmlrpc->method('LJ.XMLRPC.postevent');
			$this->xmlrpc->request($request);
			if (!$this->xmlrpc->send_request()) {
				echo $this->xmlrpc->display_error();
			}
			else {
				$postData = $this->xmlrpc->display_response();
				//$postData['url'] - содержит адрес созданной записи
			}
		}
	}
}

Несколько пояснений. Публикация сообщения выполняется в 2 этапа.

1) Нужно получить challenge строку, которая хешируется (строка 36) вместе с вашим паролем и используется вместо него. Это сделано для того, чтобы не передавать пароль в открытом виде.

2) Отправка самого сообщения. Как раз тут и нужно формировать структуру с данными. Как видите, мы везде используем массивы с двумя элементами. Первый элемент содержит передаваемое значение, второй – тип этого значения. Если нужно передать структуру, то первый элемент должен быть массивом.

Выглядит такая конструкция громоздкой и заполнять ее нужно внимательно, особенно если вы привыкли к библиотеке вроде Incutio XML-RPC. Кстати, эту библиотеку не сложно подключить и использовать вместо стандартной CodeIgniter’а.

Вообще в последнее время складывается впечатление, что разработчики забросили фреймворк. Хотя, возможно, я не прав, а Ellislab просто все силы тратит на свою CMS, вторую версию ExpressionEngine, которая вроде бы будет работать на основе CodeIgniter.

Очень не хочется, чтобы они забросили CI.

Постовой

Что выгоднее, услуги приходящего бухгалтера или ведение бухгалтерии у профессионалов? Ответ здесь

Уделяете ли вы внимание организации своей работы?
Много ли у вас "мелких" дел, о которых вы регулярно забываете?

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

Хуже всего, когда нужно сделать много «мелких» дел, которые не занимают много времени, но обязательно должны быть выполнены вовремя… и держать в голове их все просто невозможно.

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

Я решил не оставаться в стороне и сделал собственный вариант такого ToDo списка, естественно, с некоторыми дополнительными возможностями.

Кстати, скрипт называется SimpleTasks.

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

Систему обозначений придумал не я. Но, к сожалению, не могу найти первоисточник (UPD. Огромное спасибо Smarty за ссылку на оригинал). Предназначена она для использования с бумажным блокнотом и довольно удобная. Во всяком случае, читать такой список задач становится намного легче. Взгляд сразу отбрасывает выполненные задачи.

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

В общем, я написал небольшое web приложение, использующее эту систему обозначений.

Если есть желание, можете поиграться с ним (логин admin@todo.loc, пароль password).

Или скачать архив и установить на своем сервере (инструкция в архиве).

Принцип работы.

Создание новой записи.
Кликаем по ссылке "Новая запись" (справа в верхней части страницы) и в открывшемся окне вводим данные записи.
При клике по полю "Дата" будет открыт календарь. Т.е. ввести дату в неправильном формате довольно проблематично.

Редактирование.
Клик или двойной клик на соответствующем поле позволяет изменить его. Открываетеся либо диалог, либо inline редактор.

Удаление.
Кликните по картинке с изображением крестика в соответствующей строке и подтвердите удаление.

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

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

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

Скорее всего, некоторые функции будут дорабатываться.

И я очень хочу услышать ваше мнение!

Прежде всего, меня интересуют такие вопросы.

1) Есть ли смысл делать подобное приложение многопользовательским? Т.е. технически это совсем не сложно, вопрос в том будет ли кто-то в рамках небольшой организации использовать такое приложение для хранения заметок сотрудников?

2) Какие еще функии вы бы добавили?

3) Может кто-то видел хороший тьюториал о локализации JS приложений? (Сейчас я ориентируюсь на то, как сделана локализация в jQuery UI).

P.S. На этих выходных я уезжаю догуливать остатки отпуска, поэтому прошу прощения, если не сразу отвечу на ваши комментарии. Я обязательно их прочитаю… даже спаммерские

В предыдущих частях (1, 2, 3, 4, 5, 6, 7, 8, 9) мы создали практически работоспособную систему отслеживания ошибок.

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

Сегодня мы исправим этот недостаток.

Напомню, что на стороне сервера поддержка вложенных комментариев уже реализована. В базе данных (таблица comments) есть поле parent_id в котором хранится id родительского комментария.

Кроме того, метод addComment (модели mcomments) принимает массив с данными комментария, одним из полей которого является parent_id.

И, наконец, метод addcomment контроллера читает этот параметр из массива $_POST и передает его модели.

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

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

Ситуация совершенно меняется если использовать JavaScript. Под каждым комментарием мы создадим ссылку «Ответить». При клике по ней форма будет перемещаться под выбранный комментарий. Id этого комментария мы сохраним в скрытом поле формы.

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

Переходим к реализации.

Прежде всего, рассмотрим разметку формы.

<form id="fAddComment" method="post" action="http://www.bugtracker.l/bugtracker/addcomment">
	...
	<div>
		<input type="hidden" value="" id="parent_id" name="parent_id"/>
	</div>
	<p>
		<input type="submit" value="Отправить" class="addcomment" id="addcomment" name="addcomment"/>
	</p>
</form>

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

Теперь подключим два JavaScript файла. Первый – библиотека jQuery, второй – файл с нашими функциями.

<script type="text/javascript" src="<?php echo base_url(); ?>js/jquery-1.3.2.min.js"></script>
<script type="text/javascript" src="<?php echo base_url(); ?>js/main.js"></script>

Примечание. Я разместил этот код в конце страницы (в представлении footer.php).

Добавляем ссылку «Ответить» внизу каждого комментария. Для этого открываем шаблон комментариев (\application\views\comment_tpl.php)

<div class="comment depth-{depth}" id="comment-{id}">
	<p class="commentInfo">
		<span class="commentAuthor">Автор: {uname}.</span>
		<span class="commentDate">Дата: {comment_date}.</span>
	</p>
	<p class="commentDescription">{description}</p>
	<p class="replyComment"><a href="#">Ответить</a></p>
<?php
if ($this->redux_auth->logged_in()) {
	echo '<p class="deleteComment">'.anchor('bugtracker/deletecomment/{id}', 'Удалить').'</p>';
}
?>
</div>

Ссылка создается в строке 7. Тут может возникнуть вопрос: «Почему в параметрах ссылки мы не указываем id комментария?». Дело в том, что с помощью jQuery мы можем легко получить родительский div (строка 1) и прочесть его атрибут id, в котором записан id комментария.

Теперь рассмотрим функцию, которая перемещает форму (файл main.js).

$(function() {
	//перемещаем форму
	$(".replyComment a").click(function() {
		var comment = $(this).parent().parent();
		var commentId = comment.attr("id");
		var id = Array();
		//в id[1] будет сохранен id комментария на который нужно ответить
		id = commentId.split('-');

		//перемещаем форму
		$("#fAddComment").appendTo(comment);

		//устанавливаем значение в поле parent_id
		$("#parent_id").val(id[1]);

		//добавляем ссылку "Отменить комментарий", клик по ней возвращает форму вниз страницы
		cancelComment = $("<p class=\"cancelComment\"><a href=\"#\">Отменить комментарий</a></p>");
		cancelComment.prependTo($("#fAddComment"));
		var cancelLink = cancelComment.children("a").get(0);
		$(cancelLink).click(function() {
			$("#parent_id").val("");
			$(this).parent().remove();
			$("#fAddComment").insertBefore("#footer");

			return false;
		});

		//предотвращает "скачки" страницы
		return false;
	});

	//подтверждение удаления бага
	$(".deleteBug a").click(function() {
		return confirm("Точно удалить?");
	});

	//подтверждение удаления комментария
	$(".deleteComment a").click(function() {
		return confirm("Будет удалена ветка комментариев начиная с данного. Удалить?");
	});
});

Рассмотрим как она работает.

Прежде всего, мы находим все ссылки, которые находятся внутри элементов с классом «replyComment» (т.е. наши ссылки «Ответить»), и назначаем им обработчик события onclick (строка 3).

При клике по ссылке начинает выполняться функция (строки 3-30). Алгоритм тут следующий.

1) Получаем родительский div и читаем его атрибут id (строки 4, 5).

2) Вырезаем из него номер комментария (с помощью функции split, строка 8).

3) Перемещаем форму. Для этого мы используем функцию appendTo из библиотеки jQuery. Элемент, к которому нужно добавить форму мы получили на 1-ом шаге.

4) Записываем значение в поле parent_id (строка 14).

5) Создаём ссылку «Отменить комментарий» и размещаем её в начале формы. Клик по ней вернет форму в исходное положение.

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

6) Находим ссыку «Отменить комментарий» и назначем ей обработчик события onclick (строки 19-26).

7) В этом обработчике мы сбрасываем значение скрытого поля parent_id, удаляем ссылку «Отменить комментарий» и возвращаем форму в исходное положение.

Как видите, принцип работы достаточно простой. А благодаря jQuery вся функция занимает меньше 20 строк (если убрать комментарии и пустые строки).

В завершение мы выполняем ещё два действия.

Назначаем обработчик события onclick для всех ссылок «Удалить» (строки 33-40). Теперь при попытке удаления бага или комментария (в администраторском режиме) будет появляться диалог с просьбой подтвердить действие.

На этом я закончу эту часть.

Демо версия баг трекера.

Если у вас есть желание поэкспериментировать я выложил демо версию баг трекера. Логин: vvv@ddd.sss, пароль: 111.
Можете не задумываясь вставлять или удалять любые данные, все равно у меня есть бекап базы

Скачать

Также можно скачать архив с исходниками.

И, конечно, вы можете поделиться своими впечатлениями в комментариях

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

Но при этом не решенным остался вопрос локализации.

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

В этой части я расскажу, как перевести эти сообщения на русский язык.

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

Например, правила для проверки email выглядят следующим образом.

$this->form_validation->set_rules('email', 'lang:email', 'required|valid_email');

Здесь мы вызываем метод set_rules из библиотеки form_validation. В первом параметре указываем имя поля в форме (атрибут name), во втором – его описание, в третьем – правила.

Сейчас нас интересует второй параметр. Нам нужно, чтобы CodeIgniter подставил вместо него правильное описание поля.

Для этого нужно выполнить 4 шага.

1) Открываем файл \application\config\config.php и устанавливаем язык по-умолчанию.

$config['language']	= "russian";

Теперь CodeIgniter будет прежде всего искать файлы с описаниями в папке \application\language\russian.

2) Создаем папку \application\language\russian и в ней файл form_fields_lang.php. Обратите внимание: окончание _lang обязательно.

3) В этом файле создаем массив с описаниями полей:

<?php
$lang['title'] = '"Заголовок"';
$lang['uname'] = '"Ваше имя"';
$lang['category_id'] = '"Категория ошибки"';
$lang['description'] = '"Описание ошибки"';
$lang['email'] = '"eMail"';
$lang['password'] = '"Пароль"';
?>

Ключи элементов этого массива должны совпадать с именами, которые указаны после lang: (во втором параметре метода set_rules).

4) Загружаем файл с описаниями полей. Для этого в конструктор контроллера добавляем строку.

$this->load->language('form_fields');

Обратите внимание. Окончание _lang.php не указываем.

После этих манипуляций описания полей будут правильно отображаться. Но сами ошибки будут на английском.

Для их руссификации нужно скачать файлы с переводами.

Архив распаковываем в папку \application\language\russian.

Всё. На этом работа заканчивается. Названия этих файлов совпадают с названиями их английских версий, поэтому CodeIgniter загрузит их автоматически.

Заключение.

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

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

Я не ставил задачи сделать мультиязычное приложение, но если этот пункт для вас важен, в CodeIgniter входит Language Helper для этих целей. Использовать его не сложно, самый трудоёмкий этап – создание файлов с переводами. И нужно внимательно следить, чтобы в исходниках проекта напрямую не был жестко прописан текст.

До встречи!

P.S. Думаю, к следующему выпуску будет готова демонстрационная версия баг трекера. И безусловно выложу архив файлами проекта.

Приветствую всех читателей!

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

Для начала сформулируем задачу.

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

На практике это будет выглядеть следующим образом. Администратор при входе вводит имя и пароль. Баг трекер их проверяет и, если они совпадают с записанными в базе данных, добавляет к каждому багу и комментарию ссылку «Удалить».

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

Для справки. Эти проверки называются аутентификация и авторизация.

Авторизация (англ. authorization) — процесс предоставления определенному лицу прав на выполнение некоторых действий.

Аутентификация (англ. Authentication) — процедура проверки соответствия некоего лица и его учетной записи в компьютерной системе.

(цитаты из википедии)

Таким образом, при входе в систему нам нужно аутентифицировать администратора, а при выполнении им операции – авторизовать.

Задача, в общем-то, стандартная и для её решения написано множество библиотек разной степени сложности.

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

1) Создание учетной записи в базе данных.

2) Проверка имени и пароля при входе в систему (аутентификация).

3) Проверка прав пользователя на выполнение операции (авторизация).

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

Для этого проекта я решил использовать библиотеку под названием Redux. Каких-то особых причин, по которым я на ней остановился, нет. Просто видел несколько хороших отзывов, и захотелось поэкспериментировать.

На данный момент есть две версии библиотеки: 1.4а (стабильная) и 2 (бета). Вторая по своим возможностям мне понравилась больше, поэтому и использовал я именно её. Но бета есть бета, и сразу обнаружилось несколько недостатков.

Самое главное, в архиве 2-ой версии нет документации, есть только демонстрационный пример. Полноценная справка написана для версии 1.4, причем очень хорошая, сделана в том же стиле, что и тьюториал CodeIgniter.

Используя пример и справку из версии 1.4, разобраться не сложно.

Теперь рассмотрим, что нужно сделать для подключения этой библиотеки к нашему приложению.

1) Скачать и распаковать архив.

2) Скопировать 3 файла:
\application\config\redux_auth.php
\application\models\redux_auth_model.php
\application\libraries\redux_auth.php

3) Импортировать файл database.sql в базу данных. При этом будут созданы несколько таблиц.

4) Настроить библиотеку. Для этого, открываем файл \application\config\redux_auth.php и изменяем соответствующие значения. Здесь я только отключил активацию по email.

$config['email_activation'] = false;

5) Создаем группу, которая используется по-умолчанию. В файле \application\config\redux_auth.php есть параметр

$config['default_group'] = 'member';

Чтобы библиотека нормально заработала нужно создать в таблице groups запись с название этой группы. Т.е. name='member', description='member group description'.

6) В таблице sessions изменяем сравнение для поля user_data на utf8_general_ci, иначе будут проблемы с кириллицей.

7) Открываем файл \application\config\config.php и находим раздел с настройками сессий. Я изменил

$config['sess_encrypt_cookie']	= TRUE;
$config['sess_use_database']	= TRUE;
$config['sess_table_name']		= 'sessions';
$config['sess_match_ip']		= TRUE;
$config['sess_match_useragent']	= TRUE;

8 ) Добавляем библиотеку в автозагрузку (файл \application\config\autoload.php).

$autoload['libraries'] = array('database', 'session', 'redux_auth');
$autoload['model'] = array('redux_auth_model');

Теперь нужно создать учетную запись администратора.

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

Для этого, добавим в контроллер (bugtracker) метод register.

function register() {
	$this->redux_auth->register('admin', 'password', 'admin@bugtracker.local');
}

Заходим один раз на страницу bugtracker.local/bugtracker/register и в базе данных появляется новая запись.

После этого метод можно удалить.

Обратите внимание! Для аутентификации Redux использует не имя (admin), а email.

Создаем страницу с формой входа.

Для этого добавляем в контроллер метод login.

function login() {
	if ($this->redux_auth->logged_in()) {
		redirect('bugtracker/page');
	}
	$pageData['title'] = 'Login';
	$this->load->view('header', $pageData);
	$this->load->view('login');
	$this->load->view('footer');
}

Этот метод просто создает страницу с формой. Сама форма находится в представлении \views\login.php.

Перед формированием страницы мы с помощью метода logged_in() проверяем, выполнил ли вход данный пользователь (строки 2-4). И если да, то отправляем его на главную страницу багтрекера.

Теперь рассмотрим представление (\views\login.php)

<?php
$mes = $this->session->flashdata('message');
if (!empty($mes)) {
	echo '<div id="infoMessage">'.$mes.'</div>';
}
?>
<?php echo form_open('bugtracker/checklogin', array('id'=>'fLogin')); ?>
	<p>
	<label for="email">eMail</label>
	<input type="text" name="email" id="email" value="<?php echo set_value('email'); ?>" />
	</p>
	<?php echo form_error('eMail'); ?>
	<p class="even">
	<label for="password">Пароль</label>
	<input type="password" name="password" id="password" value="" />
	</p>
	<?php echo form_error('password'); ?>
	<p><input type="submit" name="bLogin" id="bLogin" class="bLogin" value="Войти" />
	</p>
</form>

Тут все просто. Мы создаем обычную форму с двумя полями: «eMail» и «Пароль». После нажатия на кнопку «Войти» данные будут отправлены методу checklogin контроллера (строка 7).

Этот метод выполняет аутентификацию пользователя. Проще говоря проверяет соответствие email'а паролю.

function checklogin() {
	$this->load->library('form_validation');
	$this->form_validation->set_rules('email', 'lang:email', 'required|valid_email');
	$this->form_validation->set_rules('password', 'lang:password', 'required');
	$this->form_validation->set_error_delimiters('<div class="fErrMessage">', '</div>');

	if ($this->form_validation->run() == false)
	{
		$pageData['title'] = 'Login error';
		$this->load->view('header', $pageData);
		$this->load->view('login');
		$this->load->view('footer');
	}
	else
	{
		$login    = $this->input->post('email');
		$password = $this->input->post('password');

		if ($this->redux_auth->login($login, $password)) {
			$this->session->set_flashdata('message', 'Привет, '.$login);
			redirect('bugtracker/page');
		}
		else {
			$this->session->set_flashdata('message', 'Неверная пара логин/пароль, попробуйте ещё раз');
			redirect('bugtracker/login');
		}
	}
}

Прежде всего, мы поверяем корректность заполнения формы. Для этого создаем правила (строки 3, 4) и выполняем проверку (сторока 7). Если форма заполнена правильно (данные введены), то с помощью метода login($login, $password) (строка 19) ищем посетителя в базе данных.

Если соответствующая запись в БД будет найдена, отправляем его на главную (строка 21). При этом библиотека сама сохранит данные этого пользователя в сессии. И в дальнейшем мы сможем использовать метод logged_in() для авторизации пользователя.

Если email или пароль введены не правильно, то показываем посетителю форму ещё раз с предложением попробовать ещё раз.

Теперь рассмотрим метод удаления записи о баге.

function deletebug($bugId) {
	if ($this->redux_auth->logged_in()) {
		if ($this->mbug->delete($bugId)) {
			$this->session->set_flashdata('message', 'Баг удален');
			redirect($this->session->userdata('prev_page'));
		}
		else {
			$this->session->set_flashdata('message', 'При удалении бага возникла ошибка');
			redirect($this->session->userdata('prev_page'));
		}
	}
	else {
		$this->session->set_flashdata('message', 'Вы должны войти для того, чтобы выполнить это действие');
		redirect('bugtracker/login');
	}
}

Во второй строке мы выполняем авторизацию пользователя. И в зависимости от её результатов либо удаляем баг (строки 3-10), либо отправляем посетителя на страницу с формой входа (строки 13, 14).

Т.е. если кто-то, не выполнив вход, попробует отправить запрос bugtracker.local/bugtracker/deletebug/1, то он увидит сообщение 'Вы должны войти для того, чтобы выполнить это действие' и форму ввода email и пароля.

В шаблонах багов и комментариев (bug_tpl.php и comment_tpl.php) также добавим несколько строк:

if ($this->redux_auth->logged_in()) {
	echo '<p class="deleteBug">'.anchor('bugtracker/deletebug/{id}', 'Удалить').'</p>';
}

Таким образом, администраторы увидят ссылку «Удалить» рядом с каждым багом и комментарием.

Примечание. Подробнее об этих шаблонах можно почитать в четвертой части.

И последний момент. Нужно дать возможность администратору выйти из приложения.

Для этого создаем метод logout.

function logout()
{
	$this->redux_auth->logout();
	$this->session->set_flashdata('message', 'Вы вышли из администраторского режима');
	redirect('bugtracker/page');
}

После выхода (строка 2) мы сохраняем в сессии сообщение и отправляем редирект на главную страницу.

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

P.S. Если возникли вопросы или есть замечания, пишите, постараюсь ответить

В этой части цикла статей о разработке баг трекера мы рассмотрим добавление записей о багах и комментариев к ним.

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

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

Кроме того, нужно сразу решить вопрос с тегами и защитой от XSS атак.

Проблема следующая. Если разрешить пользователям вставлять в текст описания багов любые HTML теги и не выполнять никаких проверок, то кто угодно сможет провести любую XSS атаку. Например, вставить скрипт с редиректом на свой ресурс.

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

Решить проблему можно с помощью bbCodes или фильтрацией части тегов. Например, теги script удаляем, а strong – не трогаем.

Я решил выбрать второй вариант. Тем более что его не сложно реализовать с помощью библиотеки HTML Purifier. Кроме фильтрации опасных тегов, библиотека исправляет ошибки в разметке. Например, добавляет закрывающие теги.

Подключение HTML Purifier к CodeIgniter.

Я использовал вот эту инструкцию. Правда, я создал для библиотеки отдельную папку (\application\libraries\htmlpurifier).

После этого нужно закомментировать строку
require 'HTMLPurifier.php';
в файле HTMLPurifier.includes.php.

А в файл HTMLPurifier.php (сразу после <?php) добавить
require_once('HTMLPurifier.includes.php');

Подключается библиотека так:

$this->load->library('htmlpurifier/HTMLPurifier');

Теперь рассмотрим алгоритм добавления записи о баге.

Сначала мы проверяем данные с помощью встроенной библиотеки form_validation. Для её работы нужно установить правила для каждого поля формы.

Полей у нас 5: заголовок, имя пользователя, eMail пользователя, категория и описание бага.

Если проверка прошла, мы обрабатываем данные с помощью HTML Purifier и добавляем их в базу. Читаем из сессии адрес последней страницы, на которой находился посетитель. И отправляем ему редирект с адресом этой страницы. Т.к. у нас есть несколько страниц, на которых находится форма добавления бага (главная, страницы категорий), то пользователь, скорее всего, захочет остаться на той странице, с которой он отправлял сообщение.

Если во время проверки возникли ошибки – формируем страницу с этой же формой и описаниями ошибок и отправляем её посетителю.

Теперь посмотрите на код метода addbug.

function addbug() {
	$this->load->library('form_validation');
	$this->form_validation->set_error_delimiters('<div class="fErrMessage">', '</div>');
	$this->form_validation->set_rules('title', 'lang:title', 'required');
	$this->form_validation->set_rules('uname', 'lang:uname', 'required');
	$this->form_validation->set_rules('category_id', 'lang:category_id', 'required|integer');
	$this->form_validation->set_rules('description', 'lang:description', 'required');
	$this->form_validation->set_rules('email', 'lang:email', 'required|valid_email');
	if ($this->form_validation->run() === FALSE) {
		//ошибка
		$pageData['message'] = 'Форма заполнена неправильно';

		//показываем форму с описаниями ошибок
		$pageData['title'] = 'Bug Tracker';
		$pageData['categories'] = $this->mcategory->getAllCategories();

		$this->load->view('header', $pageData);
		$this->load->view('categories');
		$this->load->view('addbugform');
		$this->load->view('footer');
	}
	else {
		//форма заполнена правильно
		$this->load->library('htmlpurifier/HTMLPurifier');
		$config = HTMLPurifier_Config::createDefault();

		$bugData['title'] = $this->htmlpurifier->purify($this->input->post('title'));
		$bugData['uname'] = $this->htmlpurifier->purify($this->input->post('uname'));
		$bugData['category_id'] = $this->input->post('category_id');
		$bugData['uemail'] = $this->input->post('email');
		$bugData['description'] = $this->htmlpurifier->purify($this->input->post('description'));

		if (($res = $this->mbug->addNewBug($bugData)) !== FALSE) {
			//данные добавлены
			$this->session->set_flashdata('message', 'Сообщение добавлено');
		}
		else {
			//при добавлении данных возникла ошибка
			$this->session->set_flashdata('message', 'При добавлении данных возникла ошибка');
		}

		redirect($this->session->userdata('prev_page'));
	}
}

Как видите, метод работает точно в соответствии с описанным алгоритмом.

Тут стоит обратить внимание на строки 6 и 8. В них мы установили правила (integer, valid_email), которые обеспечивают проверку номера категории и email адреса.

Кроме того, использовать библиотеку HTML Purifier имеет смысл только после обычной проверки. Причин тут две. Во-первых, если пользователь не заполнил какое-то поле формы (а в данном случае они все обязательные), то пытаться удалить теги из него бессмысленно. Во-вторых, если вы все-таки попытаетесь это сделать, то HTML Purifier начинает потреблять кучу ресурсов. Например, использование памяти увеличивается с ~2,6 до 7 МБ.

Ещё один интересный момент связан с использованием сессий. Для вставки сообщений о результатах выполнения операции мы используем метод set_flashdata. Особенность flash данных в том, что они автоматически удаляются после считывания.

Таким образом, посетитель увидит сообщение о добавлении бага только один раз. Если он обновит страницу, то сообщение исчезнет.

Рассмотрим представление, которое создает форму (файл application\views\addbugform.php)

<?php
if (!empty($errMessage)) {
	echo '<div id="errMessage">'.$errMessage.'</div>';
}
$mes = $this->session->flashdata('message');
if (!empty($mes)) {
	echo '<div id="infoMessage">'.$mes.'</div>';
}
?>
<?php echo form_open('bugtracker/addbug', array('id'=>'fAddBug')); ?>
	<?php echo form_error('title'); ?>
	<p>
	<label for="title">Заголовок</label>
	<input type="text" name="title" id="title" value="<?php echo set_value('title'); ?>" />
	</p>
	<?php echo form_error('uname'); ?>
	<p>
	<label for="uname">Ваше имя</label>
	<input type="text" name="uname" id="uname" value="<?php echo set_value('uname'); ?>" />
	</p>
	<?php echo form_error('category_id'); ?>
	<p>
	<label for="category_id">Категория ошибки</label>
	<select name="category_id" id="category_id" size="1">
	<?php
		foreach ($categories as $category) {
			echo '<option value="'.$category['id'].'"';
			echo set_select('category_id', $category['id']);
			echo '>'.$category['name'].'</option>';
		}
	?>
	</select>
	</p>
	<?php echo form_error('email'); ?>
	<p>
	<label for="email">eMail</label>
	<input type="text" name="email" id="email" value="<?php echo set_value('email'); ?>" />
	</p>
	<?php echo form_error('description'); ?>
	<p>
	<label for="description">Описание ошибки</label>
	<textarea name="description" id="description" cols="30" rows="5"><?php echo set_value('description'); ?></textarea>
	</p>
	<p><input type="submit" name="addbug" id="addbug" value="Отправить" />
	</p>
</form>

В начале представления мы выводим сообщения, если они есть. После этого создаем форму.

Форма в общем-то обычная. Обратить внимание стоит на функции вывода ошибок form_error и автоматического заполнения формы set_value. Обратите внимание на восстановление предыдущего значения Select Box (строка 28). В первом параметре метода set_select нужно указать значение атрибута name Select Box.

Теперь переходим к модели (application\models\ mbug.php).

function addNewBug($bugData) {
	$qAddBug = 'INSERT INTO bugs (title, uname, category_id, description, bug_date, uemail)'
		.' VALUES (?, ?, ?, ?, NOW(), ?)';
	$res = $this->db->query($qAddBug, array(
					$bugData['title'],
					$bugData['uname'],
					$bugData['category_id'],
					$bugData['description'],
					$bugData['uemail']
	));
	if ($res) {
		return $this->db->insert_id();
	}
	return $res;
}

Здесь всё просто. В параметре $bugData передается массив с данными из формы. После этого выполняется вставка этих данных в таблицу bugs.

При выполнении запроса все знаки вопроса заменяются исходными данными. При этом автоматически происходит экранирование спецсимволов, что обеспечивает защиту от SQL Injection.

Добавление комментариев.

Этот метод практически не отличается от предыдущего. Тот же алгоритм, те же библиотеки.

Поэтому приводить код для этих методов я не буду.

Конечно в форме только 3 поля: имя, email и текст комментария. Правил проверки меньше. И, конечно, данные вставляются в таблицу comments, а не bugs.

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

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

Сделать ответы на предыдущие комментарии без JavaScript можно, но при этом придется добавлять ещё один select box, содержащий перечень предыдущих комментариев, и пользователь сам должен будет выбрать, на какой комментарий он отвечает. Естественно, это очень неудобно. Поэтому поддержка ответов на предыдущие комментарии будет только при поддержке JavaScript.

До встречи!

P.S. Если возникли вопросы, пишите, попробую ответить

Мы продолжаем разработку собственной системы отслеживания ошибок. И сегодня подробно рассмотрим создание страниц нашего приложения.

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

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

Количество записей на одной странице мы задаем в файле конфигурации (application\config\config.php).

$config['bugs_per_page'] = 5;

Получить значение этого параметра можно так:

$this->config->item('bugs_per_page');

Теперь определимся с названиями методов контроллера и структурой URL.

По-умолчанию, URL в CodeIgniter имеют такой вид:

sitename.domen/index.php/имя_контроллера/имя_метода/параметр1/параметр2/…

Контроллер у нас будет называться bugtracker, а метод, показывающий страницы с багами – page. В результате получим URL с такой структурой:

…/bugtracker/page/номер_записи

В последнем сегменте адреса указываем номер первой записи на текущей странице. Кстати, это не id бага в базе данных, это его индекс в массиве с результатами поиска по БД.

Создаём контроллер (application\controllers\bugtracker.php)

class BugTracker extends Controller {

	//настройки отображения списка багов
	private $listConf = array(
		'commentOpen'=>'<li class="depth-{depth}">'
	);

	function BugTracker() {
		parent::Controller();

		$this->load->model('mbug');
		$this->load->model('mcategory');
		$this->load->model('mcomment');
		$this->load->library('Table2Tree');
		$this->load->library('session');
		$this->load->helper('form');
	}

	function index() {
		$this->page();
	}

	function page($firstBug = 0) {
	...
	}
}

Как видите, на данный момент он содержит конструктор, в котором мы загрузили модели и несколько библиотек, а также два метода.

1) index – вызывается CodeIgniter’ом если имя метода явно не указано в URL;

2) page($firstBug = 0) – показывает записи о багах начиная с $firstBug.

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

Теперь подробно рассмотрим метод page.

function page($firstBug = 0) {
	if (!is_integer((int)$firstBug)) {
		$firstBug = 0;
	}

	//сохраняем адрес этой страницы в сессии
	$this->session->set_userdata(array('prev_page'=>current_url()));

	$pageData['title'] = 'Bug Tracker';

	//настраиваем разбивку на страницы
	$this->load->library('pagination');
	$pconf['base_url'] = $this->config->item('base_url').'bugtracker/page';
	$pconf['total_rows'] = $this->mbug->getBugsCount();
	$pconf['per_page'] = $this->config->item('bugs_per_page');

	$this->pagination->initialize($pconf);
	$pageData['paginationLinks'] = $this->pagination->create_links();

	//загружаем общий список ошибок и комментариев к ним
	$bugs = $this->mbug->getAllBugs($firstBug, $this->config->item('bugs_per_page'));

	if ($bugs !== false) {
		$bugsTree = $this->table2tree->getTree($bugs, $firstBug, $this->config->item('bugs_per_page'));

		$pageData['bugsList'] = $this->table2tree->getHTMLList($bugsTree, $this->listConf);

	}

	$pageData['categories'] = $this->mcategory->getAllCategories();

	$this->load->view('header', $pageData);
	$this->load->view('categories');
	//размещаем форму отправки сообщений о багах
	$this->load->view('addbugform');
	$this->load->view('allbugs');
	$this->load->view('footer');
}

Его работу можно разделить на следующие этапы.

1) Проверяем параметр и сохраняем адрес текущей страницы в сессии (зачем это нужно я расскажу немного позже).

2) Настраиваем разбивку на страницы (строки 11-18). Для этого загружаем библиотеку pagination, передаём ей массив с параметрами и создаем ссылки. В качестве параметров мы указываем: общее количество записей (получаем с помощью метода getBugsCount()), количество записей, которые нужно показать на странице (читаем из конфига) и первую часть URL ссылок (к нему последним параметром библиотека будет добавлять номер первой записи на очередной странице).

Т.е. если мы показываем по 5 записей на странице, библиотека создаст такие URL:
.../bugtracker/page/
.../bugtracker/page/5
.../bugtracker/page/10
…

После этого мы загружаем список багов для данной страницы (строка 21). Запрос, который формирует этот список мы рассматривали в прошлый раз.

3) С помощью библиотеки table2tree мы преобразуем таблицу с данными о багах в HTML список (строки 23-28).

4) Загружаем список категорий (строка 30). Он используется для создания навигации по баг трекеру.

5) Показываем страницы (строки 32-37). Для этого загружаем представления и передаем им параметры.

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

Поэтому сейчас я просто приведу краткое описание всех представлений. Все они находятся в папке (application\views):

header.php – формирует заголовок страницы, загружает JavaScript и CSS файлы;
categories.php – формирует список с перечнем категорий (используется для навигации);
addbugform.php – форма добавления записи о найденном баге;
allbugs.php – показывает список багов и строку со ссылками на другие страницы;
footer.php – «хвостовик» страницы.

Создание страницы выбранной категории.

Приводить код этого метода я не буду, т.к. он практически полностью повторяет метод page. Тем не менее, есть несколько нюансов на которых стоит остановиться.

Во-первых, метод контроллера, создающий страницу отдельной категории, называется category и принимает 2 параметра: название категории и номер первой записи на странице.

Т.е. URL имеет такой вид:

…/bugtracker/category/имя_категоии/номер_записи

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

$pconf['uri_segment'] = 4;

В третьих, список багов получаем с помощью метода getBugsByCategory (модель mbugs). В прошлый раз мы рассматривали SQL запрос, который возвращает список багов для указанной категории.

Остальной код полностью повторяет метод page.

Создание страницы отдельного бага (метод bug).

function bug($id = 1) {
	if (!is_integer((int)$id) || (int)$id <= 0) {
		redirect('bugtracker/index');
		return;
	}

	//сохраняем адрес этой страницы в сессии
	$this->session->set_userdata(array('prev_page'=>current_url()));

	//ищем указанный баг
	$bug = $this->mbug->getBug($id);
	if ($bug !== false) {
		$bugTree = $this->table2tree->getTree($bug);

		$pageData['bugList'] = $this->table2tree->getHTMLList($bugTree, $this->listConf);
		$pageData['bug_id'] = $bugTree[0]['id'];
	}

	$pageData['categories'] = $this->mcategory->getAllCategories();

	$this->load->view('header', $pageData);
	$this->load->view('categories');
	$this->load->view('onebug');
	$this->load->view('addcommentform');
	$this->load->view('footer');
}

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

1) Здесь мы не используем библиотеку pagination. В ней просто нет смысла. На странице отображается запись только об одном баге и все комментарии к нему.

2) Данные бага загружаем с помощью метода getHTMLList (строка 15). Кстати, для создания дерева комментариев мы используем собственную библиотеку table2tree. Её методы getTree и getHTMLList автоматически определяют есть ли в исходных данных комментарии и глубину их вложенности.

3) Вместо формы добавления бага вставляем форму добавления комментария (строка 24).

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

До встречи!

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

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

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

Поэтому сегодня постараюсь максимально подробно осветить этот вопрос.

Т.к. индексация страниц баг трекера поисковиками очень желательна, то при разработке имеет смысл придерживаться рекомендаций от Google, а именно методики Progressive Enhancement (постепенного улучшения).

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

После этого, с помощью JavaScript вносятся различные улучшения. Например, без JavaScript при клике на заголовке бага посетитель попадет на страницу с его описанием и комментариями.

Если JavaScript включен, то после загрузки страницы обычные ссылки будут преобразованы в ajax-ссылки и вместо перехода на другую страницу будет подгужен список комментариев.

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

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

1) Страницы с общим перечнем багов. Они будут содержать заголовок и описание бага (без комментариев). Сюда относятся: главная и страницы категорий. Тут же будет форма для добавления сообщения о новом баге.

2) Страницы отдельных багов. Тут будет полная информация о баге и дерево комментариев. Плюс форма добавления комментария.

Кстати, из страниц первого типа можно будет сформировать RSS ленты (как предлагал Алексей Качаев).

Теперь посмотрим, что нам нужно сделать для того, чтобы сформировать содержимое этих страниц.

Как ни странно, но практически вся работа сделана в прошлой части .

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

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

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

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

1) Убрать array_slice. Дело в том, что я сразу не разобрался как ограничить количество результатов, которые возвращает SQL запрос при использовании объединений (JOINS), но потом исправил эту ошибку.

2) Добавить метод getHTMLCommentsList, который будет использоваться для преобразования массива с комментариями (без данных о баге) в HTML список. Этот метод потребуется при загрузке списка комментариев с помощью AJAX.

function getHTMLCommentsList($comments, $config = null) {
	if (!empty($config)) {
		foreach ($config as $key => $value) {
			$this->config[$key] = $value;
		}
	}
	$this->CI->load->library('parser');
	$html = $this->_convert2HTMLList($comments, 0);
	return $html;
}

Этот метод по сути представляет собой оболочку, для _convert2HTMLList, описанного в прошлой части.

3) Добавить проверку наличия полей с данными о комментариях (в методе _convert2SimpleTree). Т.к. теперь этот метод может получить данные багов как с комментариями так и без них.

Исходники библиотеки можно скачать в виде архива. Ссылка в конце страницы.

Кроме того, я думаю, не стоит отказываться от возможности получения полного списка багов с комментариями. По крайней мере, есть один случай, в котором это может быть полезно. Речь о том, что кроме RSS можно организовать отправку сообщений о новых багах на eMail, например, раз в день. И в таких письмах имеет смысл отправить не только описания багов, но и комментарии к ним. Ведь если между добавлением бага и отправкой письма может пройти несколько часов, то, скорее всего и комментарии появятся.

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

1) Получение списка багов (используется для создания главной страницы и страниц категорий).

SELECT b.* , c.link, c.name AS category
	FROM bugs AS b
	LEFT JOIN categories AS c ON b.category_id = c.id
	ORDER BY b.bug_date DESC LIMIT ?, ?

Обратите внимание на LIMIT в конце запроса. С его помощью мы ограничиваем число багов на странице. Естественно, при этом будет использоваться библиотека пагинации из CodeIgniter.

2) Получение списка багов для выбранной категории.

SELECT COUNT(b.id) AS catsnum FROM bugs AS b
	LEFT JOIN categories AS c ON b.category_id = c.id
	WHERE c.link=?

3) Получение подробной информации о баге и всех его комментариев.

SELECT b.*, c.link, c.name AS category,
	cm.id AS c_id, cm.uname AS c_uname, cm.description AS c_description,
	cm.comment_date, cm.parent_id, cm.bug_id, cm.uemail AS c_uemail
	FROM bugs AS b
	LEFT JOIN categories AS c ON b.category_id=c.id
	LEFT JOIN comments AS cm ON b.id=cm.bug_id WHERE b.id=?

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

5) Получение списка багов и комментариев (я приводил этот запрос в прошлый раз, но сейчас немного изменил его и ввел ограничение на количество полей).

SELECT b.* , c.link, c.name AS category, cm.id AS c_id,
	cm.uname AS c_uname, cm.description AS c_description,
	cm.comment_date, cm.parent_id, cm.bug_id, cm.uemail AS c_uemail
	FROM comments AS cm
	RIGHT JOIN (
		SELECT * FROM bugs ORDER BY bugs.bug_date DESC
		LIMIT ?, ?
	) b ON b.id = cm.bug_id
	LEFT JOIN categories AS c ON b.category_id = c.id

Тут стоит обратить внимание на строку 7.

6) Получение общего количества багов (используется для пагинации)

function getBugsCount() {
	return $this->db->count_all('bugs');
}

Это не SQL запрос Здесь я использовал встроенную функцию CodeIgniter. На самом деле выполняется

SELECT COUNT(*) AS 'numrows' FROM 'bugs'

7) Получение общего количества багов в выбранной категории

SELECT COUNT(b.id) AS catsnum FROM bugs AS b
	LEFT JOIN categories AS c ON b.category_id = c.id
	WHERE c.link=?

Я не буду подробно описывать принцип работы каждого запроса. В прошлой части я довольно подробно останавливался на одном из самых сложных (пятый запрос в этом списке). Самое главное четко представлять как работают объединения таблиц (JOINS).

Вместо вопросительно знака в запросы будут подставлены конкретные данные.

В завершение приведу ссылку на ахив с исходниками библиотеки table2tree.

Как видите, изменений минимум. На этом примере очень хорошо видно одно из основных преимуществ архитектуры MVC. За счет того, что вся работа с базой данных вынесена в модель можно расширять возможности приложения практически без изменений в остальной части кода.

До встречи!

P.S. Как всегда я рад выслушать любые замечания и предложения.

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

Напомню, в прошлый раз мы решили, что все для хранения записей о багах и комментариях к ним будем использовать две таблицы: bugs и comments.

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

Теперь переходим к созданию списка.

Чтобы лучше понять задачу рассмотрим html разметку, которую нам нужно получить.

<ul>
	<li>
		Описание бага №1
		<ul>
			<li>Комментарий 1</li>
			<li>
				Комментарий 2
				<ul>
					<li>Ответ на комментарий 2</li>
				</ul>
			</li>
		</ul>
	</li>
	<li>
		Описание бага №2
		<ul>
			<li>Комментарий 1 к багу 2</li>
			...
		</ul>
	</li>
</ul>

Как видите, разметка достаточно простая. Мы создаем список, каждый элемент которого соответствует записи о баге. Если к этому багу оставлены комментарии, то они размещаются во вложенном списке. Вкладывая такие списки друг в друга, мы формируем дерево комментариев.

Таким образом, нам нужно преобразовать данные из таблиц в дерево.

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

Теперь посмотрим, каким образом можно сформировать такой список. Есть несколько вариантов.

Можно решать задачу «в лоб». Т.е. первым запросом найти все записи о багах (напомню, у всех таких записей поле parent_id = NULL). А после этого в цикле отправлять запросы поиска комментариев к каждому из найденных багов. Недостаток такого подхода – большое количество запросов к БД.

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

Остановимся мы, конечно, на втором варианте.

И, прежде всего, нам нужно получить данные. Для этого создаем модель, назовем её mbug (application\models\mbugs.php), и метод getAllBugsWithComments.

class MBug extends Model {

	function MBug() {
		parent::Model();
	}

	/**
	 * Ищет все баги и комментарии к ним. Баги возвращаются начиная с последнего добавленного.
	 *
	 * @return массив со всеми багами и комментариями к ним, FALSE - если ничего не найдено
	 */
	function getAllBugsWithComments() {
		$qGetAll = 'SELECT b.*, c.link, c.name AS category,'
			.' cm.id AS c_id, cm.uname AS c_uname, cm.description AS c_description,'
			.' cm.comment_date, cm.parent_id, cm.bug_id, cm.uemail AS c_uemail'
			.' FROM bugs AS b'
			.' LEFT JOIN categories AS c ON b.category_id=c.id'
			.' LEFT JOIN comments AS cm ON b.id=cm.bug_id'
			.' ORDER BY b.bug_date DESC';
		$res = $this->db->query($qGetAll);
		if ($res->num_rows() <= 0) {
			return false;
		}
		return $res->result_array();
	}
}

Работает метод getAllBugsWithComments предельно просто. Он выполняет запрос к БД и возвращает результат его выполнения в виде массива.

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

Поэтому в запросе мы выполняем объединение трех таблиц (bugs, categories, comments). Рассмотрим, как выполняется это объединение.

Прежде всего, обратите внимание на то, что таблицы объединяются слева направо (LEFT JOIN). На первом этапе объединяются таблицы bugs и categories. Т.к. каждому багу соответствует только одна категория, то в результате мы получим исходную таблицу bugs с двумя новыми столбцами link и name из таблицы categories.

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

На следующем этапе происходит объединение с таблицей comments. Тут возможны два варианта.

Первый – очередной баг не имеет комментариев. В этом случае в результирующей таблице будет одна строка со сведениями из таблиц bugs и categories, а все поля, соответствующие таблице comments будут иметь значения NULL.

Второй – очередной баг имеет один или более комментариев. Тогда в результирующей таблице будет одна или более строк с данными из таблиц bugs, categories и comments. Причем количество таких строк определяется количеством комментариев.

Посмотрите на пример такой таблицы (я опустил часть полей).

Переходим к преобразованию этой таблицы в HTML список.

Т.к. операция довольно сложная, то будет удобно написать для неё небольшую библиотеку – Table2Tree.

Для этого создаём файл application\libraries\table2tree.php (название файла совпадает с названием библиотеки).

Но, прежде чем переходить к описанию библиотеки, рассмотрим пример её использования. Допустим, у нас есть контроллер (bugtracker) с методом page (формирует страницу со списком багов и комментариев).

class BugTracker extends Controller {

	//настройки отображения списка багов
	private $listConf = array(
		'commentOpen'=>'<li class="depth-{depth}">'
	);

	function BugTracker() {
		parent::Controller();

		$this->load->model('mbug');
		$this->load->library('Table2Tree');
	}

	function page($firstBug = 0) {
		...
		//загружаем общий список ошибок и комментариев к ним
		$bugs = $this->mbug->getAllBugsWithComments();

		if ($bugs !== false) {
			$bugsTree = $this->table2tree->getTree($bugs, $firstBug, $this->config->item('bugs_per_page'));

			$pageData['bugsList'] = $this->table2tree->getHTMLList($bugsTree, $this->listConf);

		}
		//формируем страницу
	}
}

Как видите, в конструкторе мы загрузили нашу библиотеку (Table2Tree) и модель (mbug).

Метод page() работает следующим образом.

1) Получаем список багов с комментариями (с помощью метода getAllBugsWithComments модели).

2) Преобразовываем полученную таблицу в многомерный массив (метод getTree нашей библиотеки).

3) Преобразовываем многомерный массив в HTML список (метод getHTMLList).

На втором и третьем этапе я хочу остановиться подробнее. Основной вопрос тут: что представляет собой многомерный массив и зачем он вообще нужен.

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

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

[0]=>
	‘title’=>’Описание бага №1’
	...
	‘comments’=>
		[0]=>
			‘description’=>’Комментарий 1’
		[1]=>
			‘description’=>’Комментарий 2’
			‘comments’=>
				[0]=>
					‘description’=>’Ответ на комментарий 2’
[1]=>
	‘title’=>’Описание бага №2’
	...
	‘comments’=>
		[0]=>
			‘description’=>’Комментарий 1 к багу 2’

Используя такой массив, получить HTML список будет значительно проще.

Теперь рассмотрим, каким образом можно преобразовать результаты поиска по БД в такой массив.

Я решил разбить задачу на 2 этапа.

На первом – формируем массив с багами. В нем каждый элемент будет содержать описание бага и одномерный массив со всеми комментариями к нему.

На втором – преобразуем массивы с комментариями в многомерные (на основании значения в поле parent_id), т.е. формируем дерево комментариев.

Рассмотрим метод getTree

function getTree($data, $firstBug = 0, $count = 1) {
	$sTree = $this->_convert2SimpleTree($data);
	//запоминаем общее количество багов
	$this->bugsCount = count($sTree);
	//оставляем в массиве только те элементы, которые будут отображаться на странице
	$sTree = array_slice($sTree, $firstBug, $count, TRUE);
	foreach ($sTree as $i => $row) {
		if (!empty($row['comments'])) {
			$sTree[$i]['comments'] = $this->_nestedComments($row['comments'], null, 0);
		}
	}
	return $sTree;
}

Он имеет 3 входных параметра:
data – массив с результатами поиска в БД;
firstBug – номер первого бага на странице (используется для пагинации, нет никакого смысла строить дерево комментариев для багов, которые не будут отображаться на странице);
count – количество багов на странице.

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

После этого мы оставляем в массиве только те записи о багах, которые будут отображаться на странице (строка 6).

И формируем дерево комментариев. Для этого мы проходим в цикле по всем элементам массива и с помощью метода _nestedComments преобразовываем массив comments в многомерный.

Рассмотрим метод _convert2SimpleTree

function _convert2SimpleTree($bugs) {
	$bugRes = array();
	$currentBugId = 0;
	$i = -1;
	$j = 0;
	foreach ($bugs as $bug) {
		if ($bug['id'] != $currentBugId) {
			$currentBugId = $bug['id'];
			$i++;
			//заполняем массив данными о баге
			$bugRes[$i]['id'] = $bug['id'];
			$bugRes[$i]['title'] = $bug['title'];
			$bugRes[$i]['uname'] = $bug['uname'];
			$bugRes[$i]['category_id'] = $bug['category_id'];
			$bugRes[$i]['description'] = $bug['description'];
			$bugRes[$i]['status'] = $bug['status'];
			$bugRes[$i]['bug_date'] = $bug['bug_date'];
			$bugRes[$i]['uemail'] = $bug['uemail'];

			//данные о категории
			$bugRes[$i]['link'] = $bug['link'];
			$bugRes[$i]['category'] = $bug['category'];

			//создаем массив с комментариями
			if ($bug['c_id'] != NULL) {
				$bugRes[$i]['comments'] = array();
				$j = 0;
				$bugRes[$i]['comments'][$j]['id'] = $bug['c_id'];
				$bugRes[$i]['comments'][$j]['uname'] = $bug['c_uname'];
				$bugRes[$i]['comments'][$j]['description'] = $bug['c_description'];
				$bugRes[$i]['comments'][$j]['comment_date'] = $bug['comment_date'];
				$bugRes[$i]['comments'][$j]['parent_id'] = $bug['parent_id'];
				$bugRes[$i]['comments'][$j]['bug_id'] = $bug['bug_id'];
				$bugRes[$i]['comments'][$j]['uemail'] = $bug['c_uemail'];
				$j++;
			}
		}
		else {
			//добавляем новую запись в массив с комментариями
			$bugRes[$i]['comments'][$j]['id'] = $bug['c_id'];
			$bugRes[$i]['comments'][$j]['uname'] = $bug['c_uname'];
			$bugRes[$i]['comments'][$j]['description'] = $bug['c_description'];
			$bugRes[$i]['comments'][$j]['comment_date'] = $bug['comment_date'];
			$bugRes[$i]['comments'][$j]['parent_id'] = $bug['parent_id'];
			$bugRes[$i]['comments'][$j]['bug_id'] = $bug['bug_id'];
			$bugRes[$i]['comments'][$j]['uemail'] = $bug['c_uemail'];
			$j++;
		}
	}
	return $bugRes;
}

Выглядит он довольно объемным, но большую часть его составляют операторы присвоения. А принцип работы достаточно простой.

В исходной таблице (с результатами из БД) каждому багу может соответствовать несколько строк (в зависимости от количества комментариев).

Поэтому мы перебираем в цикле все строки этой таблицы и если встречаем новый баг (его id отличается от предыдущего), то создаём новый элемент в результирующем массиве и копируем в него данные бага, категории и комментария (если он есть).

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

Продолжение на следующей странице >>