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 Generic Values, then the thread ID for each
Content needs to be known so that it can be used as a url parameter to get to the "thread view" screen.
lol - now that I've typed all that out, I can see that I can use a service call in the <actions>
section of the "thread view" screen to walk up the ContentAssoc tree to get the thread ID.
David E Jones wrote:
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 difficult to solve.
-David
Adrian Crum wrote:
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 other parts of the
content manager can use it for grouping content records.
I'll think about it more over the weekend.
-Adrian
Al Byers wrote:
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
philosophy is
that if it is needed, you should add another field to the entity.
The ownerContentId is another field that could be used. I have used
it for
that purpose before. It is suppose to be used to identify the content
record
from which security permissions should be determined and, generally,
that
would be the content that starts a thread. The only place that that
would
not work is if in the middle of a thread, two or more parties wanted
to send
private messages to each other. But if that were the case, it would
probably
constitute a new thread.
I think I would lean towards adding a new field, then it would be the
use of
ownerContentId and then instanceOfContentId. But, like I said, I am not
certain enough about any of those options to be definitive.
-Al
On 8/23/07, Adrian Crum <[EMAIL PROTECTED]> wrote:
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
threads) can contain thousands of messages this approach is far too
inefficient.
Currently the Content.InstanceOfContentId field isn't used in forum
messages. It seems like an
appropriate place to store a thread ID, since the message can be
thought
of as an instance of a thread.
What do you think?
-Adrian
