Lack of interest Idea For 2.0: Separate nodes from node data

This suggestion has been closed automatically because it did not receive enough votes over an extended period of time. If you wish to see this, please search for an open suggestion and, if you don't find any, post a new one.

Denny Crane

Member
No forum software has done this yet, but it's not too hard to make it so threads can be crossposted in multiple forums. The scheme I present here can do way more than that, too.

The problem with the database schema as implemented is each node has parent_id in it. If you want the node to appear in two forums, you'd need two parent_id fields. If you want the node to appear in three forums, you'd need three, and so on. That won't work.

What will work is if you break node into two tables. One has parent_id and node_id, and the other has node_id and rest of node. Let's call the first table Node and the second NodeData.

This query selects a complete node for forum # in #forum_id:
SELECT * FROM Node,NodeData WHERE Node.parent_id=$forum_id AND NodeData.node_id=Node.node_id

This query tells you where the node $node_id is cross posted:
SELECT * FROM Node,NodeData WHERE Node.node_id="$node_id" and NodeData.type="FORUM" and NodeData.node_id=Node.parent_id

While I'm at it, most things could be NodeData. Forums, Posts, Threads, and so on. You have NodeData.type tell you which type the node is.

This leads to the idea that a Node can be a Thread or any kind of new data type. A Resource, a Media object, a Review, and so on. But even better, they could be a Blog post or a Wiki Page.

I'd love to see the last two implemented. You already have a "program" that views Threads. So the system would be extensible to have programs that view the various other types.

A Blog post would appear in the list of threads. You create them like you do a thread, but the form may be custom for what a new blog post would contain. The Blog view program would show the blog first post and the comments in reverse chronological order (newest first). A Thread view program shows then oldest first.

A Wiki page would appear in the list of threads, too. You create them and anyone with permissions can edit the page (first post).

You'd identify the various node types in the forum listing by an icon to the left of the title.

3rd party plugins can provide an infinite number of new node types and programs to view and edit them, since the type field is a string.

Any forum could have a "blog view" and a "forum view."

We're all familiar with the forum view. The blog view would render a page with 20 threads. Each thread would be shown as full first post (or some first part of it) with "# of comments" displayed below it. It would look like WordPress, and rather trivial to implement.

I've mentioned elsewhere that I run a sports site and my users tend to congregate in threads during games. The way it works now, Portland Trail Blazers fans can be in their game thread and Boston Celtics fans can be in their game thread. If the Node/NodeData scheme is implemented, they can be in the same thread together, the Blazers posters seeing the Blazers forum skin (determined by Node.parent_id) and the Celtics forum poster see the Celtics forum skin.

Use these ideas, or don't use them. I offer them for free :)
 
Upvote 0
This suggestion has been closed. Votes are no longer accepted.
I forgot to mention that Node would likely have more than just parent_id and node_id fields. You'd want the sticky bit in the Node so a thread could be sticky in the Celtics forum but not in the Blazers one. As you work with this schema modification, you'll figure out what needs to be in Node and NodeData.
 
If the node is contained in multiple parent_ids, which one would be used for the node's permissions? You'd at least need a "main" parent for each node so that permissions can be applied. It all seems great until you start thinking about inherited permissions from multiple nodes that might conflict with each other.
 
Either users can see and modify the node or not. If it's in two forums, it makes no sense to allow a user to not edit in one place but go to the other and get around it.

So the node permissions belong with the NodeData.

Other attributes like sticky belong with the Node so the thread could be sticky in one place but not in the other.

If you put a node in two places, one that's private/hidden and one that's not, it's operator error.
 
Top Bottom