Suggestion for modeling a Forum module.

[aaronamm]

According to this issue #14838 and I am thinking to make a forum for my community.

However, there are some concerns about modeling main objects.
For a minimal design, we may have these 3 objects:

Forum => We can have multiple forums. Alternative name can be Room.
Topic => In a forum we can have multiple topics. Alternative name can be Thread.
Reply => In a topic, many users create replies to a topic. Alternative name can be Post.

We don't have many Forums, it's perfect to make it as ContentItem.
However, I am not sure if we should make Topic and Reply as ContentItems and store them in a single Document table because there can be many rows of Topic and Reply.
I admit that it won't be millions of records soon but just want to make sure if I pick a proper design.

IMHO, Topic/Reply are different from Article, Product which mostly are created by an admin that won't grow quickly. Therefore it is good to make them as ContentItem and get benefit from existing reusable components and quick development.

BTW, I can go with making Forum/Topic/Reply as ContentItems and use ListPart, focus on functionality/UI and refactor code later.
However, it would be nice to get valued suggestions from the community.

Here are some design options, please could you give me some suggestions or suggest other better designs.

Design option	Benefit	Concern
1. Make Topic/Reply as a ContentItem and store Reply inside Topic, not save Reply as separated record.	Reuse existing components/view/UI/content part/ListPart. Quick development. Reply object is small enough to store inside inside Topic even though we may have many replies for each topic. Alternatively, we can store only Reply Id in Topic and save Reply content as separated Reply table.	The number of row in a single Document table grows quickly.
2. Save Topic/Reply as a new YesSql collection table	Separated Topic/Reply from existing an existing Document table. We've already made some additional collections which are: Audit, Notification, OpenId.	More work to use existing helper components to render UI/editor. We may need two tables: Topic and Reply collections if we don't store Reply as a nested object inside Topic.
3. Save Topic/Reply as two normal tables and query with Dapper	We can reuse existing Orchard V1 (NGM.Forum) that save each object to separated tables. Not sure if this option can be easily to port this module to OrcahrdCore. Topic/Reply are simple enough to not store as nested/JSON/document object. We don't need extra tables for creating indexes.	We need to be careful about query performance from joining table. Extra work to reuse existing helper components.

---

Thank you so much.

[hishamco]

I see that you want to create a forum for your community, but it would be nice to create such a module and make it applicable to any community.

Regarding the terminologies, I think we should go with Forum, Thread, and Post. Also, you might find Category as well

Few examples for inspiration:

• https://community.discountasp.net/
• https://www.dnnsoftware.com/forums
• https://www.sitepoint.com/community/t/orchard-cms-using-different-layout-for-anonymous-users/25341

Or we could go with something simple like GitHub Discussion or SmarterTrack Community

[hishamco]

In terms of design

We don't have many Forums, it's perfect to make it as ContentItem.

Agree

However, I am not sure if we should make Topic and Reply as ContentItems and store them in a single Document table because there can be many rows of Topic and Reply.

Make sense

IMHO, Topic/Reply are different from Article, Product which mostly are created by an admin that won't grow quickly. Therefore it is good to make them as ContentItem and get benefit from existing reusable components and quick development.

Could you please elaborate on your last phrase?

1. Make Topic/Reply as a ContentItem and store Reply inside Topic, not save Reply as separated record.

This is opposite to what you said earlier!!

2. Save Topic/Reply as a new YesSql collection table

Related to 3

3. Save Topic/Reply as two normal tables and query with Dapper

We could use dapper, but while YesSQL already used it internally, we need to explore what are the YesSQL options. Map & Reduce indexes will be useful in this case

[aaronamm]

@hishamco

IMHO, Topic/Reply are different from Article, Product which mostly are created by an admin that won't grow quickly. Therefore it is good to make them as ContentItem and get benefit from existing reusable components and quick development.

We usually don't have many articles/projects. We don't need to worry if we make them as content items and save them to a single table. (Document table)

Creating a new content type/content item is the way that we extend OC functionality.
We get benefit for fast development:

• Quickly create new content type by combining multiple content parts.
• We get admin page for creating/editing a new content item.
• We have fronted page for showing a list of all content items and individual item.
• This reduce a lot of work by modeling business object as content type.
• We have many built-in/classes/services to use if we define a new model as content item.

My concern is from the fact that forum system can have many topics/posts and not sure if creating them as content items and save them to a single table is good idea or not.

[hishamco]

Even if we store them in the document we could use OC a lot, one example we could think of OrchardCore.Notifications module

[aaronamm]

From this topic in discourse.org:
https://meta.discourse.org/t/terminology-topics-vs-threads/63390/4

I think we should use topic instead of thread.
Then on a UI/page, we can have "Create a new topic" button or "All topics" text.
IMHO, using a model/term that syncs with UI makes a system easy to understand and maintain.
It is kind of modeling object/class from business/domain object.

In addition, I might be wrong but I don't think we need a top level category to group related forums.
We can remove a forum and use multiple categories to group related topics instead.
This design is the same as category used in GitHub Discussion and Discourse.

Therefore, our model for the forum system can be:

• Category to group/categorize relates topics. We can make if from Taxonomy. We can make subcategory for nested group.

• Topic content type has a ListPart to contain multiple posts.

• Post content type has a ListPart to contain multiple comments.

• Comment content type as a reply for each post in a topic.

• This means the system will have only one forum and multiple topics which are grouped by a category.

• Basic system usage:

  • A user choose a category which is related to his/her topic.
    • Create a new topic.
    • The a system will automatically create: a new topic content item and a new post content item.
  • Other users can:
    • Create a new post in a topic.
    • Reply/comment to the first post in a topic.
    • Reply/comment to other posts in a topic.

The project name can be OrchardCoreContrib.Forum
After we have finished our discussion, I will make a simple POC project and let you review it.

FYI, some additional forums' source code:
DNN forum (.NET)
https://github.com/DNNCommunity/Dnn.CommunityForums/tree/dev/Dnn.CommunityForums/class

Discourse
https://github.com/discourse/discourse/tree/main/app/models

Pop Forum (.NET)
https://github.com/POPWorldMedia/POPForums/tree/main/src/PopForums/Models

YAF.NET - C# ASP.NET Forum
https://github.com/YAFNET/YAFNET/tree/master/yafsrc/YAFNET.Types/Models

BB Press
https://github.com/bbpress/bbPress/tree/trunk/src

Discourse database schema
https://azimutt.app/gallery/discourse

Stack exchange database schema
https://meta.stackexchange.com/questions/250396/database-diagram-of-stack-exchange-model/250439#250439

GitHub uses "Add a comment" text.

[hishamco]

Then on a UI/page, we can have "Create a new topic" button or "All topics" text.

There's a display name for the content item

We can remove a forum and use multiple categories to group related topics instead.

I don't think so, each group has many forums that will contain threads and replies

For comments I suggest having a separate module, FYI I'm working on one that I can open source in the future

The project name can be OrchardCoreContrib.Forum

+1

After we have finished our discussion, I will make a simple POC project and let you review it.

Just a quick question Are you thinking of building the OCC.Forum from within OC admin, or from the front end

[hishamco]

By the way, when do you expect to work on a PoC? We could set up a Google Meet after

Also, I could write a prototype if I finish the modules that I need to publish

[hishamco]

After the last discussion in Discord, we agreed that we could start with something minimalistic such as the OCC.Discussion module, and will see how it goes

[hishamco]

https://eksith.wordpress.com/tag/discussion-forum/