ElkArte Community

(Transferred from here (http://www.elkarte.net/community/index.php?topic=948.0).)

Now that MyBB et al. are removing the Threaded View from the core and many people are stating that they'll miss it, maybe ElkArte should add it?

I'm pretty sure people have heard of sites like reddit and can see how horrible it is to read it. :D

Me use MyBB since many years. Threaded View never come to be deployed. Will not be missed.
It is not worth the trouble.

yep, agree.. "Threaded view" would require lots of changes..
1) modify the database structure in order to reflect replies to Messages
2) rewrite (and duplicate) the template.
3) modify the topic / message actions (merge, split and such stuff) -> move reply x to reply y inside a single topic and such things.

I think the MyBB folks do have a good reason why it was removed.

Add one int column.


Just extend the existing one. You do that all the time.


Why? It already does what it should.

Not to sound like a dick, but if it is that easy, do it.

Some big questions which arise immediately: if you have 10 posts per page, what if a post has 1000 sub-posts? If you do ?msg=X where X is a threaded message, you have to get all of its parents and children. Do threads have multiple levels? How do you find all of those levels?

I'm short on time. Maybe later.


Use collapse/expand functionalities.


Recursion.

A recursive query? So a thread with 100 levels would result in at least 100 queries. Of course that is extreme and you would probably want to have some setting to limit the number of levels. Still, say you set that to 10. You are then adding 10 queries to that page. It would be per level since you would get the first level, then do SELECT ... FROM messages WHERE id_parent IN($parents);

Even if with collapse/expand, you are getting all of those queries. Unless it uses AJAX to get the rest of them? I am pretty sure that Elk follows the SMF model of all functionality working with JS turned off, so that wouldn't work.

The German heise community has threaded views with pagination without JavaScript IIRC.

Then if you have a post with 1000 sub posts you need to get those 1000 sub posts. Unless the posts per page is applied to the sub posts. Then your pagination needs to be rewritten.

So does the linear view, at least counting them.

Huh? You only need one query to get the posts on the page. Without looking it is something like "SELECT ... FROM messages WHERE id_topic = $topic AND id_msg > $id_msg_start AND approved = 1 LIMIT $posts_per_page"

Precisely. Now what is your point?

yep, but that forum is IMHO one of the worst ones I've ever seen.. Just my 2c.

Granted. Another example: golem (http://forum.golem.de/read.php?79526,3624903,3624903,anonymous_threaded_read=1#msg-3624903).

I thought a bit during the years about threaded view and all possible variations.
It's not easy and it's not as linear as one may think (well, actually is absolutely not linear and that's where it get complicated).

I think we have to set a few common ground on the subject.

There are two ways to intend threaded view (as far as I can imagine):
1) [1] have just a "summary" of the thread and show one message at a time (the example given by @forumsearch0r ),
2) show all the messages in a threaded view (like reddit).

Let's start from the latter.
To properly show all the messages in a threaded view is kind of difficult.
Why? Well, first you cannot do pagination. No, you can't, otherwise you enter in the realm of all the fancy ways of present messages that are kind-of-not-linked one to each other.
So, no pagination means you have to load all the messages of a certain topic at once. This, obviously pose some problems: memory first, CPU second, execution time third, user experience fourth. Memory because I don't know you, but I have topics of 300 pages (x 25 = 7500 messages) and all these messages have to be loaded in memory along with all the data of all the posters that posted in each one of them (I know it's unlikely, but we should consider the possibility of 7500 different users). CPU, as we very well know, parse_bbc is one of the most CPU-hungry pieces of Elk's code, and parse some hundred of messages at once may be quite "difficult". Execution time, no matter what, grab hundreds if not thousands of messages, parse them and render them (according to all the permissions and whatnot takes time, and I think frequently it could exceed the maximum execution time of any server. User experience: if loading and preparing the page could send the server in timeout, it means a user should have to wait for approximately 30 seconds before being able to see the page, that's unacceptable, additionally, a page with hundreds or thousands of topics would be quite big and heavy to load for any browser around.
So, have a threaded view à la reddit could be rather difficult.

Now the first option: a map of the thread and single messages.
This is kind of more doable, provided some limitations are accepted.
For example: each topic could be associated with a map in the database, stored for example as a serialized array. It could work, why not: each topic added has a parent: unserialize, find the parent message, add the new one, serialize and update.
It may be difficult to remove messages (at least those in the middle of the tree), so removed messages may still appear in the tree, but give a"this has been removed" when opened,
Considering a MEDIUMTEXT can store strings of more than 16M chars, there should not be big problems for the storage.
It could be a bit "complex" to find each parent when posting if the thread becomes long enough.

