#11 Everyone read topic data for stories

closed
None
1
2004-06-15
2004-06-09
No

Here's a quick rundown of how we store topic data for stories.
Read this and post a comment to let me know if you understand it,
if it seems logical, if you think something should change...

stories table is much the same as before. But in place of section
we now have stories.primaryskid. This is not the *only* skin that
the story can/will show up in. A story whose chosen topics render
into both the Apple and BSD nexuses will appear both in the Apple
index.pl skin and the BSD index.pl skin. But one or the other is
*preferred* - it's the skin that we send the user to when the user
clicks on the article from the mainpage skin. The primaryskid can
and often will be the mainpage skin.

stories.tid is still around, mostly just for compatibility (there are a
number of places in templates where we refer to it, and I don't feel
like changing them all). What this is, is the first item returned by
getTopiclistFromChosen, when passed in the chosen topics for that
story. To see what that list looks like, try perl -MSlash::Test -le
'print Dumper($slashdb->getTopiclistFromChosen($slashdb-
>getStoryTopicsChosen(TIDOFASTORYYOUCREATED)))'

"chosen" and "rendered" topics. These are stored internally as
hashrefs, where the keys are topic IDs and the values are the
weights (which for our purposes will be 0,1,2,3 or 4). The rendered
topics are determined by the chosen topics and generated by
renderTopics().

Authors choose the chosen topics (obviously). Choosing a topic
with weight 0 means "this is not part of this story, whatever other
topics may be chosen."

Rendered topics are roughly speaking the parents of those chosen.
Weights propagate up the topic tree. This is why a topic with
weight of 1 or 2 stays "sectional", because it does not have
sufficient weight to get into the mainpage nexus -- only topics
chosen with weight of 3 or 4 make it into the mainpage nexus.

(To pick one skin as preferred, authors will have to nudge one
topic or another up to "priority" -- see admin.pl?op=edit and its
Weight popup menu choices. That's the only reason "priority"
different from non-"priority" in that popup menu, so an author can
say "this story is both Apple and BSD, but I think it's more Apple.")

submission_topics_chosen and submission_topics_rendered work
the same way.

I honestly don't know if we should have a poll_topics_* and a
journals_topics_*, logically that makes sense, but it may be
overkill.

Discussion

  • Tim Vroom

    Tim Vroom - 2004-06-09

    Logged In: YES
    user_id=596132

    Sounds good and makes sense. I think I removed tid from
    some story selects. I'll go through my diffs and
    reintroduce those.

    Do we want to have a tid in the submissions table now too
    then. It seems like it'd make sense especially since the UI
    currently only allows a user to select one topic. In fact
    I'm kind of thinking submission_topics_chosen and
    submission_topics_rendered might not be necessary. The UI
    only allows for one tid to be selected. When an admin wants
    to add topics I'd imagine they do that is created from the
    submission.

     
  • Jamie McCarthy

    Jamie McCarthy - 2004-06-11
    • priority: 9 --> 1
    • summary: EVERYONE READ - topic data for stories --> Everyone read topic data for stories
     
  • Jamie McCarthy

    Jamie McCarthy - 2004-06-15
    • assigned_to: nobody --> jamiemccarthy
    • status: open --> closed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks