[sf-perl] Browser front ends to perl back ends
friedman at highwire.stanford.edu
Fri Jan 19 09:05:44 PST 2007
I work in a similar environment -- the software developers like
command-line tools, but the production staff (the ones who bring in
the revenue!) are not so facile in Unix, so they need web-based
tools. We've decided to use a 3-part model for developing our
1. Perl modules that do all the "real work". So, for a database
update operation, we write a (or several) modules that take user
input, do the updates, and produce text output.
2. Perl scripts that run on the command-line that wrap the modules.
These scripts are *very* short and lightweight. They handle reading
the parameters (Getopt::*), passing them to the modules, and doing
minor reformatting of the output text.
3. Perl CGI scripts that run on the web server that wrap the modules.
These are also very short and lightweight. They usually have two
"modes": when called with no parameters (or only a couple of
background ones) they return a form for the user to fill out; when
you submit the form it goes back to the same CGI which then passes
the parameters to the modules and does HTML formatting of the output
By making modules for the text->HTML transformations, so that code is
shared, and being pretty standard with the implementation, the CGI
scripts are not any longer than the command-line scripts.
In this model, you only write code to do the actual work once, in a
module. Then you put two pretty much boilerplate front-ends on it for
people to use.
We had originally looked at using the command-line "fake out" that
CGI.pm offers, so we'd just write the CGI script and let command-line
users use it, but we decided that getting HTML text as output on the
command-line was... sub-optimal. ;-) So we changed to the two-wrapper
YMMV, but this approach has worked very well for us for the last 6
PS - If you are doing automated testing, you only need to test the
modules, since the scripts and CGIs don't do anything.
PPS - There are all sorts of tricks for writing modules faster and in
more standard ways. I recommend reading _Perl Best Practices_ and
implementing Damian's suggestions. If you do that, you'll have an
even easier time of the development than we did. (We had to build all
the infrastructure ourselves. Now you can just download it from
CPAN.) For example, the outputting of text to either command-line or
HTML would be very easy if you used a templating system.
On Jan 19, 2007, at 8:03 AM, David Alban wrote:
> I'm a command line person. I use things like X Windows and screen so
> that I can get more command lines. The tools I have written over the
> years are command line tools. My users have been command line people.
> 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). I plan to write command line perl tools.
> Command line perl tools that can be called from web front ends. That
> way the same set of tools can be used both by command line folks and
> by gui-only folks.
> I have no experience in developing browser-used thingamabobs. I've
> written html, sure, but only for basic web pages. No moving parts
> (well, O.K., one animated gif :-).
> My requirements for a front end are simple:
> * it has to be something which can run from a browser (say, IE or
> * it has to be able to call command line perl programs
> Nice-to-haves would be:
> * doesn't take too long to learn (my current plans don't include
> becoming a web developer). the front end is for internal use only, it
> doesn't have to have bells, whistles or sex appeal, it just needs to
> work well
> * should be as platform-independent as possible
> Is CGI the way to go for this? Is PHP? Is <something else
> altogether>? I realize that asking this on a perl list is bound to
> tip the scale in favor of CGI, but I wanted to ask anyway, figuring a
> significant number of folks might be able to give good advice on the
> P.S. I'm not considering perl/tk because I want the tools to be
> operable from any web browser on the local network. Plus, most of the
> windows users won't have an X server running.
> Live in a world of your own, but always welcome visitors.
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
Michael Friedman HighWire Press
Phone: 650-725-1974 Stanford University
FAX: 270-721-8034 <friedman at highwire.stanford.edu>
More information about the SanFrancisco-pm