В комментариях к прошлой части я получил много советов о том, в каком...

В комментариях к прошлой части я получил много советов о том, в каком виде лучше получать данные из базы. Я очень признателен всем за эти замечания, т. к. они действительно помогли найти недостатки в прошлой части. Основная проблема была в том, что я не продумал до конца, что именно будет отображаться на страницах баг трекера, но взялся за работу с базой. В общем-то, страниц у баг трекера не много. Первоначально я вообще хотел сделать одностраничное приложение, но передумал из-за проблем с индексацией поисковиками. Поэтому сегодня постараюсь максимально подробно осветить этот вопрос. Т. к. индексация страниц баг трекера поисковиками очень желательна, то при разработке имеет смысл придерживаться рекомендаций от Google, а именно методики Progressive Enhancement (постепенного улучшения). Идея следующая. Нужно сделать приложения так, чтобы без поддержки JavaScript (только с помощью обычных ссылок) можно было получить доступ к любой информации (багам и комментариям). После этого, с помощью JavaScript вносятся различные улучшения. Например, без JavaScript при клике на заголовке бага посетитель попадет на страницу с его описанием и комментариями. Если JavaScript включен, то после загрузки страницы обычные ссылки будут преобразованы в ajax-ссылки и вместо перехода на другую страницу будет подгужен список комментариев.

В комментариях к прошлой части я получил много советов о том, в каком...

Кроме того, не правильно показывать на одной странице одновременно несколько багов вместе с комментариями (как я планировал раньше). Во-первых, если комментарии содержат рисунки, то такая страница будет долго грузиться. Во-вторых, получится, что отдельные страницы багов будут дублировать главную, а, насколько я знаю, поисковики это не любят (дублирование контента). В результате получается, что для работы баг трекера нужны страницы двух типов. 1) Страницы с общим перечнем багов. Они будут содержать заголовок и описание бага (без комментариев). Сюда относятся: главная и страницы категорий. Тут же будет форма для добавления сообщения о новом баге. 2) Страницы отдельных багов. Тут будет полная информация о баге и дерево комментариев. Плюс форма добавления комментария. Кстати, из страниц первого типа можно будет сформировать RSS ленты (как предлагал Алексей Качаев).

В комментариях к прошлой части я получил много советов о том, в каком...

Теперь посмотрим, что нам нужно сделать для того, чтобы сформировать содержимое этих страниц. Как ни странно, но практически вся работа сделана в прошлой части . У нас есть библиотека, которая позволяет преобразовывать таблицу с багами и комментариями в html списки. При этом совершенно не важно, сколько багов и комментариев находится в этой таблице. Например, если мы получим из базы таблицу только с информацией о багах (без комментариев), то сможем точно также сформировать html список. Кроме того, у нас есть шаблоны для отображения багов и комментариев. И совершенно неважно как их использовать, для создания списка багов с комментариями или без них. Тем не менее, в библиотеку нужно внести несколько мелких исправлений, чтобы сделать её более универсальной. 1) Убрать array_slice. Дело в том, что я сразу не разобрался как ограничить количество результатов, которые возвращает SQL запрос при использовании объединений (JOINS), но потом исправил эту ошибку. 2) Добавить метод getHTMLCommentsList, который будет использоваться для преобразования массива с комментариями (без данных о баге) в HTML список. Этот метод потребуется при загрузке списка комментариев с помощью AJAX.

Понравилась статья? Получай обновления и будь всегда в курсе событий!
Подпишись на RSS или
blog comments powered by Disqus