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 messages for that thread.
Any advice would be appreciated. I'd like to get this wrapped up this weekend.
Adrian Crum wrote:
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
