SPUG: clever(?) new way to code CGI...

Mon Oct 23 18:50:51 CDT 2000

As I was drifting off to sleep the other night, I got this brilliant 
idea.  At least, I *think* it's a brilliant idea, but maybe it's one 
of those ideas that seem brilliant in theory, but end up being not so 
great when put into practice.  So, I decided I'd share my idea here: 
to see if anyone had ever tried something similar, and if so, to hear 
what their experience was, and just to solicit general comments and 
wisdom from the group...

BACKGROUND:
One thing that's always seemed inelegant to me when coding CGI is the 
awkward mesh between the client-side code (HTML, plus maybe some 
JavaScript, VBScript, Java, etc.) and the server-side code (for those 
of us here on SPUG, this is presumably Perl, or a combination of Perl 
and something else).

It's extremely difficult (or at least tedious) to embed sophisticated 
HTML layout directly into one's CGI code: it generally requires a lot 
of cutting and pasting between your WYSIWYG-ish HTML editor of choice 
and your source-code editor.

The usual solution (for me, at least) has been to create separate 
HTML files -- using my favorite HTML editor -- which my CGI scripts 
then serve, usually modifying the HTML (i.e. adding dynamic content) 
in the process.  This is still somewhat awkward, because it requires 
having at least two separate files, which are in different formats 
(HTML and Perl), are usually developed in two different application 
environments (HTML editor and source-code editor), and yet are 
*logically* intimately connected: the Perl code generally needs to 
"know" a great deal about the structure of the HTML document (e.g. 
the names of the form elements, perhaps their default values, and the 
possible values of radio, checkbox, and select elements, and where in 
the HTML code to insert dynamically-generated content).  In short: 
it's awkward having the HTML code in one file, but all of the logic 
for manipulating and using that code in a separate file.

Wouldn't it be cool if there were some sort of graphic, WYSIWIG-ish 
development environment for Perl CGI apps, so that both the Perl and 
the HTML code could be manipulated conveniently from within the same 
file?  Or, to put it another way: wouldn't it be nice to embed HTML 
directly into your CGI scripts, yet still be able to edit that HTML 
directly, using a full-featured HTML editor?

And now here's my brilliant idea:  why not write Perl scripts which 
are *also* valid (or very nearly valid) HTML files?  Example:

----------------foo.cgi--------------------------
#!/usr/bin/perl
my $html_start=q|
<html>

... insert any amount of HTML here, just so long as it doesn't 
contain any pipe characters (and if it needs to include a |, just 
find a different char to use with the q quoting, or invent some sort 
of escape code like '__PIPE__' and do a s/__PIPE__/|/g on the string 
later on) ...

<!--
|;

...insert any amount of Perl code here, just as long as it never contains
the string '-->'...

__END__

--> ...insert any amount of HTML code here, which can be read by the 
Perl code above via the DATA handle...
</html>
---------------------EOF---------------------------

Other than the first two lines, this is a perfectly valid HTML file. 
Most HTML editors could handle this file no problem: they might 
complain slightly about those first two lines, but most are 
configurable so that they will leave those two lines alone.  Even if 
you use a more Draconian HTML editor that insists on removing those 
first two lines, it would be easy enough to add them later in a text 
editor, or perhaps have a script that automatically adds those line 
when the files are uploaded to the server.

There are dozens of useful variations on this idea:  if one wants to 
have a chunk of WYSIWIG-editable HTML in the middle of one's Perl 
script, all one needs to write is some construct such as:

... q| -->

... this HTML will be visible and editable by your HTML editor....

<!-- | ...

If you want to access the html at the end of the file, but don't want 
to use the DATA handle, you can use the here-docs syntax instead:

... my $last_little_bit= <<'</html>';
...HTML code...
</html>
---------------------EOF---------------------------

Another variation is to put the HTML into a separate file, but then 
*also* embed the logic for serving that HTML in that file, like this:

----------------foo.cgi-------------------------
#/usr/bin/perl

...
open( HTML_FILE, 'bar.html' ) or die $!;
undef $/;
$_ = <HTML_FILE>;
eval "\$html_start=q|$_";
...
---------------EOF----------------------

----------------bar.html--------------------------
<html>
... any amount of HTML code not containing a '|' character ...
<!-- |;

... any amount of Perl code that doesn't include the string '-->' ...

$last_little_bit=<<'</html>';
  -->
... more HTML code ...
</html>
---------------EOF----------------------

Now bar.html is a perfectly valid HTML file, which you can preview in 
any browser and should be editable in any HTML editor -- and it is 
*also*, in effect, a loadable Perl module (as long as you remember to 
use eval and to stick that little '$html_start=q|' in the front). 
One could combine this technique with AUTOLOAD and make all the 
"html" files in a certain directory accessible as simple function 
calls.  And of course, since the whole point of these techniques is 
encapsulation, the obvious next step is to make these files behave 
like objects, with a full OO interface...

As you can see, the examples I've given above are *extremely* 
skeletal, but I hope I've communicated the gist of where I'm going 
with this.  Has anyone tried a system like this for doing CGI 
programming?  Any thoughts, reactions, criticisms?  Does anyone else 
find this idea as exciting as I do?  Or is this really specific to my 
own idiosyncratic coding style, and utterly useless to everyone else?

-jason

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
  Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/