Своя CMS: форум

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

Функции модуля

• Собственно общение. Форум будет состоять из категорий, собранных в виде иерархии. В категории могут быть как подкатегории, так и посты. Обязательно предусмотреть ограничение на уровень вложенности категорий (на уровне конфигурационных файлов или вынести в БД?). Сами категории простым пользователям неподвластны, но доступны для управления форумчанам с определенными ролями (об этом ниже). Предусмотреть возможность добавления формы для голосования (ИМХО полезная «фича»).
• Система ролей. Как я уже говорил, авторизация будет использоваться ядром, а данный модуль должен предусматривать наделение пользователей дополнительными ролями. Причем, помимо «бонусных» ролей (модератор, администратор и т.д.) могут быть и «карательные» (система банов и «молчанок»). Управлять всеми этими возможностями должна отдельная библиотека, тестовое название — Supervisor. Насчет нее у меня пока есть вопросы. Дело в том, что похожие механизмы будут и в других модулях (например, в «блоге»). Возможно, если общий алгоритм окажется единым, библиотека будет вынесена в ядро, в обратном случае наверное просто в ядре окажется прототип Supervisor‘а, от которого будут унаследованы библиотеки остальных модулей. Не знаю, стоит ли предусматривать «скрытые» разделы (т.е. возможность добавить ресурсу требование в виде минимально допустимой роли для просмотра). Вроде как с этим вполне может справиться портированная из Zend библиотека A1 (я уже писал о ней).
• Ведение статистики. Я считаю полезными те цифры, которые часто сопровождают топики и категории: количество комментариев, прочтений и т.д. Значит, их надо вести и собирать. Конечно, в каждый контроллер запихивать строчки кода с увеличением счетчика посещений неправильно. Данная задача решается с помощью событий. При любом имеющем значение действии пользователя (открытие страницы, создание/редактирование/удаление объекта) будет генерироваться соответствующий event. А что произойдет дальше — это уже забота подключенных плагинов и библиотек. Так, должна быть базовая статистика (количество топиков в категории к примеру), а что-то должно быть вынесено в необязательный плагин (текущее количество пользователей на форуме).
• Использование средств связи между пользователями. Приватные сообщения весьма востребованная функция, которой я на многих форумах пользуюсь. Поэтому я считаю, что данная возможность должна присутствовать в базовом функционале форума. Хотя можно и предусмотреть ограничение ее использования или вообще отключение.
• Капча. С одной стороны, сегодня это практически обязательный элемент проверки на «человечность». Однако многих она напрягает, поэтому ее надо продумать как плагин. Причем с поддержкой различных драйверов (ведь сейчас существуют не только классические картиночные капчи, но и всякие текстовые вопросы и прочие модификации одной идеи). В общем, та еще задачка.
• Текстовые редакторы (а-ля Tiny_MCE & CFKeditor). Не хочу писать свой велосипед, существует множество различных редакторов. Остается их встроить на страницу. Этим будет заниматься отдельная библиотека, поддержка различных редакторов с помощью драйверов. Судя по всему, библиотеку придется выносить в ядро, т.к. в том же «блоге» редактор нужен. Скажу по секрету, что первая версия такой библиотеки у меня уже написана, проверяется на Tiny_MCE и FCKeditor, скоро выложу ее на суд читателей. В отличие от раскопанных мной на форуме вариантов там реализована максимальная гибкость в конфигурировании, в том числе и с помощью заранее настроенных в config’ах профилей.
• Темы. Смена внешнего вида форума в админке или настройках профиля конкретного пользователя приветствуется. Не думаю, что тут можно будет обойтись только сменой статики (css, img), скорее всего надо будет менять и пути к шаблонам (Views). Опять же, менеджер тем может быть полезен и для других модулей, так что есть вероятность его выноса в ядро.
• Прочие плагины (аватары, смайлики, уведомления и т.д.). Различные полезные мелочи, которые буду прикручивать уже по ходу пьесы.

База данных

На основании данных размышлений можно прикинуть примерную схему БД модуля.

Как видно, многие таблицы модуля будут связаны с модулем Auth (точнее с его модификацией — A1). Имена таблиц модуля начинаются с префикса ‘forum_‘, само значение префикса будет вынесено в конфигурацию. Таблица категорий (forum_categories) имеет связь один-ко-многим сама с собой — таким образом выстраивается дерево категорий. Использовать Nested Sets для такого небольшого дерева (глубину вложенности мы планируем контролировать через конфигурацию) я не вижу смысла.

Частично статистические данные собираются в ключевых таблицах (forum_categories, forum_posts) — выглядит не очень красиво, но зато должен быть выигрыш в скорости. Фильтрация просмотренных пользователем топиков будет осуществляться на основе анализа данных таблицы forum_user_visits, в которой будут храниться даты последних посещений пользователем данного топика. Прочая статистика (типа общей посещаемости форума) планируется в виде плагинов.

Уведомления пользователей о новых темах на форуме или комментариях в топике реализуются с помощью таблиц forum_category_subscribers и forum_post_subscribers соответственно. Роли пользователей хранятся в справочнике forum_roles, а их применение — в forum_assigned_roles.

@TODO.

• Не очень пока представляю себе, в каком виде реализовать голосования. С одной стороны, это част поста со всеми вытекающими — комментарии и т.д. Однако есть мысль выделить голосовалки как отдельный ресурс категории. В этом случае в категориях будет дополнительный подраздел «голосования» (или последние 5 голосований к примеру).
• Поскольку (в планах) возможны отдельные настройки для каждой категории, надо их хранить где-то. Совмещать это прямо с таблицей forum_categories я не хочу, лучше выделить в отдельную таблицу и сделать связь один-к-одному.
• Часто мной упоминаемая система плагинов/виджетов пока что не существует, есть вопросы по поводу ее организации. В первую очередь посмотреть существующие реализации в открытых разработках. Как один из ключевых моментов будущей системы, она должна быть продумана как можно тщательнее, дабы потом не пришлось перекраивать все заново.

Продолжение следует

В общем, тот необходимый минимум, что я описывал выше, вроде как набросал. А дальше, основываясь на этих рассуждениях, буду описывать этапы построения модуля в виде небольших статеек с заголовками типа «как прикручивались аватарки«. Было бы интересно выслушать ваши мнения, наверняка что-нибудь важное пропустил или какие-то ляпы уже видно невооруженным глазом…