SocialTools - Социальный функционал MODX

SocialTools – Социальный функционал MODX.

Название хоть и громкое, но из функционала уже есть:

  1. Отправлять сообщения

  2. Читать сообщения

  3. Получать списки входящих и исходящих сообщений.

Немного теории

У MODX с социальной составляющей все плохо, и настолько что что даже готовая таблица и класс modUserMessage – просто бесполезны. Если вы присмотритесь к полям таблицы, то поймете что выжать из них что то стоящие нельзя, поэтому я решил создать свой класс и таблицы.

После долгого чтения/мучения интернета я остановился на модели входящих и исходящих в разных таблицах, но с одинаковыми полями.

Плюсы:

  1. Очень редко используем 2 таблицы вместе. А их отдельность проще для понимания как по логике, так и для использования.

  2. Даже если будет нужно для использования 2 таблиц сразу, с одинаковыми полями будет удобно. Сделать вывод переписки людей не составит проблемы

.

Минусы:

  1. Дублирование информации для входящих и исходящих.

Ну и немного примеров.

5 шагов для быстрого начала:

  1. Создать ресурс с формой отправки сообщений.
<div class="social-container">[[!socDialogForm]]</div>
<div class="social-container">[[!socDialogForm]]</div>
  1. Создать ресурс со списком входящих сообщений.
<div class="social-container">
[[!pdoPage?
  &element=`socDialogList`
  &action=`inbox`
]]

<div class="paging">
<ul class="pagination">
  [[+page.nav]]
</ul>
</div>

</div>
  1. Создать ресурс со списком исходящих сообщений.
<div class="social-container">
[[!pdoPage?
  &element=`socDialogList`
  &action=`outbox`
]]<

<div class="paging">
<ul class="pagination">
  [[+page.nav]]
</ul>
</div>

</div>
  1. Создать ресурс для чтения сообщения
<div class="social-container">[[!socDialogReceive]]</div>
  1. Сделать правки в чанках по умолчанию.

    Изменить readMsgResourceID - на id вашего ресурса с вызовом сниппета для чтения сообщений.

    Изменить formSendResourceID - на id вашего ресурса с вызовом сниппета для формы отправки сообщения.

Рекомендации, дополнения

  1. Установить компоненты dateAgo, и phpthumbon для приятного отображения даты отправки сообщения и аватара пользователя в чанках.

  2. Вывод плейсхолдера непрочитанных сообщений по умолчанию

    [[!+socIsRead:notempty=`Новые сообщения! ([[!+socIsRead]])`]]
    
  3. Заключать все вызовы в div с классом social-container, у этого класса фиксированая ширина, с помощью него вы легко сможете настроить ширину под свой сайт в CSS

  4. Полезные классы в CSS social-listheader , social-msgcontent - параметр max-width, определяет максимальную ширину этих полей, все что больше будет обрезаться и ставиться многоточие. Они используется для отображения списка сообщениий. Если вы изменяете параметры класса social-container, то значения в social-listheader , social-msgcontent так же нужно настроить под ваш CSS.

  5. Вы всегда можете сделать свои чанки, с собственным CSS, на основе чанков по умолчанию

Компонент есть как официальном репозитарии так и в Simple Dream

Демо сайт:

http://c2714.paas2.ams.modxcloud.com/

*Позже появиться документация на docs.modx.pro

баги и пожелания писать в этой теме или на Gitgub*

Комментарии (14)
Наумов Алексей
29.03.2014 11:57

Очень приятно, что разработка идет! С полгода назад начал писать аналогичный функционал, дописал примерно до вашего уровня, может чуть поменьше, потом правда забросил.

Я тоже думал, как лучше сделать, но мне приглянулся больше вариант в виде диалогов, как в контакте например, а не в виде отдельно списка входящих и исходящих.

Из пожеланий - простой выбор получателя сообщений. Думаю, что должна быть возможность передачи получателя сообщения через GET параметр и еще подсказка получателя при наборе первых букв имени в поле ввода.

И все же почему 2 таблицы с одинаковыми полями? Почему не так: - id - отправитель - получатель - тема - сообщение - дата отправки - дата прочтения - удалено отправителем - удалено получателем

ну может еще что-то забыл.

Саша Пекшев
29.03.2014 13:19

флаги с удалением не удобны, их нужно отслеживать (можно сделать триггеры, но нет), и просто обычная логика это 2 разные таблицы сообщений - которые вы отправили и которые вам прислали. а одинаковы они как раз для того что б их можно было объединить через inner sql, вы например сможете сделать свой сниппет (который я позже напишу, и это можно даже развить до конференций), что бы вывести список переписок как вконтакте отсоритрованый по 1 одинаковому полю, время отправки например. И еще как часто в своей почте вы заходите в исходящие ? =) избавление от лишней нагрузки в 1 таблицу. О пожеланиях: простой выбор получателя сообщений. - не совсем понял, смысле снипета кто написал сообщение ? А по подсказке да, есть уже наброски и готовые(кстати) будет наверно typehead bootstrap или что то полегче, но только после френд листа (что бы можно было выбрать подсказки френд листа или всех юзеров), и фикса багов и завершения сообщений (предполагаются ajax формы ответов в след. версии) ,

bezumkinВасилий Наумкин
29.03.2014 15:42

флаги с удалением не удобны, их нужно отслеживать

Удобны, нужно только помнить и писать deleted = 0 в условиях выборки. Именно так и сделано в modResource, например.

а одинаковы они как раз для того что б их можно было объединить через inner sql

Не объединять быстрее и удобнее. Просто указывать, какие сообщения выбирать - входящие или исходящие.

