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