Thinking about it more...
The service call will have to hit the database for each thread message until the first message in
the thread is found - which takes me back to the original point I made: it's going to be
inefficient. It would be better to hit the db once and scoop up all of the message
Let's say you're viewing a screen of recent forum messages, most recent on top. Clicking on a
message of interest takes you to a screen where all the messages in that thread are listed - so you
can see the message of interest in context.
If the first screen is generated from a list of Content G
Is that field really needed? I recommend stepping back and looking at the
process you're trying to do, in real terms of user interaction. From the stuff
here I don't see what that is.
If it's a hypothetical "how would I..." then I recommend making it more
concrete or the problem will be diffi
Al,
Thank you for the reply!
I'm hesitant to add another field that is specific to forums. As David has pointed out,
ownerContentId is intended to be used for security purposes and right now it contains the forum ID -
I don't want to change that.
How about a field named contentGroupId? Then
Adrian,
There are so many things about this that I cannot think of and, hopefully,
David will be able to comment. The InstanceOfContentId field is used in a
mode where content is derived from a template. I don't think that there
would be any conflicts in its use, but I am guessing the right philos
I think I've mapped out the basic entity usage for forums. I wanted to see if it's okay to use an
unused field to hold the forum thread ID. I know I can start with any ContentAssoc record and walk
up the tree to find the ID of the uppermost message (the thread start) but since forums (and
thread
