Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re: How do you organize your Perl applications?

by Ovid (Cardinal)
on Apr 04, 2003 at 22:13 UTC ( #248200=note: print w/replies, xml ) Need Help??

in reply to How do you organize your Perl applications?

Here's roughly how we would do it at my work (assumes that this is under some site specific directory):

|   myprogram.ini
|   mytemplate.html

The main consideration is to ensure that nothing goes under the www/ folder unless you really need direct Web access to it. Otherwise, one slip in your configuration could give away information that you may not want others to see.


New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

  • Comment on Re: How do you organize your Perl applications?

Replies are listed 'Best First'.
Re[2]: How do you organize your Perl applications?
by PotPieMan (Hermit) on Apr 05, 2003 at 02:43 UTC
    I agree with your directory structure, but I would like to make one further recommendation: Instead of a data directory for configuration files, use the standard UNIX etc directory. This allows you to use data for actual data, such as comma-separated value files that a client sends you.

    From the data directory, I generally move to a ddl directory for database definition files and a sql directory for SQL scripts.


      Forgive me if this sounds pedantic, but how do you distinguish between DDL and SQL scripts? I only ask because I use a single directory (sql, although I like ddl as well) for this. Aren't they the same thing?

      I also wonder if you have a sibling dml directory which has the definitions for a SQL phrasebook. To be honest, that idea only just occurred to me, but it does seems attractive. Something like:

      +--sql +--dml # database setup scripts and definitions here. +--ddl # data files with phrasebook definitions here.
        My team uses the ddl directory for schema definitions: tables, constraints, triggers, etc. The sql directory is used as storage for what might be called a phrasebook, though we haven't formally come to that concept yet. Definitely something to consider. :-)


      I disagree with that recommendation.

      There are many cases where you want to allow multiple configurations to co-exist on the same machine. For instance multiple developers on one machine, each with their own home directory. Or staging and production versions of the same site on the same machine, served from different IP addresses.

      Of course if this is for broader distribution and not just for internal use, then be nice to administrators and put configuration files where the sysadmin will expect it - namely /etc. But for internal use...?

        I'm sorry if I wasn't clear before. When I said "standard UNIX etc directory", I meant the following:

        Inside your project directory (whether in your home directory, in CVS, or in some other version control system), create an etc directory for storing configuration files.

        I definitely do not recommend putting everything in /etc. Sorry for the confusion.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://248200]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2017-04-28 11:04 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (521 votes). Check out past polls.