PERL Beginners - FW: Html within code

Author

FW: Html within code

Reginald Johnson

2007-07-25, 6:59 pm

>
> Is coding this way wrong? By "this way" I mean where you don't use a
> module to write html, but instead do it within the code by using print
> "Content-type: text/html", "\n\n";
>
> Example program
>
> #!/usr/bin/perl
>
> print "Content-type: text/html", "\n\n";
>
> open (OMARFILE, "<junk" || die "input file cannot be openned:$!\n");
>
> print <<EOF
> <html>
> <head>
> <title>Omar Metrics</title></head>
> <body>
> <div align=center>
> <h1>TSM OMAR STATISTICS</h1>
> </div>
> EOF
> ;
> while ( $line =<OMARFILE> ) {
> chomp($line);
> if ($line ne "" ) {
> ($fdt,$tod,$cap,$util,$actnodes,$gb,$att
,$comp,$comppct,$bdays,$restor
> ecnt,$req,$setups) = split(/ /,$line);
>
> print <<EOF
>
> <div align=center>
> <table border="1" cellspacing="0" cellpadding="0" width="50%">
> <tr>
> <td align="center" valign="middle" colspan="2"><b>OMAR Metrics
> for $fdt to $tod </b></td>
> </tr>
> <tr>
> <td valign="middle" bgcolor="#00FFFF">Backup Completion
> Percentage</td>
> EOF
> ;
> if ($comppct >= 98) {
> print <<EOF
> <b><td bgcolor=00FF99>$comppct</td></b>
> </tr>
> <tr>
> EOF
> ;
> } #end if
> else {
> print <<EOF
> <b><td bgcolor=YELLOW>$comppct</td></b>
> </tr>
> <tr>
> EOF
> ;
> } #end else
> print <<EOF
>
> <td valign="middle" bgcolor="#00FFFF">Total Backup
> Attempts</td>
> <td><b>$att</b></td>
> </tr>
> <tr>
> <td valign="middle" bgcolor="#00FFFF">Total Backup
> Completions</td>
> <td><b>$comp</b></td>
> </tr>
> <tr>
> <td valign="middle" bgcolor="#00FFFF">Total Client Disk
> Capacity</td>
> <td><b>$cap</b></td>
> </tr>
> <tr>
> <td valign="middle" bgcolor="#00FFFF">Total Client Disk
> Utilization</td>
> <td><b>$util</b></td>
> </tr>
> <tr>
> <td valign="middle" bgcolor="#00FFFF">Total Active Client
> Nodes</td>
> <td><b>$actnodes</b></td>
> </tr>
> <tr>
> <td valign="middle" bgcolor="#00FFFF">Total Restores</td>
> <td><b>$restorecnt</b></td>
> </tr>
> <tr>
> <td valign="middle" bgcolor="#00FFFF">Total Business Days</td>
> <td><b>$bdays</b></td>
> </tr>
> <tr>
> <td valign="middle" bgcolor="#00FFF">Gigabytes Written To
> Tape</td>
> <td><b>$gb</b></td>
> </tr>
> <tr>
> <td valign="middle" bgcolor="#00FFF">Remedy Client
> Request</td>
> <td><b>$req</b></td>
> </tr>
> <tr>
> <td valign="middle" bgcolor="#00FFF">New Client Setups</td>
> <td><b>$setups</b></td>
> </tr>
> </table>
> <br>
> </div>
> </body>
> </html>
>
> EOF
> ;
> } #end if
> else {
> next;
> } #end else
>
> } #end while
> close(OMARFILE);
>
> Sample junk file
>
> '06/01/2007 00:00' '06/30/2007 23:59' 235 118.75 566
> 43 11 10 98.900 21 204 2
>
> '05/01/2007 00:00' '05/31/2007 23:59' 230 113 560
> 41 12,324 12,025 97.500 23 33 21
>
> '04/01/2007 00:00' '04/30/2007 23:59' 227 107 552
> 38,807.0 11 11,784 98.300 21 15 24
--------------------------------------------------------

This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing.
--------------------------------------------------------

"Please consider the environment before printing this email."

Ovid

2007-07-25, 6:59 pm

--- "Johnson, Reginald (GTI)" <reggie_johnson@ml.com> wrote:
[color=darkred]
> a
> print
> openned:$!\n");

<snip>

It's definitely not recommended. There are a number of issues with
this, but regarding the HTML, if you produce it, put it in a template
such as HTML::Template, Template Toolkit or similar. With that, you
can just pass the relevant data to your template and keep your Perl
code clean. It makes it easier to debug both the HTML *and* the Perl.

If you *must* have self-contained HTML (not recommended), then at least
encapsulate it into subroutines which don't obscure the main flow of
the program.

Cheers,
Ovid

--
Buy the book - http://www.oreilly.com/catalog/perlhks/
Perl and CGI - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog - http://use.perl.org/~Ovid/journal/

Tom Phoenix

2007-07-26, 9:58 pm

On 7/25/07, Johnson, Reginald (GTI) <reggie_johnson@ml.com> wrote:

> open (OMARFILE, "<junk" || die "input file cannot be openned:$!\n");

No matter what virtues your technique has or lacks, this particular
line is surely broken; it will never die, even if the file can't be
opened. Check the table of precedence in the perlop manpage. Cheers!

--Tom Phoenix
Stonehenge Perl Training

Mr. Shawn H. Corey

