Idea: pseudo-threaded comments, back and forward compatible

99% of threading is simply indenting content to the right depth. The depth data could be stored in a special HTML comment at the start of the annotation string, which could then be pulled out by a view script/Javascript.

As this metadata is a comment, it would have no impact on systems without this plugin/patch and when comments become entities, this data could either be converted to reconstruct the threading, or left to be handled by the view layer.

Obvious problem is what to do about pagination, but even threaded systems don't agree on the right way to do this. In this case, the next page would just pick up where the last left off, which seems acceptable to me.

  • I knew this couldn't be that easy: Comments will appear at the correct depth, but always at the bottom.

    I'm going to play with storing the parent comment ID rather than the depth and see if I can manually rethread in the comment view/javascript.

    Already found out that Elgg makes HTML comments visible, so the best bet is to store this data in an unknown element like "<parent=2/>". This keeps better BC/FC because htmlawed will strip this if left in.

  • Consider the case of 100 comments with the last one replying to the first. Unless the view pre-fetches and parses ALL the comments, it can't draw the 100th in the correct location.

    The comment view would have to fetch comments recursively walking down the tree and somehow impose a limit to deal with pagination.

    Anyone know how WordPress does nested/paginated comments?

  • I think this is why comments as objects is a target for 1.9 - threading then becomes a matter of containers.  I'm not sure there is a good way of doing it with the current annotation model.

  • Steve,

    Your efforts are *much* better spent helping us convert comments to entities. If that is something you are interested in, please let us know.