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

[Greger]

On Fri, 19 Jan 2007 09:05:44 -0800, Michael Friedman wrote
> 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>
> ---------------------------------------------------------------------
> 
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm

very good advice. 
--
http://www.gregerhaga.net/
http://hack-space.biz/