[sf-perl] Browser front ends to perl back ends
boss at gregerhaga.net
Fri Jan 19 09:11:06 PST 2007
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
> 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
very good advice.
More information about the SanFrancisco-pm