Commentable

[max.zloy]

Возьмусь за Commentable

Начал с базы данных.


В таблице comment будут храниться сами комментарии непосредственно.
В таблице comment_relation будут хранится связи комментариев к разным таблицам в базе данных.
Составной первичный ключ для того чтобы исключить повторений.

Комментарии древовидны, но не nested sets пока что)

Будет 2 виджета
- для показа формы комментариев
- для показа дерева комментариев

пока не понятно как делать добавление комментария от какого либо зарегистрированного пользователя. Думаю потом не долго будет доработать.
И не понятно как должно происходить удаление комментариев, у каждого распределение прав доступа свое.
В перспективе на основе этого расширения будет просто сделать что то похожее для рейтинга.

[Svyatov]

И не надо nested sets, для комментов это смерть будет по нагрузке

[Werewolf]

Модуль полезный. Для своей CMS такой хотел написать.

И не надо nested sets, для комментов это смерть будет по нагрузке

Из-за долгой вставки нового узла?

Материализованные пути (1.2.3.4.5)
Узел очень быстро вставляется.
По сравнению с Adjacency List (parent ID) намного удобней работать, простой запрос на выборку дочерних узлов.

[Svyatov]

И не надо nested sets, для комментов это смерть будет по нагрузке

Из-за долгой вставки нового узла?

Именно.

Материализованные пути (1.2.3.4.5)
Узел очень быстро вставляется.

Можно использовать, да. Для комментов в нашем проекте мы используем банальный Adjacency List, по той простой причине, что на самом деле построение дерева базой бессмысленно, нам ведь нужно показывать сразу все комменты для сущности. Поэтому делаем выборку тупо по типу сущности, а потом готовим комменты к выводу (строим дерево или поступаем еще проще - просто проставляем комментам их уровень и при верстке используем для визуализации дерева, потому что настоящее дерево комментов на самом деле не нужно, да и проходить его в шаблоне сложно, а плоский массив с уровнями - элементарно).

[samdark]

Nested Set для комментов актуален только в случае их постраничной разбивки.

[Svyatov]

Nested Set для комментов актуален только в случае их постраничной разбивки.

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

[timlar]

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

На счет "главное быстрая вставка" не соглашусь. В процентном соотношении гораздо больше тех, кто читает коменты, чем тех, кто их пишет. Банальная ситуация, когда пользователь просто зашел почитать статью, комментарии его вообще не интересуют, но они на странице отображаются. Скорость выборки, ИМХО, важнее. А за разбивку камментов на страницы нужно лишать права на программерскую деятельность. Тут я обеими руками "за".

[max.zloy]

А за разбивку камментов на страницы нужно лишать права на программерскую деятельность. Тут я обеими руками "за".

Нефакт, вот например есть ЖЖ tema.livejournal.com там без этой разбивки все было бы плохо, 1к - 2к комментов отрендерить браузеру та еще задача
Да и бывают такие места где комментов ну ооооочень много, пусть даже не древовидных

[max.zloy]

Я все написал уже врипнципе, один вопрос есть по части конфига.
Как добавлять бехавиор к модели динамически в зависимости от того что написанно в конфиге. В каком месте это правильнее сделать?

[samdark]

Ну, не древовидные разбить по страницам очень легко. В behaviors() модели?

[Ekstazi]

C adj. list можно двумя запросами все дочерние узлы вытянуть.

[max.zloy]

Ну, не древовидные разбить по страницам очень легко. В behaviors() модели?

Вы меня не полняли
В todo сказанно

Commentable
Поведение (behaviour) для моделей + набор формочек и всяких других плюшек, позволяющий через конфиг и самые минимальные правки прицепить комментарии к любой модели.

Скажем у меня в конфиге есть описание того как каким моделям подключать бехавиор, но совсем непонятно, в каком месте это делать?
Делать какую то общую супер модель от которой наследовать все, а в init смотреть надо ли к модели подключать что то или нет - не нравится мне идея. Да и смысл бехавиора теряется вообще

[Darth_Ixis]

У меня есть версия данного поведения из yiiext, но может у кого есть более совершенная?

[xoma]

Мой вариант очень простых комментариев вот тут http://code.google.com/p/yupe/source/br ... s/comment/

Все хранится в одной табличке, сущность к которой прикреплен комментарий определяется по Url, т.е. я храню не id поста и запись вида "/post/show/id/3/" - это и есть идентификатор. Для удобства у модели есть метод getAbsoluteUrl - который этот самый идентификатор и возвращает.

Модель http://code.google.com/p/yupe/source/br ... omment.php
Виджет формы http://code.google.com/p/yupe/source/br ... Widget.php
Виджет вывода комментариев http://code.google.com/p/yupe/source/br ... Widget.php
Пример работы http://yupe.ru/story/novost-raz


p.s. повторюсь - этот метод подходит только для самых простейших случаев.

[SpartakuS]

В yiiext не нашел ни sql табличек, ни хотя бы моделей для табличек комментов. Есть такие или самому по коду+схемме из первого поста восстанавливать?

[coder]

Ребят, действительно, выложил бы кто-то таблички.

[Darth_Ixis]

У меня немного другой commentable.
Кто какие преимущества/недостатки видит перед схемой из первого поста?

[samdark]

Тут небольшая избыточность. Получается, что один коммент может быть для нескольких сущностей.

[rak]

зато обход антипаттерна
Такое решение предлагается тут http://www.slideshare.net/billkarwin/sq ... trike-back
Страница 41

[samdark]

Ну в этом плане да. Мне больше нравится, чем соединение по имени сущности.