В комментариях к прошлой части я получил много советов о том, в каком виде лучше получать данные из базы. Я очень признателен всем за эти замечания, т. к. они действительно помогли найти недостатки в прошлой части. Основная проблема была в том, что я не продумал до конца, что именно будет отображаться на страницах баг трекера, но взялся за работу с базой. В общем-то, страниц у баг трекера не много. Первоначально я вообще хотел сделать одностраничное приложение, но передумал из-за проблем с индексацией поисковиками. Поэтому сегодня постараюсь максимально подробно осветить этот вопрос. Т. к. индексация страниц баг трекера поисковиками очень желательна, то при разработке имеет смысл придерживаться рекомендаций от Google, а именно методики Progressive Enhancement (постепенного улучшения). Идея следующая. Нужно сделать приложения так, чтобы без поддержки JavaScript (только с помощью обычных ссылок) можно было получить доступ к любой информации (багам и комментариям). После этого, с помощью JavaScript вносятся различные улучшения. Например, без JavaScript при клике на заголовке бага посетитель попадет на страницу с его описанием и комментариями. Если JavaScript включен, то после загрузки страницы обычные ссылки будут преобразованы в ajax-ссылки и вместо перехода на другую страницу будет подгужен список комментариев.
.jpg)
Кроме того, не правильно показывать на одной странице одновременно несколько багов вместе с комментариями (как я планировал раньше). Во-первых, если комментарии содержат рисунки, то такая страница будет долго грузиться. Во-вторых, получится, что отдельные страницы багов будут дублировать главную, а, насколько я знаю, поисковики это не любят (дублирование контента). В результате получается, что для работы баг трекера нужны страницы двух типов. 1) Страницы с общим перечнем багов. Они будут содержать заголовок и описание бага (без комментариев). Сюда относятся: главная и страницы категорий. Тут же будет форма для добавления сообщения о новом баге. 2) Страницы отдельных багов. Тут будет полная информация о баге и дерево комментариев. Плюс форма добавления комментария. Кстати, из страниц первого типа можно будет сформировать RSS ленты (как предлагал Алексей Качаев).
.jpg)
Теперь посмотрим, что нам нужно сделать для того, чтобы сформировать содержимое этих страниц. Как ни странно, но практически вся работа сделана в прошлой части . У нас есть библиотека, которая позволяет преобразовывать таблицу с багами и комментариями в html списки. При этом совершенно не важно, сколько багов и комментариев находится в этой таблице. Например, если мы получим из базы таблицу только с информацией о багах (без комментариев), то сможем точно также сформировать html список. Кроме того, у нас есть шаблоны для отображения багов и комментариев. И совершенно неважно как их использовать, для создания списка багов с комментариями или без них. Тем не менее, в библиотеку нужно внести несколько мелких исправлений, чтобы сделать её более универсальной. 1) Убрать array_slice. Дело в том, что я сразу не разобрался как ограничить количество результатов, которые возвращает SQL запрос при использовании объединений (JOINS), но потом исправил эту ошибку. 2) Добавить метод getHTMLCommentsList, который будет использоваться для преобразования массива с комментариями (без данных о баге) в HTML список. Этот метод потребуется при загрузке списка комментариев с помощью AJAX.