jcwren has asked for the wisdom of the Perl Monks concerning the following question:

I'm curious as to what other people do when it comes to generating complex pages of HTML from a perl script.

My typical method is that I design the web pages in HotMetal, and use a super-classed version of the HTML::Parser module that does variable substitution (and more) for all the dynamic stuff.

I look at a page like the main page of the Monastery, or SlashDot, and wonder how it's managed. I'm familiar with the CGI module, but formatting the perl source so that it's readable has always been a problem. I prefer my HTML indented, to the effect of:

<table ...>
  <tr>
    <td><p>This is some text</p></td>
  </tr>
</table>

[download]

I have yet to find a way of formatting that in perl that allows me to understand at a glance how the page is going to look. I also know that I can use some of the "fancy" (read: highly compressed) formatting as shown in the CGI.pm docs, but I don't consider that maintainable (from the standpoint of not using the CGI module everyday, and coming back to it in a few months).

I'm proficient enough in HTML, but I don't want to "think" about writing in HTML. I'd rather "think" about my writing in Perl. This is why I use pages that I can design (and others can edit) in an HTML editor.

So, monks, friars, saints, and the lot of you, what's your opinion? How do you manage your massive amounts of HTML?

--Chris

Replies are listed 'Best First'.
Re: Managing large CGI pages
by KM (Priest) on Jun 07, 2000 at 21:07 UTC
    Have you tried using template pages, HTML::Mason, or simply using here documents? Generally, when I am doing CGI which creates HTML that is quasi-dynamic (as in it looks the same, but certain values may change) and a non-Perl person is maintaining the HTML portion, I generally like to give them a template to use or a here doc. I have even used the __DATA__ token to allow them to do whatever they need to below it. But, using things like Mason will allow you to easily change HTML on many pages. I have also used Apache::Sandwich to allow for easy changes in headers and footers. I believe HTML::WWWTheme also does something of this nature (with nav bars and such), and Apache::SetWWWTheme. So, there are plenty of options out there.

    Cheers,
    KM

[reply]
Re: Managing large CGI pages
by swiftone (Curate) on Jun 07, 2000 at 21:30 UTC
    I use Text::Template, which helps seperate the HTML from the perl code. See my posts at Node 12215 (in the thread Design vs. Code vs. Maintenance) and Node 14368 (in the thread Perl solutions for large websites?)

    Basically Text::Template lets you embed Perl code into HTML. This can be a complete program, or a variable (the latter is the way I recommend). Thus you can have a perl program that does all the calculating, then dumps variables into an HTML file. Text::Template is flexible enough to support just about any situation, and you avoid the "my site doesn't work like that" problems of full site-maintainers such as HTML::Mason.

[reply]
Re: Managing large CGI pages
by cwest (Friar) on Jun 07, 2000 at 21:32 UTC
    Considering the Monistary as an Example... I would go with mod_perl. I would write a simple template system, perhaps a normal Perl module called Monistary::Template and use that for all my page formatting needs.

    I would then go on to build the mod_perl modules. One (that get's pre loaded when the httpd server starts) would be called Monistary::Nodes that would handle all the node retrieval.

    Next would be things like Monistary::SeekersOfWisdom... but then again, do we really need a module for each section? I'm not too sure we do since everything is a node, after all.

    Better idea IMHO would be to write Monistary (aka. Monistary.pm)

    Using apache, Monistary would govern everything about the site as follows: 

    <Location />
  SetHandler perl-script
  PerlHandler Monistary
</ Location>
    According to the way everything seems to be handled by index.pl here, I think mod_perl isn't in use, at least the way I'm suggesting.

    As for HTML handling? I'd go with the aformentioned template system... there are some great modules already in existence to subclass and take advantage of. Enjoy! 

    --
Casey
[reply]
Re: Managing large CGI pages
by t0mas (Priest) on Jun 07, 2000 at 22:04 UTC
    I usually create (with a simple editor, I don't trust complex tools...) a header, footer and body template. I parse the body template and parse it (with perl), changing certain tags (or whatever) and then just print the header, body and footer.
    I usually do cgi-applications so header and footer usually stays the same all the time. The body usually gets its data from DBI.

    /brother t0mas
[reply]
Re: Managing large CGI pages
by a (Friar) on Jun 08, 2000 at 06:50 UTC
[reply]
RE: Managing large CGI pages
by JanneVee (Friar) on Jun 07, 2000 at 23:18 UTC
    It depends all above given suggestions work for me. But for simple managing I usually manage things with the wonderful. 
    print <<EndOfHtml;
 <B>put your HTML here!</B>
EndOfHtml

    [download]
    It gives a good separation of what is perl and what is put out on the page as HTML.
[reply]
[d/l]
RE: Managing large CGI pages
by flyfishin (Monk) on Jun 08, 2000 at 00:08 UTC
    I haven't worked with it much but HTML::Template seems like a pretty slick way to keep HTML and Perl in separate files but be able to pass information from the Perl script to the HTML page of choice. It is incredibly easy to setup and learn, if I can do it anyone can.
[reply]
Re: Managing large CGI pages
by plaid (Chaplain) on Jun 08, 2000 at 00:57 UTC
    I'm also a fan of here documents, and sometimes of embedded-code solutions such as Apache::eperl or Apache::embperl. What I find easiest to do is to write up the HTML with no code in it first (or ideally, have someone else do that for me), and then stick in variables, etc. later on. In order to keep the pages themselves clean looking, I find it a good idea to separate functions into a file or files that are then required, and have only variables and function calls within the HTML itself. It's very straightforward, and the whole thing basically becomes a template easily edittable by a non-coder.
[reply]
      There is actually a drawback with eperl and embperl. You're mixing design with content and adding code. IMHO one should aim at separating the design, content and code. Sometimes the code is used to generate design. Sometimes for content generation. Even for both.

      But on the other hand Perl can look scary for a non-coder. That in turn just scream "don't touch me!". That leaves the trouble makers with coding aspirations.

[reply]

Back to Seekers of Perl Wisdom