|
Customizing the Story_summary Block
|
|
By imrdkl2 , Section Help! []
Posted on Sun Jul 18, 2004 at 12:00:00 PM PST
|
 |
|
The story_summary block provides an important "first impression" for visitors and new users to a given scoop site. Its role in constructing the front page, via summarizing all of the current FP stories individually, is clearly critical for introducing and maintaining the look and feel of any given site.
To that end, a relatively proficient scoop hacker
has given
this site
a very different and unique "look and feel", apparantly via recoding certain effects produced within the story_summary block. Now, I don't know whether he's done it via direct changes to lib/Scoop/Stories/Views.pm and friends, or via a box of some sort - but it seems clear that several features which are embedded in the code have been altered, somehow.
As it turns out, I too would like to modify the look and feel of story_summary. Inside, I describe my needs, and provide some box code which seems to work ok for the task, for your evaluation and criticism.
|
| For the sake of completeness (and please forgive my limited understanding here) the story_summary block is called multiple times during the build of each front page and each section (including diary section) listing page - it provides CONTENT for index_template. Story_summary is the block which sets up the text and formatting for the story title, author, section, topic, posting-date, intro-text, and most importantly for me, comment stats, story stats (words/bytes), and the link to Full Story. Depending on the user preferences, it may be called from 10-50 times per section listing view or FP view.
So, the "relatively proficient" scoop hacker I mentioned previously has made several modifications to story_summary on dailykos. First, he's rearranged the |by| and the |info| blocks so that they appear before the |intro_text| - but that's easy. And that's how it works on k5, too. Where things get interesting is when we look at |section_link|, |stats|, and |info| blocks which are instantiated in story_summary, and which appear on dailykos.com. First, the |section_link| and |info| are somehow "merged" into a single Section::Story pair of links. Next, the |stats| block is printing only the number of comments - the bits about how many words/bytes are in the story are completely gone, even though they're hardcoded in lib/Scoop/Stories/Views.pm. Nifty!
So, the folks I'm trying to help out would like very much to do something like this on their website. To that end, I've written the following box code, which replaces the |stats| block in story_summary. I call it simply as |BOX,my_stats,|sid||, passing in the sid which allows me to get enough information to reproduce the statistics which are built in to (hardcoded) in |stats|, via the call to sub story_links{} from sub frontpage_view{}. Please consider:
# Get S and the sid
my $S = shift;
my $sid = "$ARGS[0]";
# Initialize some stuff, based on code from the story_links subroutine in Views.pm
my $comment_plural = $S->{UI}->{BLOCKS}->{comment_plural} \|\| 's';
my $show = $S->{UI}->{VARS}->{show_new_comments};
my $comment_word = $S->{UI}->{BLOCKS}->{comment_word} \|\| 'comment';
my $section = $S->_get_story_section($sid);
# Fetch the count for both topical and editorial comments, as well as "new" comments.
# We'll only be displaying the number of topical comments and new topical comments
my ($topical, $editorial, $pending, $highest) = $S->_comment_breakdown($sid);
# Since the $story object doesn't seem to be available at story_summary time, we
# need to ask the database whether a given story has bodytext, so that the correct string
# can be printed out, indicating that this is it, or that there's more.
# Here, we're going to use some cache, to limit the number of hits on the db
unless(exists($S->cache->{CACHE}->{bodytext_lengths}->{$sid})){
my ($rv, $sth) = $S->db_select({
WHAT => 'length(bodytext)',
FROM => 'stories',
WHERE => qq{sid = '$sid'}});
my $lengths = $sth->fetchall_arrayref();
$sth->finish();
$S->cache->{CACHE}->{bodytext_lengths}->{$sid} = $lengths->[0]->[0];
}
# Setup the appropriate page text based on whether the bodytext has length
my $text = ($S->cache->{CACHE}->{bodytext_lengths}->{$sid} > 0)?
'%%readmore_txt%%' :
'%%no_body_txt%%';
# just in case you don't have no_body_txt set
$text = ($text eq '') ? 'Comments >>' : $text;
# Construct the link based on perms
my $content = qq\|<A CLASS="light"
HREF="%%rootdir%%/story/$sid">$text</A> \| unless
(($S->have_section_perm(hide_read_comments => $section)) &&
($S->have_section_perm(hide_post_comments => $section)));
if ($S->have_perm('story_list')) {
$content .= qq\| [<A CLASS="light"
HREF="%%rootdir%%/admin/story/$sid">edit</A>] \|;
}
# If there are topical comments, show the count
if( $topical){
$content .= sprintf( "%s$S->{UI}->{BLOCKS}->{comment_num_format_start}%d
$S->{UI}->{BLOCKS}->{comment_num_format_end}%s%s", "(",
$topical,$comment_word,
$topical > 1 ? $comment_plural : ''
) ;
# If there are new comments, indicate how many (minus editorial)
if($show){
my $num_new = $S->new_comments_since_last_seen($sid);
if($num_new){
($num_new > $topical) && ($num_new = $topical); # If more than topical,
set equal to topical XXX
my $new_comment_format_start =
$S->{UI}->{BLOCKS}->{new_comment_format_start} \|\| '<b>';
my $new_comment_format_end = $S->{UI}->{BLOCKS}->{new_comment_format_end}
\|\| '</b>';
$content .= ", $new_comment_format_start$num_new$new_comment_format_end new";
}
}
$content .= ")";
}
return $content;
Now, with this code, I aim to accomplish several things, hopefully clear from the comments in the code, but outlined here for competeness' sake:
- Provide the (perms checked) link to the story, with appropriate text based on whether the story has body text. In the case of dailykos.com, when there is no bodytext, only "Link and Discuss" is printed. If there is bodytext, then "There's More" is printed.
- Completely eliminate the "N Blocks/Bytes in story" text
- Indicate the number of topical comments only
- Indicate the number of new topical comments
So, that pretty much demonstrates the limits of my understanding and competence here. What I'd like to know then, are several things:
- Does this seem a reasonable approach?
- How intensive is this code, really? It duplicates several calls which are already in sub frontpage_view{} and sub story_links - how will it affect the db load on a heavily viewed site, do you suppose?
- Is the $story object really unavailable? Or am I missing something fundamental, and need not ask the database about bodytext at all?
- Anything else?
Any and all help or feedback is appreciated.
|
|
|
Story Views
|
|
101 Scoop users have viewed this story.
|
|
