BuddyPress.org

BP1.2 is shaping up to be a major, beneficial update to the platform. But I do have a small issue with this thread’s topic.

As Mike said several posts above, the current threaded commenting feature of the SWA stream offers nothing more than a “comment about a comment.” I understand what jjj is proposing, but why should we want members to be able to comment about blog comments and forum posts?

Should we later then create a feature that allows members to comment about comments about comments? This is just a rhetorical question, of course.

The SWA table is reporting on activity sitewide. IMO, it should not be a place where new activity is created and stored. If you look at the new table, that is exactly what is happening. There is a new component_action called “activity_comment.” It exists only in the activity table. It is not a reflection of activity that has occurred elsewhere. It is a self-referential, disjointed piece of activity—activity for activity’s sake in essence.

What is the solution?

Well, as Andy has pointed out above, there is limited time before v1.2 comes out. So, at this point, I believe we need to discuss viable and desirable solutions for a future release. Here’s one thought going forward.

I am not a fan of the way that content data is duplicated in the xx_bp_activity_user_activity_cached table. The data already exists in other tables. It is not a good practice to copy it into this table. Yes, I know that that’s what a cache is all about. But a cache is supposed to take place in memory or temporarily on the HD. It is considered temporary storage. It is not written to a physical, permanent table.

Why is this important? Well, since this thread is about the bifurcating of commenting activity, if we ensure that all commenting activity takes place in the original containers—this means in the backend, not in any particular user interface—then we could do away with this table.

This would mean that to obtain the wonderful threaded commenting feature that Andy has implemented for the SWA stream would require that the data be written back to the appropriate tables and properly associated with the original piece of comment datum. The SWA stream would be auto-created from a query, storing the results in an array instead of pulling it from a permanent “cache” table. The array would be updated as needed.

To clarify, be stating that the system would ensure that all commenting activity takes place in the original containers it does not mean that all commenting activity would be forced to occur in the blog or forums screens. With the proper underlying functionality, the system would write the data back to the appropriate table; commenting could occur within any user interface area (like the SWA stream). This is a behind-the-scenes issue, not a user interface issue.