Seperating Perl code and HTML using Here Documents...

B

barrybevel

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
 
U

Uri Guttman

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
 
B

barrybevel

Thanks Sherm & Uri, very quick response.

I'll have a look at:

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

Regards...
 
M

Mark Clements

Thanks Sherm & Uri, very quick response.

I'll have a look at:

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

HTML::Template may also fit the bill.

Mark
 
P

Peter Scott

Thanks Sherm & Uri, very quick response.

I'll have a look at:

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

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.)
 
B

barrybevel

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.
 
U

Uri Guttman

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
 
D

DJ Stunks

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

that exactly is how template::simple evolved.
<snip>
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).

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
 
U

Uri Guttman

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
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,581
Members
45,056
Latest member
GlycogenSupporthealth

Latest Threads

Top