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

[Michael Friedman]

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  
internal software:

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  
text.

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  
strategy.

YMMV, but this approach has worked very well for us for the last 6  
years.

Good luck!
-- Mike

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:

> Greetings,
>
> 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  
> firefox)
>   * 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
> subject.
>
> Thanks,
> David
>
> 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
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm

---------------------------------------------------------------------
Michael Friedman                     HighWire Press
Phone: 650-725-1974                  Stanford University
FAX:   270-721-8034                  <friedman at highwire.stanford.edu>
---------------------------------------------------------------------