RE: [WEB400] The proper way to set up your directory stucture for webserving

["Jones, John (US)" <John.Jones@xxxxxxxxxx>]

I would do the first.  That way, any given app can refer to all of it's
parts via indirect links: ../images/header.jpg and ../html/index.html.
Apps are also unaware of their root directory, i.e. live vs. test.
They're also unaware of your application's naming convention.

Using your second scheme, apps would have to be coded with the
environment and the app's directory name.  For index.html to load an
image, the img tag would be something like
/test/images/someappname/header.jpg (vs. my example above).  Granted,
this can probably be done via some sort of evaluated header, but why
bother when it's not necessary?

Personally, I figure having HTML is the 'default' content of a directory
so I use:
/www/app <-- html files
/www/app/i <-- images
/www/app/macro <-- net.data
etc.

So for me, an html file uses i/header.jpg.  /i/header.jpg also works as
my web server instance has /www/app as it's root.

Finally, my way lets you easily split the apps amongs various server
instances, migrate from server to server, or back up/restore separately
as entire apps are bundled together.

John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787  F: +1-312-601-1782
john.jones@xxxxxxxxxx

-----Original Message-----
From: rick baird [mailto:rick.baird@xxxxxxxxx] 
Sent: Tuesday, January 18, 2005 3:22 PM
To: web400@xxxxxxxxxxxx
Subject: [WEB400] The proper way to set up your directory stucture for
webserving

I'm having a brain seizure, and i'm looking for some direction on the
'BEST' way of organizing web document directories.

I'm on V5R3, using apache for static pages and some homespun CGI (the
hard way) programs.

I want to begin using net.data and CGIDEV as well, and I'm having
difficulty deciding the proper way to set up my directory structure, but
before I do, I want to make sure I don't paint myself into a corner by
doing it wrong.

How do you all organize your directories?     by document type and
then application?  or by application and document type.  What about
images, static pages or net.data macros that could be used in several
different applications?

Mostly, I'm concerned about my html (static and generated) will be able
to easily 'find' my images, other pages, other links, etc.
without having to specify full path's to those objects, and to easily
navigate between static pages, cgi and net.data links.

for instance, can you think of anything functionally different between
the following:

/live/common/html/...
/live/common/images/...
/live/common/netdatamacros/...
/live/application1/html/...
/live/application1/images/...
/live/application1/netdatamacros/...
/live/application2/html/...
/live/application2/images/...
/live/application2/netdatamacros/...
/test/application1/html/...
/test/application1/images/...
/test/application1/netdatamacros/...
/test/application2/html/...
/test/application2/images/...
/test/application2/netdatamacros/...

and this:?

/live/html/common/...
/live/html/application1/...
/live/html/application2/...
/live/netdatamacros/common/...
/live/netdatamacros/application1/...
/live/netdatamacros/application2/...

etc.

or some other way of organizing?

thanks in advance,

Rick



This email is for the use of the intended recipient(s) only.  If you have 
received this email in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this email without the author's prior permission.  
We have taken precautions to minimize the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any attachment 
to this message.  We cannot accept liability for any loss or damage caused by 
software viruses.  The information contained in this communication may be 
confidential and may be subject to the attorney-client privilege. If you are 
the intended recipient and you do not wish to receive similar electronic 
messages from us in future then please respond to the sender to this effect.