Seperating Perl code and HTML using Here Documents...

Discussion in 'Perl Misc' started by barrybevel, Jan 28, 2007.

  1. barrybevel

    barrybevel Guest

    Hi,
    I have a Perl cgi program which can return a number of different HTML
    pages based on input.
    I am using Here Documents to hold the HTML pages with $variables to
    output dynamic content.
    The way I'm doing it is becoming very sloppy and unmanageable.

    Can someone suggest a better/cleaner way of seperating dynamic HTML
    and perl code?

    Here's an example of what I'm doing (shame on me):

    my $webpage;
    my $var1;
    my $var2;
    ....
    if( ...) {
    open (FILE, 'good-page.pl') or die "blah...";
    my @code = <FILE>;
    eval join("\n", @code);

    } else {
    open (FILE, 'bad-page.pl') or die "blah...";
    my @code = <FILE>;
    eval join("\n", @code);
    }
    ....
    print "http headers...";
    print $webpage;

    ############################################

    # good-page.pl

    $webpage = <<PAGE;
    <html>
    ....
    Good Page $var1
    ....
    </html>
    PAGE

    ############################################

    # bad-page.pl

    $webpage = <<PAGE;
    <html>
    ....
    Bad Page $var2
    ....
    </html>
    PAGE
     
    barrybevel, Jan 28, 2007
    #1
    1. Advertisements

  2. barrybevel

    Uri Guttman Guest

    SP> Have a look at the Template::Toolkit or HTML::Mason modules on CPAN.

    or even Template::Simple which is much easier to learn and use. call it
    david vs goliath of template modules. 4 markups and 150 lines of module
    code vs massive code and docs to learn. :)

    but i do agree templating is the way to go instead of numerous here
    docs.

    uri
     
    Uri Guttman, Jan 28, 2007
    #2
    1. Advertisements

  3. barrybevel

    barrybevel Guest

    Thanks Sherm & Uri, very quick response.

    I'll have a look at:

    Template::Simple
    Template::Toolkit
    HTML::Mason

    Regards...
     
    barrybevel, Jan 28, 2007
    #3
  4. HTML::Template may also fit the bill.

    Mark
     
    Mark Clements, Jan 28, 2007
    #4
  5. barrybevel

    Peter Scott Guest

    Don't forget HTML::Template.

    If, for some reason, separating the HTML into separate template files
    isn't a good idea in your design, try Inline::File. (But it would be a
    rare reason.)
     
    Peter Scott, Jan 28, 2007
    #5
  6. barrybevel

    barrybevel Guest

    Mark, thanks for the HTML::Template suggestion I will keep it in mind.

    Michele,
    My requirements are not that complex, I just need to put a few
    variables in a HTML page,
    so I'm going to implement your suggestions straight away.
    If my code is still too complex I can always use one of the modules
    suggested.
    But it looks like I wont need to, your ideas look like they will make
    a huge difference.
    Thanks very much.
     
    barrybevel, Jan 28, 2007
    #6
  7. barrybevel

    Uri Guttman Guest

    MD> So these external Perl scripts only "load" a page into a scalar. One
    MD> may wonder why you don't get rid of the Perl code and directly load
    MD> the HTML pages. Of course the answer is that you interpolare $var1,
    MD> $var2, etc. This is where one sees the usefulness of a templating
    MD> system. If things are really this simple, you may roll your own
    MD> templating system though, so you may have a file like:

    MD> <html>
    MD> ...
    MD> Good Page [var1]
    MD> ...
    MD> </html>

    MD> called good-page.tpl, and in your Perl script you would do something
    MD> like

    MD> my %config=( var1 => 'foo',
    MD> var2 => 'bar' );
    MD> my $default='baz';

    MD> my $webpage;
    MD> if( whatever() ) {
    MD> $webpage=load('good-page.tpl');
    MD> } else {
    MD> $webpage=load('bad-page.tpl');
    MD> }
    MD> $webpage =~ s/\[(\w+?)\]/$config{$1}||$default/ge;

    MD> sub load {
    MD> my $file=shift;
    MD> open my $fh, '<', $file
    MD> or die "Can't open `$file': $!\n";
    MD> local $/;
    MD> scalar <$fh>;
    MD> }

    MD> Of course, the more you need to add features, the more you will create
    MD> yet another full fledged templating system, with all the difficulties
    MD> of doing so, so you will realize that maybe it would have been better
    MD> to choose a ready made one in the first place. It all really depends
    MD> on how complex your requirements actually are.

    that exactly is how template::simple evolved. i had done trivial scalar
    expansions many times and i just added the minimal set of features i
    needed over time (chunks, implied loops, include files) until i had
    something interesting and productive. then i cpan'ed it into
    template::simple. even with such short pseudo code as you show there be
    subtle issues and quickly desired features that a module is the way to
    go even for beginners. it will amaze the OP how fast he will want
    conditionals and loops and nesting. as soon as he needs to fill in
    tables and rows he will scream when trying to do it from scratch. just
    my observations on how simple requirements never stay simple. so it is
    best to use a template module from the beginning IMO (of course i didn't
    and wrtoe my own but i am kinda that way).

    uri
     
    Uri Guttman, Jan 28, 2007
    #7
  8. barrybevel

    DJ Stunks Guest

    very funny :))

    according to Simon's recollection of a clp.moderated thread, every
    Perl programmer eventually tries to re-invent the following wheels:

    1) templating system :-D
    2) database abstraction layer
    3) HTML parser
    4) command-line argument processor
    5) date/time manipulation module

    It's nice to see that despite everything that's going on in the world
    these days, the universe is still obeying her natural laws :p

    -jp
     
    DJ Stunks, Jan 28, 2007
    #8
  9. barrybevel

    Uri Guttman Guest

    MD> If things are really this simple, you may roll your own
    MD> templating system though, so you may have a file like:

    DS> very funny :))

    DS> according to Simon's recollection of a clp.moderated thread, every
    DS> Perl programmer eventually tries to re-invent the following wheels:

    DS> 1) templating system :-D

    as i said, i did many dinky ones until it bloated to 37 lines of code!

    DS> 2) database abstraction layer

    sorta did that with a message passing wrapper in stem for dbi. it works
    well but isn't an abstraction layer. i do plan a proper abstraction one
    day that will not be anything like what is out there. more for an
    abstract persistance backend than a classic dbms.

    DS> 3) HTML parser

    never will try that.

    DS> 4) command-line argument processor

    my first perl5 project was one of those. never did publish/cpan it and i
    don't even use it. interesting learning experiment for me. it is on
    sysarch.com somewhere. still is very different than most (table driven
    with lots of interesting features). damian conway implemented most of
    those in his.

    DS> 5) date/time manipulation module

    never will try that. too much human cruft to deal with.

    DS> It's nice to see that despite everything that's going on in the world
    DS> these days, the universe is still obeying her natural laws :p

    so i have only tried 3 of those (and only one proper success). i only
    tackle these types of problems when i need it myself and i rarely agree
    with how they are done on cpan. template::simple is my case in point for
    how to really abstract out the core needs and make it simple to use and
    to code.

    i am currently working on CMS::Simple (which uses Template::Simple of
    course) which will support a simple plain text content format with
    minimal markup, flexible sharing of content and template components,
    custom filtering (with a core lib of filters) and a very clean data flow
    which is easy to understand and change. this is meant for any form of
    publishing but will initially be web centric to start. i haven't seen
    anything that allows for the sharing of content and templates in the way
    this does. and sharing is the key to simplicity as you can build up libs
    of stuff at a high and low level (e.g. a single page body template
    includes all custom pages which are rendered as needed). again, my views
    of what is important (maximum sharing and reuse and minimal complexity)
    don't jibe with the cms modules out there.

    uri
     
    Uri Guttman, Jan 28, 2007
    #9
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.