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

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

Модули и кэширование.

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

База данных.

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

Календарь.

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

Пермалинки.

От пермалинков я решил отказаться - это во много раз упрощает анализ строки адреса для CMS. Да и не думаю что пользователю есть большая разница между адресами site.ru/?d=25.11.2010 и site.ru/25.11.2010/

Записи за день.

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

Страницы.

Со страницами тоже пришлось слегка помучаться. Ведь нужно подсвечивать ту страницу, на которой сейчас находится пользователь, а генерировать такой код для каждой страницы - слишком ёмко (особенно если страниц будет штук 30). Вначале я думал вообще отказаться от подсветки, оставив просто генерацию и кэширование списка страниц, но потом в кэш добавил простенькую javascript-функцию, которая анализирует адрес страницы и удаляет ссылку на текущую страницу. С другом немного поспорили на тему того, что у кого-то может быть отключен javascript в браузере, и поисковые боты тоже не работают с ним. Но точно так же они не учитывают ссылку на эту же страницу, а людей без javacript’а я пока не встречал

RSS.

Пожалуй, самым сложным был RSS. Просто потому что я никак не мог найти спецификацию стандарта, и фид до сих пор не проходит валидацию (не понимаю почему).

Панель управления

Наконец, последний штрих - панель администратора. Так как других пользователей или комментариев у меня на сайте не предполагалось, я и не стал создавать пользователей, а логин и пароль прописал в разборе формы. Наиболее убога сейчас именно панель администратора, поскольку она выполняет только 2 наиболее важные функции: добавляет записи и генерирует новые кэши при добавлении новой записи. Тем не менее, я заранее предположил наличие других функций и оставил для них заготовки. И тут появилась новая проблема: при добавлении новой записи, их список изменяется на каждой странице… А это значит что? Правильно, обновлять кэш нужно каждой страницы из списка. Сейчас их всего 4, поэтому это не сильно трудоёмкая задача. Но когда-нибудь их будет сотня, и это будет уже проблемой.

Итоги.

Как итог: при отсутствии кэша вообще, генерация страницы потребляет 0.28MB и 4 SQL-запроса. А при всём валидном кэше - 0.16MB и 0 SQL-запросов. Потребление мизерное, но цифра потребления памяти с кэшированием кажется мне завышенной, поэтому я всё-равно проанализирую код. А пока вы можете понаблюдать за процессом разработки по адресу micro.nerevarin.ru. Ну и желающие, традиционно, могут связаться со мной и поставить себе микроблог.