SPUG: Re: clever(?) new way to code CGI...
starfire at zipcon.net
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)
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)
----- 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...
> 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
> 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:
> my $html_start=q|
> ... 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 '-->'...
> --> ...insert any amount of HTML code here, which can be read by the
> Perl code above via the DATA handle...
> 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...
> 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:
> open( HTML_FILE, 'bar.html' ) or die $!;
> undef $/;
> $_ = <HTML_FILE>;
> eval "\$html_start=q|$_";
> ... any amount of HTML code not containing a '|' character ...
> <!-- |;
> ... any amount of Perl code that doesn't include the string '-->' ...
> ... more HTML code ...
> 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?
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 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/
More information about the spug-list