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

SocialTools – Социальный функционал MODX.
Название хоть и громкое, но из функционала уже есть:
  1. Отправлять сообщения
  2. Читать сообщения
  3. Получать списки входящих и исходящих сообщений.

Немного теории
У MODX с социальной составляющей все плохо, и настолько что что даже готовая таблица и класс modUserMessage – просто бесполезны. Если вы присмотритесь к полям таблицы, то поймете что выжать из них что то стоящие нельзя, поэтому я решил создать свой класс и таблицы.
После долгого чтения/мучения интернета я остановился на модели входящих и исходящих в разных таблицах, но с одинаковыми полями.
Плюсы:
  1. Очень редко используем 2 таблицы вместе. А их отдельность проще для понимания как по логике, так и для использования.
  2. Даже если будет нужно для использования 2 таблиц сразу, с одинаковыми полями будет удобно. Сделать вывод переписки людей не составит проблемы
.
Минусы:
  1. Дублирование информации для входящих и исходящих.
Ну и немного примеров.
5 шагов для быстрого начала:
  1. Создать ресурс с формой отправки сообщений.
    <div class="social-container">[[!socDialogForm]]</div>
  2. Создать ресурс со списком входящих сообщений.
    <div class="social-container">
    [[!pdoPage?
      &element=`socDialogList`
      &action=`inbox`
    ]]
    
    <div class="paging">
    <ul class="pagination">
      [[+page.nav]]
    </ul>
    </div>
    
    </div>
  3. Создать ресурс со списком исходящих сообщений.
    <div class="social-container">
    [[!pdoPage?
      &element=`socDialogList`
      &action=`outbox`
    ]]<
    
    <div class="paging">
    <ul class="pagination">
      [[+page.nav]]
    </ul>
    </div>
    
    </div>
  4. Создать ресурс для чтения сообщения
    <div class="social-container">[[!socDialogReceive]]</div>
  5. Сделать правки в чанках по умолчанию.
    Изменить 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

Следующая заметка
[Tickets] Версия 1.4.0-rc4 Работа с избранным
Предыдущая заметка
[Sendex] Версия 1.0.0-pl — Отправка нескольких писем вручную


