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

Mon Oct 23 22:03:31 CDT 2000

Numerous people have addressed this issue.  A partial listing of the options
I know about:

HTML::Template (simple, but effective)
Text::Template (more powerful)
HTML::Mason (comprehensive)

No need to reinvent the wheel until you have worked with these modules and
have a clear reason why they don't serve your needs.

Richard.Anderson at rayCosoft.com    RayCosoft, Professional Services Group
Perl/SQL/Unix software engineering    www.rayCosoft.com (corporate)
www.zipcon.net/~starfire/home (personal)
----- Original Message -----
From: "Jason Lamport" <jason at strangelight.com>
To: <spug-list at pm.org>
Sent: Monday, October 23, 2000 4:50 PM
Subject: SPUG: clever(?) new way to code CGI...

> 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/
>
>
>

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     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/