Philip Mak wrote:
> 
> I see. There are two problems that I have with file includes though:
> 
> (1) I cannot specify a file's location relative to $ENV{'DOCUMENT_ROOT'}.
> 
> (2) I cannot specify a file's location relative to the directory the
> current file is in.
> 
> For #1, I want to do something like this in all my pages:
> 
> <!--#include virtual="/code/header.asp"-->
> <!--#include virtual="/code/footer.asp"-->
> 

For #1, know includes will be picked up from your Global directory,
so you can use that repository to share includes, instead of some
DOCUMENT_ROOT location.  You can also use IncludesDir for this if
it is set.

> And for #2, I have an "index.inc" in all my directories. Each index.inc
> has to include the one in its parent directory, e.g.:
> 
> <!--#include file="../index.inc"-->
> 
> so that directories can pass on properties to their subdirectories. If I
> use include file for that, it will include files relative to the pathname
> of the first ASP file, and not relative to the pathname of the ASP file
> that actually has the include.
> 
> ...
> http://www.girlsofanime.com/series/slayers/lina/ has title of
> Girls of Anime::Anime Series::The Slayers::Lina Inverse
> 
> The way the title is constructed is:
> 
> In /index.inc: $title = 'Girls of Anime';
> /series/index.inc: $title .= '::Anime Series';
> /series/slayers/index.inc: $title .= '::The Slayers';
> /series/slayers/lina/index.inc: $title .= '::Lina Inverse';
> 

I would not do it this way, in fact the way I would do this
would not be with your methods at all, unless you want 
to have each section to be arbitrarily different and 
maintained by separate graphics designers.  The way I would
do this thing is to lose the directory structure completely
and to have things be database driven with parameters from
?query_string like /index.asp?dir=1111, which you can build
the title for from the database because you know all the 
parents for dir=1111.

The point here is that each ASP script is a whole program
by itself, and I would not recommend having hundreds or
thousands of them to have to compile for your site.  If you
have meta data you want to display, you should really stick
as much of it as possible in a database like MySQL.  In
the long run, your project will be much more maintainable
even if in the short run its easier to derive info from
unix directories & flat files.

If you want to have a nicer /path_info scheme, we'll 
probably have to add a patch for you to have Apache::ASP
not be bound to executing real files as it is currently.
This would be more similar to the way Mason does things.

--Joshua

Reply via email to