Комментарии ()

  1. Наумов Алексей 29 марта 2014, 15:57 # 0
    Очень приятно, что разработка идет! С полгода назад начал писать аналогичный функционал, дописал примерно до вашего уровня, может чуть поменьше, потом правда забросил.

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

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

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

    ну может еще что-то забыл.
    1. Саша Пекшев 29 марта 2014, 17:19 # 0
      флаги с удалением не удобны, их нужно отслеживать (можно сделать триггеры, но нет), и просто обычная логика это 2 разные таблицы сообщений — которые вы отправили и которые вам прислали. а одинаковы они как раз для того что б их можно было объединить через inner sql, вы например сможете сделать свой сниппет (который я позже напишу, и это можно даже развить до конференций), что бы вывести список переписок как вконтакте отсоритрованый по 1 одинаковому полю, время отправки например.
      И еще как часто в своей почте вы заходите в исходящие? =) избавление от лишней нагрузки в 1 таблицу.
      О пожеланиях:
      простой выбор получателя сообщений. — не совсем понял, смысле снипета кто написал сообщение?
      А по подсказке да, есть уже наброски и готовые(кстати) будет наверно typehead bootstrap или что то полегче, но только после френд листа (что бы можно было выбрать подсказки френд листа или всех юзеров), и фикса багов и завершения сообщений (предполагаются ajax формы ответов в след. версии),
      1. Василий Наумкин 29 марта 2014, 19:42 # +1
        флаги с удалением не удобны, их нужно отслеживать
        Удобны, нужно только помнить и писать deleted = 0 в условиях выборки. Именно так и сделано в modResource, например.

        а одинаковы они как раз для того что б их можно было объединить через inner sql
        Не объединять быстрее и удобнее. Просто указывать, какие сообщения выбирать — входящие или исходящие.

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

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

        Ну и, наконец, дублирование однородной информации в БД всегда плохо, об этом много умных статей написано.
        1. Саша Пекшев 30 марта 2014, 22:33 # 0
          Кстати говоря, в xPDO это могут быть 2 разных объекта, но храниться они будут в одной таблице, дописывая свой class_key при сохранении. Я бы так и сделал.
          Для этого нужно указать 1 таблицу для двух классов в схеме mysql.schema.xml Modx? ну и добавить поле class_key в таблицу?
      2. Саша Пекшев 29 марта 2014, 19:05 # 0
        Хотя если вы предоставите доводы что бы соединить их в 1 таблицу, сейчас на ранней версии самое то. Вся эта разработка подразумевает учебный характер для меня (которую я использую не в коммерческих целях для своего сайта ) и я просто решил поделиться ей, в знак благодарности сообществу MODX и отдельным личностям.
        1. Наумов Алексей 29 марта 2014, 19:53 # +1
          Вот Василий верно пишет сверху… я тоже не вижу смысла в 2х таблицах. Но и делать разный class_key тоже не понимаю зачем (может объяснит?).
          Есть 1 объект — сообщение. Оно должно быть 1 записью в таблице. И есть его отправитель, а есть получатель. А такое понятие, как входящее или исходящие — это уже на уровне логики приложения, а не БД.
          1. Чикин Артур 29 марта 2014, 20:44 # +1
            И потом искать по 1 таблице легче чем по двум таблицам. И так придется постоянно джоинить 2 таблицу для нормальной работы и например для поиска по сообщениям. А так же автору бы посоветовал в БД добавить еще одно поле, с именем например extended и формой хранения json например что бы при расширении компонента не нужно было редактировать таблицу в БД.
            1. Саша Пекшев 29 марта 2014, 22:08 # 0
              select * from inbox,outbox where order by date_sent

              код для выборки из двух таблиц, насколько это усложнило не совсем понял, кроме добавления лишь 1 таблицы в запросе.
              и опять же, как часто вы пользуетесь исходящими?
              Добавить json вполне реально, не проблема, как будет потребность.
              А по поводу Василия:
              Удобны, нужно только помнить и писать deleted = 0 в условиях выборки. Именно так и сделано в modResource, например.
              то о чем я и говорил за этим нужно следить и тд. в БД как по мне легче добавлять запись или удалять чем ее редактировать (Но это лишь мое мнение). При этом если запись связана с 2 пользователями, сложность и аккуратность и возможность ошибки лишь растет.
              а про дублирование — я написал как минус, class key — минус универсальности, хотя подумаю, интересно
              1. Чикин Артур 29 марта 2014, 23:01 # 0
                Смысл ты тогда спрашиваешь как лучше сделать?! Тебе говорят что лучше 1 таблица, а в ответе ты:
                то о чем я и говорил за этим нужно следить и тд. в БД как по мне легче добавлять запись или удалять чем ее редактировать (Но это лишь мое мнение)
                Раз так, то делай как тебе легче, это не нам следить за состоянием компонента а тебе, главное что бы работало без перебоев. Создавая компонент ты берешь на себя ответственность. Сейчас тебе кажется что лучше 2 таблицы, завтра ты прочитаешь какую нибудь крутую статью к примеру на habarahabr и решишь что нужно переделать в 1 таблицу, но это уже будет твоя проблема.
      3. Алексей 29 марта 2014, 16:21 # 0
        круто! интересно, сколько будет стоить выставление счетов в диалоге? (с отправкой на платежный агрегатор для оплаты)
        1. Саша Пекшев 29 марта 2014, 17:53 # 0
          Не совсем понял, если вы имеете ввиду совместимость Minishop2 как доп. функционал, то я к сожалению не разу пока с ним не работал.
          Но если вы просто за системные сообщения, то они в разработке, оповещения о чем то или регистрация…
        2. Clean 30 марта 2014, 21:54 # +4
          Автор молодец, что сделал компонент, но восринимать критику нужно так же.

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

          В остальном не смотрел, как доберутся руки — потестирую, направлю реквесты или сделаю форк.
          1. Саша Пекшев 30 марта 2014, 22:17 # +4
            я ее воспринимаю, за что вам благодарен! Следующий релиз будет сборка в 1 таблицу и добавление ajax формы ответов
          2. Антон Мамрашев 06 апреля 2014, 20:37 # +1
            А еще если кому-то понадобится реализовать чат, менеджер задач в замен cron, можно воспользоватся вот этим пакетом github.com/reactphp/react.
            Это асинхронный сервер на php, вдохновленный node.js, я например использовал его для отложенной загрузки фото в google drive для minishop. Пакет простой и удобный в использовании, сервер можно запустить в несколько строчек кода, можно его использовать к примеру для реализации websocket в связке с xpdo.
            Добавление новых комментариев отключено.