in reply to Development Directory Structure and Technique

I like both Coreolyn and Fastolfe's suggestions. With one comment on the apache_root/projectname/lib approach.

In the case of a CGI project, I would keep any project modules in a directory outside the apache_root structure ( as well as any conf directories) as a misconfiguration by the webmaster can expose those to the web, you won't want to have someone inadvertently get an index view of your libs/conf directory where you may have stashed some important database connection information.

  • Comment on Re: Development Directory Structure and Technique

Replies are listed 'Best First'.
($code or die) Re: Development Directory Structure and Technique
by $code or die (Deacon) on Jan 03, 2001 at 22:33 UTC
    I second that - it is a security risk.

    I do like both Coreolyn & Fastolfe's ideas. I am trying to organize my projects better these days but so far I keep changing my mind each time I start a new one. At least it's better than when I used to dump EVERYTHING in one folder.

    My current directory plan is a bit like this:
    /work/project-a/database - store databases in here /work/project-a/libs - modules, libraries /work/project-a/temp /work/project-a/backups - archives of previous working versions /work/project-a/webroot - Web folder starts here /work/project-a/utils - command line utils I may need /work/snippets - useful code snippets to save and reuse.
    I like Fastolfe's use of a docs folder. I really, really, really should do that. Problem is, I work in a company where I'm the only guy who can 'use Perl;' - everyone else uses VB\VBScript. Maybe that's a reason TO document more?

    Update: To answer ichimunki's second question, (if I understand it correctly), so long as you don't rely on anything above your project root and use relative links, then you should be able to zip up the project folder when you are ready to move from development to production, or whatever.