Разработка ПО
«Лента друзей»: разрабатываем компонент «1С-Битрикс»
Сергей Лещенко (sle_e@mail.ru)
Прошло время, когда социальные сети считались бесполезной для бизнеса игрушкой. Все больше компаний осознают ценность данного инструмента. Появился даже специальный термин – Enterprise 2.0, обозначающий комплекс методов и подходов, позволяющих применить технологии Web 2.0 для решения типичных корпоративных задач. Рынок Web-разработок не мог не отреагировать на такие тенденции, и сегодня сложно найти систему управления сайтом (CMS), которая не предоставляла бы возможность создавать социальные сети.
Компания «1С-Битрикс» в конце 2008 г. тоже выпустила модуль «Социальные сети» для своего пакета «1С-Битрикс: Управление сайтом» (БУС), который позволяет организовывать сообщества (группы), устанавливать «дружеские отношения», вести черные списки, распределять права доступа. Пользователь или группа получают развитый набор служб: блоги, фотогалереи с массовой загрузкой фотографий, рейтингами и обсуждениями, форумы, онлайновая переписка и др. Это весьма мощная разработка, более подробный обзор которой можно найти в PC Magazine/RE, 1/2009 (ознакомиться с продуктом «вживую» можно на www.pcmag.ru/club).
В этом же обзоре речь пойдет о том, чего недостает модулю «Социальная сеть» – о так называемой «ленте друзей». С точки зрения архитектуры и принципов организации данных социальный модуль БУС похож на популярную сеть FaceBook (в России более известен ее клон «ВКонтакте»). Однако в русскоязычном сегменте Сети не меньшей популярностью пользуется служба «Живой Журнал», интерфейс которой отличается от интерфейсов FaceBook и его клонов (порой радикально). Среди прочих различий в «Живом Журнале» имеется модуль «Лента друзей» (чаще «френдлента»).
Организация материала в виде «Ленты друзей» имеет ряд преимуществ. Она удобна для быстрого просмотра за чашкой утреннего кофе (или вечернего пива) новых поступлений в дружественные дневники. В БУС есть подсистема «лог обновлений», но это не совсем удачная замена. Слишком много несущественной информации и ссылок, по которым приходится лишний раз кликать. Вроде бы мелочи, но именно мелочи определяют впечатление пользователя от сайта. В общем недоработка налицо, и мы постараемся ее исправить.
Итак, постановка задачи: необходим компонент, имитирующий в БУС «Ленту друзей». «Лента друзей» конкретного пользователя как минимум должна аккумулировать новые записи из блогов друзей (полностью или в виде анонсов) и групп, в которых состоит владелец ленты. В «Ленте друзей» групп должны собираться новые записи из блогов ее участников. И, кстати, следует отметить существенное отличие блогов «Битрикс» от блогов «Живого журнала»: в «Битрикс» пользователь может публиковать сообщения не только в своем блоге и блогах групп, в которых он состоит, но и в других блогах, если владелец блога разрешил это делать.
Сначала разберемся с внутренними объектами (или сущностями) социальной сети «пользователь» и «группа»: какие свойства они имеют и как эти свойства влияют на результат. Заметим, что в обзоре будут затронуты только вопросы, касающиеся функциональности «Ленты друзей» для блогов; форумы, фотогалереи и т. д. мы во внимание не принимаем (принципы останутся теми же, а объем статьи увеличится существенно). Материал излагается в предположении, что читатель знаком с основами разработки на PHP и с API системы «1С-Битрикс: Управление сайтом».
Из свойств объекта пользователя нас интересуют настройки, которые можно задать на персональной странице социальной сети в формах настроек приватности и прав доступа к блогам. Среди настроек приватности для нашей задачи важны два поля: «кто может смотреть друзей» и «кто может смотреть мои группы». Эти поля влияют на включение в ленту записей из блогов друзей и из блогов групп, в которых состоит владелец. Причем записи из блогов друзей или групп должны включаться только, если право на просмотр имеют все пользователи. Иными словами, если Иван зайдет на страницу «Ленты друзей» Петра, а Петр разрешает просмотр своих групп только друзьям, то Иван не должен видеть записи из блогов групп Петра, даже если между ними установлены дружеские связи (в соответствующем интерфейсе модуля «Социальная сеть»).
В настройках блогов нас интересует параметр «кто может просматривать сообщения». От него зависит, войдут ли записи блога в ленту друзей пользователя и групп, в которых он состоит, причем они будут включаться только в случае, если права на просмотр разрешены всем пользователям. Например, если Петр разрешает читать записи своего блога только друзьям и друзьям друзей, то они не попадут ни в одну из лент.
Если блоги вообще отключены, следует автоматически исключить все записи, оставленные ранее в блоге пользователя, из всех лент всех друзей.
Аналогично из свойств групп нас интересуют настройки, которые будут заданы в формах редактирования группы и настроек блогов группы.
Параметр «группа видима всем посетителям» должен учитываться при включении записей блога группы в ленты ее участников. В настройках блогов нас интересует параметр «кто может просматривать сообщения». От него зависит, войдут ли записи блога в ленты участников группы, причем они будут включаться только, если просмотр будет разрешен всем пользователям.
Теперь подберем функции, которые будут использоваться для выборки записей блогов с учетом прав доступа и связей пользователей внутри социальной сети. Сначала выясним, не заложены ли в системе уже готовые решения, на базе которых можно сформировать «Ленту друзей» или хотя бы нечто похожее. Первое, что приходит на ум – если есть компонент ведения журнала событий, то нет ли в нем подходящих функций? Изучаем список свойств и методов (или код компонента) и видим, что для получения списка событий в нем используется функция CSocNetLogEvents::GetUserLogEvents():
CSocNetLogEvents:: GetUserLogEvents(int userID, array arFilter = Array());
Функция возвращает структуру, содержащую список событий социальной сети по фильтру arFilter. Параметр userID – идентификатор пользователя, в массиве arFilter сохраняется набор параметров для выборки данных из БД. Он имеет структуру вида:
array(«фильтруемое поле»=>"значение фильтра" [, ...])
где фильтруемое поле может принимать специфичные значения: ENTITY_TYPE (тип сущности социальной сети, U – пользователь или G – группа), ENTITY_ID – идентификатор сущности социальной сети, EVENT_ID – идентификатор инициатора события (сигнатуры blog, photo, forum или system), LOG_DATE_DAYS – количество дней для выборки журнала. Фактически количество дней ограничено временем жизни журнала (неделя), очистка выполняется агентом CSocNetLog::ClearOldAgent().
Функция возвращает структуру, содержащую идентификатор события, его тип, дату и время, текстовое описание, заголовок, ссылку на страницу, имеющую отношение к событию, идентификатор модуля, где событие было инициировано, набор данных, определяющих права доступа, данные о пользователе и др. К сожалению, ознакомившись с результатами работы этой функции, напрашивается вывод, что она не совсем подходит.
Во-первых, функция CSocNetLogEvents::GetUserLogEvents() работает только в контексте пользователя, а нам нужны еще и данные групп. Во-вторых, не передаются типы записей, т. е. записи добавления комментариев и сообщений ничем не отличаются друг от друга, идентифицировать их «по-человечески» не получится. Не возвращаются ID блогов и сообщений, а они нам нужны, чтобы сформировать ссылки. Время жизни записи «Ленты друзей» принудительно ограничивается агентом модуля (это поправимо, но требует вмешательства в обработку соответствующего события, чего делать не хотелось бы). Возможно, в будущих версиях «Социальной сети» разработчики «Битрикс» предпримут какие-то меры, но сегодня ситуация такова.
Поиск других подходящих функций в модуле тоже не дал результата. Остается два пути. Первый – самостоятельно реализовать нужный нам метод. С точки зрения системного подхода, это более правильное решение, но... Здесь могут возникнуть проблемы обратной совместимости. Модуль довольно новый, мало ли что может измениться в недалеком будущем. Второй – получить необходимые данные, скомбинировав результаты нескольких стандартных методов, благо изучение исходных текстов модуля дает четкое представление, как это сделать. Вот и попробуем.
Общая идея выглядит так. Для объектов типа «пользователь» мы получаем списки идентификаторов пользователей-друзей и идентификаторов групп, для сущности «группа» – список идентификаторов пользователей-участников. Далее из списков идентификаторов пользователей исключаем тех, чьи записи не должны войти в «Ленту друзей». Аналогично обрабатываем список идентификаторов групп. Какие именно записи из блогов не должны включаться в ленты, мы выяснили при разборе свойств объектов «пользователь» и «группа». На основе созданных списков пользователей и групп составляем списки идентификаторов блогов, извлекаем необходимые записи и передаем их в шаблон для вывода на Web-странице, откуда был вызван компонент.
Для получения списка записей в блогах будем использовать функцию CBlogPost::GetList(). На первый взгляд, больше подходит функция CBlogUser::GetUserFriendsList(), которая специально предназначена для формирования списка сообщений друзей пользователя, но, к сожалению, она опирается на связи пользователей внутри модуля блогов, а не социальной сети, а это значит, что она нам не подходит. Функция же CBlogPost::GetList() возвращает список записей, соответствующих заданному фильтру, с возможностью сортировки и разбивки на страницы.