SPUG: Re: clever(?) new way to code CGI...
Jason Lamport
jason at strangelight.com
Tue Oct 24 01:02:10 CDT 2000
I find these responses very interesting, though slightly puzzling.
I've looked at these modules, and *to me* they all seem to suffer
from precisely the awkwardness that my idea is meant to avoid. In
some ways, they seem to me to make the situation even worse: it's bad
enough that I've got to mesh HTML and Perl -- the last thing I want
to do is to then add some module with its own idiosyncratic API,
effectively requiring me to throw YET ANOTHER mini language into the
mix.
I have certainly done my share of wheel-reinventing: I long ago coded
modules that do most of what HTML::Template and Text::Template do,
and probably a few things that even HTML::Mason doesn't do (though I
confess, I haven't read those docs in their entirety). The
*functionality* is not what I find so interesting about my
suggestion. I found my idea so exciting because it seems to me like
a simpler and far more flexible way of doing these things, and many
fancier things as well, and one that allows me *easily* to design my
own API's, rather than being forced to use someone else's.
It seemed to me that in this case, I had found a way around my usual
CPAN dilemma: use a CPAN module which does *almost* what I want, or
put in some extra time and effort "reinventing the wheel" to create
my own module which does *exactly* what I want. In this case, it
seems to me that I've discovered a system with which I can
effectively create modules that do exactly what I want, and do so
with less effort than it would take me to download a CPAN module and
learn its API.
Judging from these responses, however, I suspect that this is
completely relative to my own programming style, and apparently not
as much use to others on the list as I had hoped. And again, this is
all still just theoretical: I haven't actually coded any sites using
these techniques yet. I'll try it out, and if it works as well as I
hope, maybe I'll come back with something of more general interest to
share...
-jason
At 8:03 PM -0700 10/23/00, Richard Anderson wrote:
>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/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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
mailing list