Best practices? Organizing CGI code and modules?

Discussion in 'Perl Misc' started by robb@acm.org, Sep 20, 2006.

  1. Guest

    Hi,

    I've taken over management of a website that has absolute chaos in the
    organization of the CGI directory (/cgi-bin). There are ~600 files and
    directories here, no user-built modules, and perl files
    indiscriminately named .pl, .cgi, etc.

    Instituting revision control has been a big help. :)

    But specifically to perl, is there a consensus about where to put which
    files, and how they should be named? I personally like to develop with
    packages and modules, and this is a new thing in this environment. I
    so far have these kinds of files that I'm developing:

    Test Scripts
    Application-Specific Modules
    Application-Independent Modules
    Application CGI scripts, referenced directly from a web client

    Currently, here's what I'm doing, but I don't believe this is optimal:

    /cgi-bin
    App. CGI scripts, named *.cgi.
    App-independent modules named *.pm

    /cgi-bin/CamelCaseAppName
    App-specific modules, named *.pm
    App-specific test scripts, named *.pm

    I'm definitely interested in removing things from cgi-bin that don't
    need to be there. And, I want to increase maintainability. I also
    want to enable automated running of all my tests.

    Thanks for any input,
    Robb
     
    , Sep 20, 2006
    #1
    1. Advertising

  2. Uri Guttman Guest

    >>>>> "ro" == robb@acm org <> writes:

    ro> Test Scripts

    those are executables so should be in some bin/ dir. they don't need to
    be in any cgi areas (unless they are cgi driven). in fact i wouldn't put
    any development source in the actual cgi dirs. copy tested scripts into
    cgi dirs using an install process.

    ro> Application CGI scripts, referenced directly from a web client

    in many cases those can be reduced to minimal or even reused scripts
    that call out to modules that do all the work. this is a very good way
    to do this because the modules will have a clean perl API which can be
    called from standalone test scripts. the cgi scripts become trival
    wrappers which grab the cgi params (using CGI.pm or mod_perl), mung the
    data into the form the modules want (hash trees, etc.) and call out
    to the proper modules. the results are processed into html output
    (possibly using a templater) and that can be also done in external
    modules. then the cgi is even simpler and it can almost be made into a
    common script that can do many operations based on its name (check $0 as
    a primary dispatch arg) or a command type param.

    with these modules you can develop them anywhere you want. use lib can
    help you find and load them from the proper installed dirs (or you can
    install them in perl's default lib dirs). you can put the test script
    development near the modules that they test which is good too.

    ro> I'm definitely interested in removing things from cgi-bin that don't
    ro> need to be there. And, I want to increase maintainability. I also
    ro> want to enable automated running of all my tests.

    what needs to be in cgi-bin is a minimal set of cgi scripts which just
    call out to modules that do the real work. this makes your cgi very
    clean and easy to manage. consider cgi as just an interface to your
    modules and design your code accordingly. interfaces should be isolated
    from back end work so you can more easily have multiple interfaces
    (think cgi and test scripts as using two different interfaces).

    uri

    --
    Uri Guttman ------ -------- http://www.stemsystems.com
    --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
    Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
     
    Uri Guttman, Sep 20, 2006
    #2
    1. Advertising

  3. Ted Zlatanov Guest

    On 20 Sep 2006, wrote:

    > Currently, here's what I'm doing, but I don't believe this is optimal:
    >
    > /cgi-bin
    > App. CGI scripts, named *.cgi.
    > App-independent modules named *.pm
    >
    > /cgi-bin/CamelCaseAppName
    > App-specific modules, named *.pm
    > App-specific test scripts, named *.pm


    I like to "use lib '/usr/local/PROJECT'" for things in cgi-bin, then
    put all modules, templates, etc. under /usr/local/PROJECT.
    '/usr/local' is a matter of preference, but it really helps to base
    the code somewhere outside of the webserver's grubby indexing hands.

    Ted
     
    Ted Zlatanov, Sep 20, 2006
    #3
  4. John Bokma Guest

    "" <> wrote:

    > Hi,
    >
    > I've taken over management of a website that has absolute chaos in the
    > organization of the CGI directory (/cgi-bin). There are ~600 files and
    > directories here, no user-built modules, and perl files
    > indiscriminately named .pl, .cgi, etc.
    >
    > Instituting revision control has been a big help. :)
    >
    > But specifically to perl, is there a consensus about where to put which
    > files,


    First, regarding the cgi-bin directory, this should be *outside* your
    document root (see: http://johnbokma.com/windows/apache-virtual-hosts-
    xp.html)

    Next all files that are not cgi scripts *shouldn't* be in this directory.
    One configuration mistake, and they are available on the Internet.

    > and how they should be named? I personally like to develop with
    > packages and modules, and this is a new thing in this environment. I
    > so far have these kinds of files that I'm developing:
    >
    > Test Scripts


    Shouldn't be online.

    > Application-Specific Modules
    > Application-Independent Modules
    > Application CGI scripts, referenced directly from a web client


    only ones that should be inside cgi-bin online.

    > Currently, here's what I'm doing, but I don't believe this is optimal:
    >
    > /cgi-bin
    > App. CGI scripts, named *.cgi.
    > App-independent modules named *.pm


    Would put the latter in a directory that is outside document root *and*
    outside cgi-bin. Readable by your scripts.

    > /cgi-bin/CamelCaseAppName
    > App-specific modules, named *.pm


    See above

    > App-specific test scripts, named *.pm


    pm stands for Perl module.

    --
    John Experienced Perl programmer: http://castleamber.com/

    Perl help, tutorials, and examples: http://johnbokma.com/perl/
     
    John Bokma, Sep 20, 2006
    #4
  5. Guest

    Thanks for the replies, everyone. Lots of good advice here.
     
    , Sep 22, 2006
    #5
  6. On 2006-09-20 18:07, <> wrote:
    > I've taken over management of a website that has absolute chaos in the
    > organization of the CGI directory (/cgi-bin). There are ~600 files and
    > directories here, no user-built modules, and perl files
    > indiscriminately named .pl, .cgi, etc.


    This hasn't got anything to do with perl, but ...
    I always hated the cgi-bin directory, as it makes a rather irrelevant
    distinction between static and dynamic content. If I have two
    applications app1 (which consists of foo.cgi, bar.html and baz.jpg) and
    app2 (which consists of waldo.cgi, fubar.html and fred.png) I find it a
    lot clearer to organize them as

    /
    app1/
    foo.cgi
    bar.html
    baz.jpg
    app2/
    waldo.cgi
    fubar.html
    fred.png

    than

    /
    docs/
    bar.html
    fubar.html
    cgi-bin/
    foo.cgi
    waldo.cgi
    images/
    baz.jpg
    fred.png

    If you use MultiViews with Apache, you can even hide the distinction
    completely by omitting the extension in the URL: So if the user accesses
    /app1/foo, /app1/foo.cgi will be invoked, and if he accesses /app1/bar,
    /app1/bar.html will be invoked. If I later decide that bar needs to
    generated dynamically, I can simply add a /app1/bar.cgi and remove the
    /app1/bar.html. The user will still access the same URL, but now a CGI
    script will be invoked.

    As for the organisation of the code, I agree with Uri: Put as much as
    possible into modules which can be installed anywhere where perl can
    find them and make the CGI scripts only thin wrappers.

    hp

    --
    _ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
    |_|_) | Sysadmin WSR | > ist?
    | | | | Was sonst wäre der Sinn des Erfindens?
    __/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd
     
    Peter J. Holzer, Sep 22, 2006
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ing. Davide Piras

    AS.PNET 2.0, runtime modules Best Practices

    Ing. Davide Piras, Jan 30, 2007, in forum: ASP .Net
    Replies:
    2
    Views:
    352
    Ing. Davide Piras
    Jan 30, 2007
  2. Eric S. Johansson

    organizing collections of small modules

    Eric S. Johansson, Mar 25, 2007, in forum: Python
    Replies:
    2
    Views:
    239
    Eric S. Johansson
    Mar 26, 2007
  3. bukzor

    Guide to organizing modules?

    bukzor, Jun 6, 2008, in forum: Python
    Replies:
    2
    Views:
    288
    bukzor
    Jun 6, 2008
  4. Replies:
    4
    Views:
    113
    Robert Klemme
    Jul 30, 2007
  5. rambius
    Replies:
    2
    Views:
    194
    Demian Brecht
    Oct 27, 2012
Loading...

Share This Page