SPUG: Re: clever(?) new way to code CGI...
Richard Anderson
starfire at zipcon.net
Tue Oct 24 08:42:08 CDT 2000
It's a matter of making the most effective use of your time. Any module
that offers complex functionality is necessarily going to have a complex
API. I do agree that most CPAN modules have inadequate documentation, but
since they always come with source code I can usually figure them out in
much less time than it takes to reproduce the code "my way".
I found the interface for HTML::Template to be very simple, and I learned it
in less than an hour.
The other benefit of using CPAN modules is that the more popular ones are
often upgraded and maintained over the years. It's like free candy.
If you feel a module is inadequate but useful, you can modify it to work the
way you want, then send the new code to the author for incorporation. If
the author doesn't like your mods, you can release your version as a new
CPAN module.
CPAN is one of the things that makes Perl great, and I feel it is in my
self-interest to support it.
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>; "Jason Lamport" <jason at strangelight.com>
Sent: Monday, October 23, 2000 11:02 PM
Subject: Re: SPUG: Re: clever(?) new way to code CGI...
> 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/
>
>
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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