Кстати говоря, в xPDO это могут быть 2 разных объекта, но храниться они будут в одной таблице, дописывая свой class_key при сохранении. Я бы так и сделал.

И еще как часто в своей почте вы заходите в исходящие?

Часто. Более того, почта хорошо показывает цепочку сообщений: входящие и исходящие в одном потоке.

Ну и, наконец, дублирование однородной информации в БД всегда плохо, об этом много умных статей написано.

Саша Пекшев
30.03.2014 18:33

*Кстати говоря, в xPDO это могут быть 2 разных объекта, но храниться они будут в одной таблице, дописывая свой class_key при сохранении. Я бы так и сделал.*Для этого нужно указать 1 таблицу для двух классов в схеме mysql.schema.xml Modx? ну и добавить поле class_key в таблицу ?

Саша Пекшев
29.03.2014 15:05

Хотя если вы предоставите доводы что бы соединить их в 1 таблицу, сейчас на ранней версии самое то. Вся эта разработка подразумевает учебный характер для меня (которую я использую не в коммерческих целях для своего сайта ) и я просто решил поделиться ей, в знак благодарности сообществу MODX и отдельным личностям.

Наумов Алексей
29.03.2014 15:53

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

Чикин Артур
29.03.2014 16:44

И потом искать по 1 таблице легче чем по двум таблицам. И так придется постоянно джоинить 2 таблицу для нормальной работы и например для поиска по сообщениям. А так же автору бы посоветовал в БД добавить еще одно поле, с именем например extended и формой хранения json например что бы при расширении компонента не нужно было редактировать таблицу в БД.

Саша Пекшев
29.03.2014 18:08
select * from inbox,outbox where order by date_sent

код для выборки из двух таблиц, насколько это усложнило не совсем понял, кроме добавления лишь 1 таблицы в запросе. и опять же, как часто вы пользуетесь исходящими ? Добавить json вполне реально, не проблема, как будет потребность. А по поводу Василия: *Удобны, нужно только помнить и писать deleted = 0 в условиях выборки. Именно так и сделано в modResource, например.*то о чем я и говорил за этим нужно следить и тд. в БД как по мне легче добавлять запись или удалять чем ее редактировать (Но это лишь мое мнение). При этом если запись связана с 2 пользователями, сложность и аккуратность и возможность ошибки лишь растет. а про дублирование - я написал как минус, class key - минус универсальности, хотя подумаю, интересно

Чикин Артур
29.03.2014 19:01

Смысл ты тогда спрашиваешь как лучше сделать?! Тебе говорят что лучше 1 таблица, а в ответе ты:

то о чем я и говорил за этим нужно следить и тд. в БД как по мне легче добавлять запись или удалять чем ее редактировать (Но это лишь мое мнение)

Раз так, то делай как тебе легче, это не нам следить за состоянием компонента а тебе, главное что бы работало без перебоев. Создавая компонент ты берешь на себя ответственность. Сейчас тебе кажется что лучше 2 таблицы, завтра ты прочитаешь какую нибудь крутую статью к примеру на habarahabr и решишь что нужно переделать в 1 таблицу, но это уже будет твоя проблема.

Алексей
29.03.2014 12:21

круто! интересно, сколько будет стоить выставление счетов в диалоге? (с отправкой на платежный агрегатор для оплаты)

Саша Пекшев
29.03.2014 13:53

Не совсем понял, если вы имеете ввиду совместимость Minishop2 как доп. функционал, то я к сожалению не разу пока с ним не работал. Но если вы просто за системные сообщения, то они в разработке, оповещения о чем то или регистрация...

CleanClean
30.03.2014 17:54

Автор молодец,что сделал компонент, но восринимать критику нужно так же.

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

В остальном не смотрел, как доберутся руки - потестирую,направлю реквесты или сделаю форк.

Саша Пекшев
30.03.2014 18:17

я ее воспринимаю, за что вам благодарен! Следующий релиз будет сборка в 1 таблицу и добавление ajax формы ответов

me6iatonАнтон Мамрашев
06.04.2014 16:37

А еще если кому-то понадобится реализовать чат, менеджер задач в замен cron, можно воспользоватся вот этим пакетом https://github.com/reactphp/react. Это асинхронный сервер на php, вдохновленный node.js, я например использовал его для отложенной загрузки фото в google drive для minishop. Пакет простой и удобный в использовании, сервер можно запустить в несколько строчек кода, можно его использовать к примеру для реализации websocket в связке с xpdo.

ЕвгенийК
09.04.2022 03:35
Это хорошо, что такая возможность есть и может быть использована. А то тенденция, мания, что-то в по...
begoodco1
07.04.2022 05:49
Зарегистрировался чтобы выразить благодарность за доступное и подробное описание процесса. Была возм...
bezumkin
Василий Наумкин
18.03.2022 12:35
Авторизация есть из коробки, для входа в базовую админку. Можно установить через composer и собрать ...
bezumkin
Василий Наумкин
10.03.2022 12:08
Ну, я имел в виду, что по закону можно =) А в реальности с валютой очевидные проблемы.
Сергей Лелеко
04.03.2022 06:12
О как! не знал! спасибо
bezumkin
Василий Наумкин
01.03.2022 15:32
Я делал одного бота на botman/botman, но из-за своей универсальности конкретно с Телеграм на нём раб...
bezumkin
Василий Наумкин
25.02.2022 09:22
P.S. Кажется цитаты у тебя никак не стилизуются в комментариях... Спасибо, поправил!
Electrica
Михаил
08.02.2022 11:19
Работает!
Алексей
09.01.2019 10:55
Насыщенный год ) От души поздравляю с ДР! Счастья, успехов и семейного благополучия! Жаль лимит заме...
septa rose
28.05.2018 22:16
hmmm, keren abis