Lack of interest [Developer Tool] "Abstract Comment" system

[DragonByte Tech]

At the moment, there are at least two areas in XF and its official add-ons that use a "comments system"; profile posts, and XFMG comments. These two are roughly the same; a "post" associated with a content type, and a "comment" associated with a "post".

I believe XF would be well served to have this type of comments system abstracted just like reports, approval queues, etc. There are many 3rd party add-ons that would benefit from having an easier time implementing a comments system, and I would bet that any future official XF add-ons (should something like a blog or CMS materialise) would also benefit from such a system.

That being said, I recognise that it would be a somewhat significant undertaking, and would perhaps not be as immediately beneficial as the content permission system contributed previously. For that reason, and because I need this for my my own add-ons, I'd be happy to create this functionality and contribute it the same way the content permission system was contributed, if it would be added to the XF core.

Thanks for considering.

 

[Chris D]

While I'm not going to say "No" it is worth pointing out that the comment system in XFMG, at least in terms of JavaScript, doesn't use anything custom. We made sure that things like the AJAX insertion of the messages, replying, editing, mentions, quotes etc. were all supportable for custom content types totally out of the box without any custom code. That's quite a contrast to XF1.x where the basis for the comment system was actually some video tutorial Kier wrote on how to implement a AJAX based scratch pad or shoutbox or something!

There's even a reasonable amount of shared back end code that wouldn't have been shared for XF1 implementations. The Service system and the message preparer gives us shortcuts for things like preparing quotes and mentions in messages, logging IP addresses, checking for spam, notifying users etc.

So on the whole, I'm not exactly certain which bits end up being beneficial to being abstracted out.

 

[DragonByte Tech]

So on the whole, I'm not exactly certain which bits end up being beneficial to being abstracted out.

Templates, and code for add/edit/save/delete etc. I don't know about the inner workings of the XFMG comments system, but when I needed a comments system for the Shop mod, I looked at Profile Posts as a base, and it required quite a lot of variable replacements and whatnot.

I feel like with a core similar to the Custom Fields and Permissions, where we would provide content types and entity keys rather than needing to copy the entire Profile Posts system and change all the variable names, it would be easier for 3rd parties to implement.

From a quick look at the Shop file, the TradePost controller ended up at roughly 900 lines of code. Things like this action:

    /**
     * @param ParameterBag $params
     *
     * @return \XF\Mvc\Reply\View
     * @throws \XF\Mvc\Reply\Exception
     */
    public function actionLoadPrevious(ParameterBag $params)
    {
        $tradePost = $this->assertViewableTradePost($params->trade_post_id);

        $repo = $this->getTradePostRepo();

        $comments = $repo->findTradePostComments($tradePost)
            ->with('full')
            ->where('comment_date', '<', $this->filter('before', 'uint'))
            ->order('comment_date', 'DESC')
            ->limit(20)
            ->fetch()
            ->reverse();

        if ($comments->count())
        {
            $firstCommentDate = $comments->first()->comment_date;

            $moreCommentsFinder = $repo->findTradePostComments($tradePost)
                ->where('comment_date', '<', $firstCommentDate);

            $loadMore = ($moreCommentsFinder->total() > 0);
        }
        else
        {
            $firstCommentDate = 0;
            $loadMore = false;
        }

        $viewParams = [
            'tradePost' => $tradePost,
            'comments' => $comments,
            'firstCommentDate' => $firstCommentDate,
            'loadMore' => $loadMore
        ];
        return $this->view('DBTech\Shop:TradePost\LoadPrevious', 'dbtech_shop_trade_post_comments', $viewParams);
    }

In my eyes, the exact same code would be used in every incarnation of the comments system, with no real changes needed other than renaming "tradePost" and the View class / template references. This entire block of code, along with the template, could easily be abstracted in a similar way to custom fields or permissions, so that the dbtech_shop_trade_post_comments template would just be a call to a macro (thus giving the option of replacing it with an entirely different template should that be required).

The same could be said for the AddComment action. It contains code to check for comments newer than what was last loaded, to support the feature that loads new comments along with the one that was just posted, etc.

Hopefully the request makes a bit more sense now