On Sat, 20 May 2000, Joshua Chamas wrote:
> > <!--#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.
Thanks! That pretty much lets me do exactly what I want to.
> > 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.
There are two reasons why I don't like doing it this way:
(1) The URL is no longer human readable. My site will have a clear
hierarchical structure, so I think it makes sense to mirror that in the
directories. People who want to chop or type URLs (even though I have good
navigation in my web design) can do so, and they can also look at the URL
to get an idea of where they are.
(2) Setting up a database seems to be overkill for this site. The only
meta data that it has (or probably will ever have) is:
- directory name label
- What links are on the sidebar for this directory?
- What advertising banner(s) is displayed on pages in this directory?
My method of having an index.inc for each directory is fairly simple, yet
it would seem to provide all the flexibility I need to implement this and
the flatfiles are easy to maintain. I don't see a good reason to switch to
database-based which seems to be significantly more complicated.
> 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.
Each ASP script is compiled separately? I thought that <!--#include
file--> and <!--#include virtual--> are supposed to work just like
#include does in C, i.e. it pretends that the text of the included file
was actually pasted directly into the program. Am I thinking about ASP
include in the wrong way?
> 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.
Well, I would like to suggest that you consider including <!--#include
virtual--> in the Apache::ASP distribution, so that included files use the
same namespace. It doesn't make sense logically that include virtual
behaves differently from include file (other than the way the
filename/pathname is interpreted, of course).
-Philip Mak ([EMAIL PROTECTED])
