Skip to main content ↑ ↓
Topic: Threaded View (Read 12001 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Threaded View

Reply #15 –

Quote from: forumsearch0r – The German heise community has threaded views with pagination without JavaScript IIRC.
yep, but that forum is IMHO one of the worst ones I've ever seen.. Just my 2c.
Thorsten "TE" Eurich
------------------------

Re: Threaded View

Reply #16 –

Granted. Another example: golem.
-

Re: Threaded View

Reply #17 –

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.
1 We really have to find a way to have implicit lists with decimals, it's tedious have to write the list bbcode!!... :P <= where is markdown? O:-)↵
Bugs creator.
Features destroyer.
Template killer.

Re: Threaded View

Reply #18 –

Quote from: forumsearch0r – Precisely. Now what is your point?
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.

Re: Threaded View

Reply #19 –

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

Re: Threaded View

Reply #20 –

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.

Re: Threaded View

Reply #21 –

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

Re: Threaded View

Reply #22 –

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)

Re: Threaded View

Reply #23 –

Quote from: groundup – emanuele, I don't think a map is the way to go, unless it's just in the cache.
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?
Last Edit: January 28, 2014, 01:18:48 am by emanuele
Bugs creator.
Features destroyer.
Template killer.

Re: Threaded View

Reply #24 –

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.

Re: Threaded View

Reply #26 –

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.
 

Re: Threaded View

Reply #27 –

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..?