[sf-perl] Browser front ends to perl back ends

Joe Brenner doom at kzsu.stanford.edu
Fri Jan 19 13:50:20 PST 2007


David Alban <extasia at extasia.org> wrote:

> Now I'm in a situation where half my users are command line oriented,
> and half don't use it at all, and are not likely to start.  

> I need to write tools that cause and/or foster building of java code
> and cause and/or foster the deployment of code and build artifacts
> from a source code repository to different environments (dev, qa,
> production equivalent, production).

Hm.  I'm wondering if something like that might exist already.  
I was thinking about the Mozilla tools (Bonsai, Tinderbox, etc).
But I'm not sure they give you quite what you want.

> I plan to write command line perl tools.
> Command line perl tools that can be called from web front ends.  

If you're in the habit of always putting script functionality in a
module, and just writing simple scripts that invoke the module, then 
you can write very efficient "mod_perl" code that just uses the 
modules directly.

But on the other hand, since this is just intranet stuff, you can 
probably get away with doing simple CGI stuff and shelling out to 
run your perl scripts (backticks, "system", etc).

Note: you want to watch your ass doing this, you're most like going to
have security holes out the wazoo if it's possible for an unauthorized 
person to get access to the intranet pages.

> I have no experience in developing browser-used thingamabobs.  

Look at Chapter 19 "CGI Programming" of the Perl Cookbook, and
see if it makes sense.

The docs for CGI.pm lead off with a decent example of a simple
program.

The Randal Schwartz book "Perls of Wisdom" has some okay CGI
examples, which also use CGI.pm.

(Note: CGI.pm arguably has bloat problems, but the latest
version at least has a lot of "tags" so you only need to load
the parts you care about).

>   * doesn't take too long to learn (my current plans don't include
> becoming a web developer).  

All software development projects evolve until they become web
development projects.

When you start doing stuff like this, get used to checking the
apache error log a lot, and realize that you can send debugging
messages to the log, e.g.

  use Data::Dumper; print STDERR Dumper($my_data_ref); 

And what "stateless protocol" means is that your scripts all
have a bad case of amnesia: if you want them to know something
about what was happening, you have to make sure you pass the
information to them somehow.  When you click "submit" the form 
values get passed to the script, but it won't know anything
from the time you clicked "submit" before that.

Embedding HTML generation code inside of perl, is shall we say, 
"considered harmful" (that's a big part of what that "model-view-
controller" jazz is about), but you have bigger problems at the
moment, so you might as well live with using the CGI.pm
shortcuts for now. (After you graduate to mod_perl, you should
look into Mason and/or Template Toolkit.)

> Is CGI the way to go for this?  

It's at least a way to go.  If you're working in perl already, it makes
sense to continue working with it, I would say. 



More information about the SanFrancisco-pm mailing list