Precisely? Huh?

It would have to do this:
 "SELECT ... FROM messages WHERE id_topic = $topic AND id_msg > $id_msg_start AND id_msg = NULL AND approved = 1 LIMIT $posts_per_page"

do
{
    $i++;
     "SELECT ... FROM messages WHERE id_parent IN($msgs[$parent_level]) AND approved = 1"
} while(!empty($level[$i]))

Of course, you could do the inverse (smarter) and put num_children on the messages. Then only do those queries if num_children > 0. Also, you could do num_levels and update that every time someone replies. That way you can do one giant query. I would definitely limit that though. If it's a busy site, that might quickly become a bottleneck.

I guess you could just show 10 replies per request. Then either using AJAX or another route, grab more.

Really though, nobody wants to do this and nobody cares enough. So unless you're willing to do it, it's not going to get done.

And you're able to speak for "everyone except me" because...?

Okay, I'll reword what I said: [it appears] nobody wants to do this and nobody cares enough. So unless you're willing to do it, it's not going to get done.

No need to get an attitude though, I'm the only one supplying you help on getting it done. I don't care if it gets done or not. Either way, it makes zero difference to me.

I know it's not something that has a high priority. Basically, it's just a feature request. :)

emanuele, I don't think a map is the way to go, unless it's just in the cache.

1) Get all of the first level posts
2) Check those posts to see if they have num_level > 0 (this could also be done in step 1 as part of the topic)
3) If num_level > 0 ? 'SELECT ... FROM messages M ' for ($i = 0; $i < $num_level; $i++) { $sql .= "UNION SELECT ... messages M$i ON($m-1)" }

num_level would be the number of child levels.

If you didn't want to use a UNION, you'd have to put it in a loop. If you were going to cache it, it would make sense to cache it both ways. From the topic id down, and from a message id up (and down)

That's exactly the first thing to define: what people that want the feature are expecting.
Once this is known (and I'm still not sure which is the way forumsearch0r expects the feature to work) it's possible (and meaningful) start thinking if it is possible and how it is possible to implement it and propose alternatives.
For example, IIRC (somewhere) forumsearch0r said something along the lines "a board should not require javascript to work", so AJAX seems not to be an option unless there is a fallback.

First step "clearly" define the expectation of how the feature should work, after look at the "implementation details". ;)

So forumsearch0r, "threaded view": all messages at once, or map of the messages and one at once?

It would be AJAX with a non-JS fallback. Just change the link to do preventdefault(); on click but makes its "href=?action=display;topic=$topic;submsg=$sub_msg[]" to get the messages for those children. Maybe you add each parent in there as well.

The map isn't necessary with a UNION. It will just select all of the levels. The hard part is keeping track of that. You would need to get the levels in every post/delete/merge/split action. The other hard thing is changing all of the GET functions to use that UNION.

Maybe: All except it's too long?

Offering a threaded alternative on a forum that started flat is never gonna cut it. It only works when it starts as threaded. Or if you have different types of contents and threaded for one of them (eg blogs).
One thing that could work everywhere though, is limiting threads to one level below the flat one, like stack overflow and Facebook do.

Regarding the technical aspects... I'd suggest that Elk immediately adds an 'id_parent' entry to their message table, so that if they want to add threading one day, at least nesting will be enabled as soon as the feature is written. I did that for Wedge years ago, and I know that if I end up deciding against this implementation, I can just drop the column from the messages table, and be done with it.

Additionally, this is how I would do thread paging:
- Have a 'position' column in the messages table, and show pages BETWEEN 0 AND 15 in position. Once you have a list of items, you can always re-build the nesting on the page. If you want to keep their horizontal position across multi-page sub-threads, then you'll have to maintain a 'depth' column as well, but this is outside of this technical discussion.
- If MAX(position) for that topic is = 0, then rebuild the list (do it from a recursive function, it's much simpler...)
- If a message is added to the thread, determine its position.
- If a message is added or remove, UPDATE messages SET position = position + 1 / - 1 WHERE id_topic = {int:id_topic} AND position > {int:id_msg}... That should be enough, as far as I can tell. It's a single query, so it should be fast enough. position + 1 if inserting a message inside a thread, and position - 1 if removing it, of course.

I'm not sure there are any gotchas to this algorithm. Can you think of any..?