Since we're giving coding exmaples for ideas... One way to do it with a
Template enginer:
use Template;
my $calOutput = getCalendar('week');
print "Content-type: text/html\n\n" . $calOutput ;
sub getCalendar {
my $type = shift @_;
my $template = Template->new( INCLUDE_PATH =>
$runTimeData->{htmlTemplateDir
} ) ;
my $templFile = getCalendarTemplate($type);
my $templateData = {} ;
my $outputText = '' ;
$template->process( $runTimeData->{htmlStatusTemplateFile},
$templateData, \$outputText );
return($outputText);
}
sub getCalendarTemplate {
my $type = shift @_;
my %calendarFiles = (
'month' => 'calMonth.templ',
'week' => 'calWeek.templ',
'year' => 'calYear.templ');
return($calendarFiles{$type});
}
Note how easy it would be to change just what makes up the output of any
given calendar. Because it's in a template, you can change the
look/feel/layout of any of them, without ever changing the program
itself. In addition, it would be pretty easy to add support for other
"types", while minimizing the complexity of the program itself.
-Alex
drieux wrote:
>
> On Monday, April 15, 2002, at 02:40 , Ryan wrote:
>
>> --At 4/15/02 4:25 PM -0500, PK Eidesis wrote:
>>
>>> sub makeCalendar {
>>> $type = @_;
>>> if($type eq "month") {
>>> print "all the code for a monthly calendar";
>>> elsif($type eq "week") {
>>> print "all the code for a weekly calendar";
>>> elsif($type eq "year") {
>>> print "all the code for a yearly calendar";
>>> }
>>> }
>>
>>
>> Personally, I'd change all those prints to returns -
>
>
> We agree that they should be 'returns' but why not
> the usual sort of predef approach
>
>
> sub makeCalendar {
> my ($type) = @_;
> my $retString = ''; # safety set
>
> if($type eq "month") { $retString = "all the code for a monthly
> calendar"
> ;
> } elsif($type eq "week") { $retString = "all the code for a weekly
> calendar";
> } elsif($type eq "year") { $retString = "all the code for a yearly
> calendar"; }
>
> $retString ; # the default value would be returned on error case
>
> }
>
> Assuming that the branch tree is built in the order of
> expected usage - or one might go with the fact that the
> hash is the core of the perl reality space - and one should
> have a reasonable expectation that it will be kosher:
>
> sub doCal {
> my ($type) = @_;
> my %retHash = (
> 'month' => 'all the code for a monthly calendar',
> 'week' => 'all the code for a weekly calendar',
> 'year' => 'all the code for a yearly calendar',
> );
>
> $retHash{ $type }; # defaults to empty if not used
>
> } # end doCal
>
> Since this is when the player starts thinking in terms of:
>
> sub doMon { my $string = "all Your Months Be Mine"; }
>
> sub doWeek {my $string = "all Your Weeks Be Mine";}
>
> sub doYear { my $string = "this is the year line";}
>
> sub doCal {
> my ($type) = @_;
> my %retHash = (
> 'month' => \&doMon,
> 'week' => \&doWeek ,
> 'year' => \&doYear ,
> );
>
> no strict 'refs'; # must skank around the ref indirection here
> my $retString = $retHash{ $type }->()
> if ( $retHash{$type } ); # if we have it
>
> $retString ; # return what ever the function passed
>
> } # end doCal