2007-07-26, 9:59 pm

Tom Phoenix wrote:
> On 7/25/07, Johnson, Reginald (GTI) <reggie_johnson@ml.com> wrote:
>
>
> No matter what virtues your technique has or lacks, this particular
> line is surely broken; it will never die, even if the file can't be
> opened. Check the table of precedence in the perlop manpage. Cheers!

Wow, lots of words; no help.

Things that are not in the documentation:

open my $omarfile, '<', "junk" or die "input file \"junk\" cannot be opened; $!";

Note the use of the lexical, 'my $omarfile', file handler.

Note the use of the tri-argument open.

Note the use of 'or die'.

(Note the correct spelling.)

Reading documentation is good; but it out of date with respect to best practices. Reading `perldoc perlop` will not correct the errors in the statement. Reading `perldoc -f open` will tell you what's possible but not what's the best practice.

--
Just my 0.00000002 million dollars worth,
Shawn

"For the things we have to learn before we can do them, we learn by doing them."
Aristotle

Ken Foskey

2007-07-29, 6:59 pm

On Thu, 2007-07-26 at 20:42 -0400, Mr. Shawn H. Corey wrote:[color=darkred]
> Tom Phoenix wrote:

The brackets are in the wrong place.

The other answers were just far to clever & cryptic.

--
Ken Foskey
FOSS developer

Rob Dixon

2007-07-29, 6:59 pm

Ken Foskey wrote:
>
> On Thu, 2007-07-26 at 20:42 -0400, Mr. Shawn H. Corey wrote:
>
> The brackets are in the wrong place.
>
> The other answers were just far to clever & cryptic.

Hehe how true.

What this

open (OMARFILE, "<junk" || die "input file cannot be openned:$!\n");

does is

open(OMARFILE, ("<junk" || die "input file cannot be openned:$!\n"));

and because "<junk" is true, die is never called and we have just

open(OMARFILE, "<junk");

What I recommend instead is

open OMARFILE, 'junk' or die "Input file cannot be opened: $!";

Rob

Mr. Shawn H. Corey

2007-07-29, 6:59 pm

Rob Dixon wrote:
> What I recommend instead is
>
> open OMARFILE, 'junk' or die "Input file cannot be opened: $!";

The recommended usage of open is:

open my $omarfh, '<', 'junk' or die "Input file 'junk' cannot be opened: $!";

The three argument is preferred as a malicious user could enter a file name that starts with '>'

The lexically scoped file handler is preferred since it won't interfere with other file handlers.

--
Just my 0.00000002 million dollars worth,
Shawn

"For the things we have to learn before we can do them, we learn by doing them."
Aristotle

Rob Dixon

2007-07-29, 6:59 pm

Mr. Shawn H. Corey wrote:
>
> Rob Dixon wrote:
>
>
> The recommended usage of open is:
>
> open my $omarfh, '<', 'junk' or die "Input file 'junk' cannot be
> opened: $!";
>
> The three argument is preferred as a malicious user could enter a file
> name that starts with '>'
>
> The lexically scoped file handler is preferred since it won't interfere
> with other file handlers.

Sure, I agree Shawn, but I also think it's nice to change the OP's code
as little as possible to turn it into something that works as well as
possible.

Plus most of the published literature still uses bareword filehandles
and offering something different unnecessarily complicates things for
beginners.

And there is no way that line of code could be compromised so the mode
parameter is unnecessary.

Rob

Mr. Shawn H. Corey

2007-07-30, 7:00 pm

Jay Savage wrote:
> On 7/29/07, Mr. Shawn H. Corey <shawnhcorey@magma.ca> wrote:
>
> It is preferred in code that accepts file names as user input and
> doesn't perform taint checking. If the program uses a hard-coded
> filenames, then no hurt, no foul. There can be no malicious user until
> there is first a user.

There's no time like the present to learn good habits.

--
Just my 0.00000002 million dollars worth,
Shawn

"For the things we have to learn before we can do them, we learn by doing them."
Aristotle

Rob Dixon

2007-07-30, 9:59 pm

Mr. Shawn H. Corey wrote:
> Jay Savage wrote:
>
> There's no time like the present to learn good habits.

When someone is trying very hard to learn to write Perl that works at
all, I think it is /not/ the time to regale him with the rigours of
professional programming.

Rob

Mr. Shawn H. Corey

2007-07-31, 7:59 am

Rob Dixon wrote:
> When someone is trying very hard to learn to write Perl that works at
> all, I think it is /not/ the time to regale him with the rigours of
> professional programming.
>
> Rob
>

Programming is a rigorous discipline. Learning to do things right the first time around achieves two things:

1. You don't have to unlearn bad habits before you learn the good ones.

2. Understanding the concepts behind the practice is easier.

--
Just my 0.00000002 million dollars worth,
Shawn

"For the things we have to learn before we can do them, we learn by doing them."
Aristotle

Rob Dixon

2007-08-01, 7:00 pm

Mr. Shawn H. Corey wrote:
>
> Rob Dixon wrote:
>
>
> Programming is a rigorous discipline. Learning to do things right the
> first time around achieves two things:
>
> 1. You don't have to unlearn bad habits before you learn the good ones.
>
> 2. Understanding the concepts behind the practice is easier.

I disagree, but I can see I'm not going to change your mind.

I'm just glad you didn't teach me to program.

Rob

Sponsored Links