Perl / cgi / include file a la #include

Discussion in 'Perl Misc' started by me, Mar 26, 2010.

  1. me

    me Guest

    I have a perl script generating HTML code. I'd like to include some
    existing HTML files (e.g. header.htm, footer.htm) in the output,
    while the perl program will generate the majority of the html code.

    I know I can do a "require" statement and pull the files in while the
    perl program runs. I have a couple questions though:

    1. Is it possible to get the web server to parse the perl output and
    simply have a standard #include in the generated html that would
    include the header and footer just before delivery to the client? Or
    will the server always deliver the program output directly with no
    further parsing?

    2. If it's possible to put the #include in there (item 1 above), is
    this a more or less efficient way to deliver the code? In other words,
    does it make more sense to have the perl code run once and include all
    that's needed, or will the server be more efficient at doing the
    include? This specific implementation will be in a shared server
    environment, so I don't know that I can count on the included files
    being buffered anywhere on the server.

    Thanks,
     
    me, Mar 26, 2010
    #1
    1. Advertising

  2. me

    C.DeRykus Guest

    On Mar 25, 7:34 pm, me <> wrote:
    > I have a perl script generating HTML code. I'd like to include some
    > existing HTML files (e.g. header.htm, footer.htm) in the output,
    > while the perl program will generate the majority of the html code.
    >
    > I know I can do a "require" statement and pull the files in while the
    > perl program runs. I have a couple questions though:
    >
    > 1. Is it possible to get the web server to parse the perl output and
    > simply have a standard #include in the generated html that would
    > include the header and footer just before delivery to the client? Or
    > will the server always deliver the program output directly with no
    > further parsing?
    >
    > 2. If it's possible to put the #include in there (item 1 above), is
    > this a more or less efficient way to deliver the code? In other words,
    > does it make more sense to have the perl code run once and include all
    > that's needed, or will the server be more efficient at doing the
    > include? This specific implementation will be in a shared server
    > environment, so I don't know that I can count on the included files
    > being buffered anywhere on the server.
    >


    These are web server rather than Perl issues. If
    the server allows server-side includes. SSI's
    'include' command is an option. If SSI's aren't
    available, you could easily use Perl itself to
    read/insert a file: perldoc -q external. Or, to
    avoid a separate process, you could DIY with
    a short subroutine possibly using File::Slurp.

    --
    Charles DeRykus
     
    C.DeRykus, Mar 26, 2010
    #2
    1. Advertising

  3. me <> wrote:
    >I have a perl script generating HTML code. I'd like to include some
    >existing HTML files (e.g. header.htm, footer.htm) in the output,
    >while the perl program will generate the majority of the html code.


    A simple File::slurp and print() should do nicely.

    >I know I can do a "require" statement and pull the files in while the
    >perl program runs. I have a couple questions though:


    Aehmmm, probably not. Or how would perl interpret the require()d
    header.htm?

    >1. Is it possible to get the web server to parse the perl output and
    >simply have a standard #include in the generated html that would
    >include the header and footer just before delivery to the client? Or
    >will the server always deliver the program output directly with no
    >further parsing?


    That really has nothing to with Perl at all. And I can't see what would
    be stopping you from calling e.g. 'foobar.pl | cpp' instead of just a
    plain 'foobar.pl'

    >2. If it's possible to put the #include in there (item 1 above), is
    >this a more or less efficient way to deliver the code? In other words,
    >does it make more sense to have the perl code run once and include all
    >that's needed, or will the server be more efficient at doing the
    >include?


    I would guess this very much depends upon what server you are using,
    what features it has, and how it is configured. But in general terms
    starting additional processes is always expensive, so you want to avoid
    doing that as much as possible.

    On the other hand, maybe all you are looking for is really a simple
    templating system.

    jue
     
    Jürgen Exner, Mar 26, 2010
    #3
  4. me

    Uri Guttman Guest

    >>>>> "JE" == Jürgen Exner <> writes:

    >> 2. If it's possible to put the #include in there (item 1 above), is
    >> this a more or less efficient way to deliver the code? In other words,
    >> does it make more sense to have the perl code run once and include all
    >> that's needed, or will the server be more efficient at doing the
    >> include?


    JE> I would guess this very much depends upon what server you are using,
    JE> what features it has, and how it is configured. But in general terms
    JE> starting additional processes is always expensive, so you want to avoid
    JE> doing that as much as possible.

    JE> On the other hand, maybe all you are looking for is really a simple
    JE> templating system.

    and since my File::Slurp has been mentioned, i might as well bring up
    Template::Simple. as you said, the OP really is asking for a templater
    and doesn't know it. that module can do includes, substitutions and more
    and is very easy to learn and use. don't generate html directly from
    perl as it is noisy and annoying to handle all sorts of things.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Mar 26, 2010
    #4
  5. me

    me Guest

    On Fri, 26 Mar 2010 00:10:02 -0700, Jürgen Exner
    <> wrote:

    >me <> wrote:
    >>I have a perl script generating HTML code. I'd like to include some
    >>existing HTML files (e.g. header.htm, footer.htm) in the output,
    >>while the perl program will generate the majority of the html code.

    >
    >A simple File::slurp and print() should do nicely.
    >
    >>I know I can do a "require" statement and pull the files in while the
    >>perl program runs. I have a couple questions though:

    >
    >Aehmmm, probably not. Or how would perl interpret the require()d
    >header.htm?


    Yes... I discovered a little gotcha in that process. Open / Read works
    but I will check out Slurp.

    >>1. Is it possible to get the web server to parse the perl output and
    >>simply have a standard #include in the generated html that would
    >>include the header and footer just before delivery to the client? Or
    >>will the server always deliver the program output directly with no
    >>further parsing?

    >
    >That really has nothing to with Perl at all. And I can't see what would
    >be stopping you from calling e.g. 'foobar.pl | cpp' instead of just a
    >plain 'foobar.pl'


    I don't think I can do what you are suggesting as a cgi program.

    >>2. If it's possible to put the #include in there (item 1 above), is
    >>this a more or less efficient way to deliver the code? In other words,
    >>does it make more sense to have the perl code run once and include all
    >>that's needed, or will the server be more efficient at doing the
    >>include?

    >
    >I would guess this very much depends upon what server you are using,
    >what features it has, and how it is configured. But in general terms
    >starting additional processes is always expensive, so you want to avoid
    >doing that as much as possible.
    >
    >On the other hand, maybe all you are looking for is really a simple
    >templating system.


    Yes... that might work better although "templating" is overkill for
    this site as there is only one page that needs to be programmatically
    created.
     
    me, Mar 26, 2010
    #5
  6. me

    me Guest

    On Fri, 26 Mar 2010 03:39:42 -0400, "Uri Guttman"
    <> wrote:

    >and since my File::Slurp has been mentioned, i might as well bring up
    >Template::Simple. as you said, the OP really is asking for a templater
    >and doesn't know it. that module can do includes, substitutions and more
    >and is very easy to learn and use. don't generate html directly from
    >perl as it is noisy and annoying to handle all sorts of things.
    >


    Thanks, I will look into the Template module.
     
    me, Mar 26, 2010
    #6
  7. me <> wrote:
    >On Fri, 26 Mar 2010 00:10:02 -0700, Jürgen Exner

    [...]
    >>>will the server always deliver the program output directly with no
    >>>further parsing?

    >>
    >>That really has nothing to with Perl at all. And I can't see what would
    >>be stopping you from calling e.g. 'foobar.pl | cpp' instead of just a
    >>plain 'foobar.pl'

    >
    >I don't think I can do what you are suggesting as a cgi program.


    Again, this has nothing to do with the CGI program.
    Somewhere in the web server configuration there must be a description
    for what the server is supposed to do when the resource http:/..... is
    being requested. If the web server doesn't allow that description to be
    a shell command with a pipe, then still you could write a 1/2 line
    wrapper script which does nothing but call 'foobar.pl | cpp'.

    Now, I am not saying this is a good solution for your original problem,
    not at all. But it sure is possible.

    jue
     
    Jürgen Exner, Mar 26, 2010
    #7
  8. me

    Uri Guttman Guest

    >>>>> "m" == me <> writes:

    m> Yes... that might work better although "templating" is overkill for
    m> this site as there is only one page that needs to be programmatically
    m> created.

    'programmatically created' means template. you can do it by breaking up
    the html into parts and build it up in the template. you may still need
    code to mung the data with perl to work with the template but it will be
    easier than generating the html in perl. there are other advantages to
    using a template including allowing a designer to do the html/css and a
    coder to work on the perl. rarely can one person be very good at both.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Mar 26, 2010
    #8
  9. me

    ccc31807 Guest

    On Mar 25, 10:34 pm, me <> wrote:
    > I have a perl script generating HTML code. I'd like to include some
    > existing HTML files (e.g. header.htm, footer.htm) in the output,
    > while the perl program will generate the majority of the html code.


    This is a very, very common need.

    I create Perl modules which output HTML, and call the functions that
    return the HTML in my scripts. Like this:

    -----------HTML.pm------------------
    package HTML;

    ....

    sub print_header
    {
    my $title = shift;
    print qq(<?xml version="1.0" encoding="UTF-8" ?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <head>
    <title>$title</title>
    <link type="text/css" rel="stylesheet" href="http://site.css" />
    </head>
    <body>
    );
    }

    ....

    ---------------index.cgi-----------------
    use HTML;

    ....

    HTML::print_header($page);

    ....

    exit(0);

    CC
     
    ccc31807, Mar 26, 2010
    #9
  10. me

    Uri Guttman Guest

    >>>>> "c" == ccc31807 <> writes:

    c> On Mar 25, 10:34 pm, me <> wrote:
    >> I have a perl script generating HTML code. I'd like to include some
    >> existing HTML files (e.g. header.htm, footer.htm) in the output,
    >> while the perl program will generate the majority of the html code.


    c> This is a very, very common need.

    c> I create Perl modules which output HTML, and call the functions that
    c> return the HTML in my scripts. Like this:

    that doesn't return the html, it prints it directly.

    c> print qq(<?xml version="1.0" encoding="UTF-8" ?>

    c> HTML::print_header($page);

    a better style i teach is called "print rarely, print late". instead of
    printing directly, return the string you make up. build up the final
    page in a buffer (using .= is easiest) and then you can decide what to
    do with it. you can print to stdout as usual, print to a file for later
    use by the web server, print to a socket if desired. or more than one of
    those at the same time. by printing directly from the html subs you lose
    the flexibility. it is also a bit faster to call print one time than
    multiple times (.= is faster than print). and you can decide where to
    print at the higher level which keeps the logic cleaner. i have seen
    requests for dual handles which can print to a file and to stdout (i
    think IO::Tee does that) but this is even easier and faster. so the rule
    print rarely means build up a full string in a buffer before you print
    it. print late means print only when you are done and can decide where
    to print it.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Mar 26, 2010
    #10
  11. me

    ccc31807 Guest

    On Mar 26, 5:53 pm, "Uri Guttman" <> wrote:
    > a better style i teach is called "print rarely, print late". instead of
    > printing directly, return the string you make up.


    In Paul Graham's book 'On Lisp' in chapter 3, 'Functional
    Programming', he makes an extended case for this, which I find
    compelling but not necessarily persuasive. I've been slowly making my
    way through the dead tree version of HOP by MJD, and I also have found
    a lot to like in that. My problems are (as Graham notes) an imperative
    habit, a lack of opportunity, and little discretionary time.

    > build up the final
    > page in a buffer (using .= is easiest) and then you can decide what to
    > do with it.


    I actually use this quite a bit in my day job. I almost always find
    myself constructing and deconstruction strings and arrays (and
    hashes), moving between them, and as a result I do this quite a bit.
    (I've also found the ||= operator useful.)

    > you can print to stdout as usual, print to a file for later
    > use by the web server, print to a socket if desired. or more than one of
    > those at the same time. by printing directly from the html subs you lose
    > the flexibility. it is also a bit faster to call print one time than
    > multiple times (.= is faster than print). and you can decide where to
    > print at the higher level which keeps the logic cleaner.


    As an explanation if not a defense of what I wrote previously, most of
    my HTML consists of front ends to databases, and most of the heavy
    lifting is the SQL part. When I write my HTML files, I use variables
    to trigger both the SQL and the HTML. I quite frequently end up with a
    cgi script that looks something like this (illustration only):

    HTML::print_header(@vars1);
    HTML::print_banner(@vars2);
    HTML::print_menu(@vars3);
    my $hashref = SQL::get_list($var1);
    HTML::print_content($hashref);
    $hashref = SQL::get_calendar($var2);
    HTML::print_content($hashref);
    HTML::print_footer();
    exit;

    > i have seen
    > requests for dual handles which can print to a file and to stdout (i
    > think IO::Tee does that) but this is even easier and faster. so the rule
    > print rarely means build up a full string in a buffer before you print
    > it. print late means print only when you are done and can decide where
    > to print it.


    In this case, I am 'printing' a response to an HTTP request, not a
    physical device. I also do some JSP, and for some reason, the JSP
    doesn't seem any faster than my CGI, and sometimes is noticeably
    slower.

    CC
     
    ccc31807, Mar 26, 2010
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jürgen Exner

    Re: CGI Perl "use CGI" statement fail

    Jürgen Exner, Jul 31, 2003, in forum: Perl
    Replies:
    0
    Views:
    1,511
    Jürgen Exner
    Jul 31, 2003
  2. praba kar

    Python-cgi or Perl-cgi script doubt

    praba kar, Jul 30, 2005, in forum: Python
    Replies:
    1
    Views:
    710
    Michael Sparks
    Jul 30, 2005
  3. excord80
    Replies:
    17
    Views:
    769
    J Kenneth King
    Jan 29, 2009
  4. shumsta
    Replies:
    1
    Views:
    283
    Fabian Pilkowski
    Jul 22, 2005
  5. kath
    Replies:
    4
    Views:
    701
    J. Gleixner
    Apr 9, 2007
Loading...

Share This Page