So, there's no way in Apache::ASP to include a file by specifying a path
relative to DOCUMENT_ROOT, or relative to the directory of the current
file (which is not necessarily equivalent to the request URI, if the
current file is included)?
I managed to get my site to work using <!--#include file--> and specifying
full pathnames and using PerlSetVar IncludesDir, but it would have been
nice if there was a way to include a file with relative path
specifications as in the above paragraph (and still be in the same
namespace). I first learned ASP on IIS, and there, <!--#include virtual-->
(which allows the relative path specifications) can be used for this
purpose.
-Philip Mak ([EMAIL PROTECTED])
On Sat, 20 May 2000, Joshua Chamas wrote:
> Ime Smits wrote:
> >
> > | 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).
> >
> > It does make sense to me, though. Consider one having very big (say 50k)
> > include files being included from several other (say 100) scripts. Just
> > sucking them in each script doing the include would cause *every* script
> > growing by at least the size of the include. Now as Apache::ASP caches all
> > compiled scripts, this would result in each httpd process growing by 50kB x
> > 100 scripts = 5 MB, holding 98% redundant data.
> >
>
> If DynamicIncludes are turned on, then file includes are
> compiled as subroutines, and executed as if $Response->Include()
> were called. Without this setting, includes text are added
> to the including scripts like you are saying.
>
> But this does not solve the virtual includes problem. A virtual
> include is supposed to be anything executed on the server,
> not just files, but the output from anything like some C cgi,
> or another .pl or so, and must therefore be processed as a
> separate subrequest. This is what Apache::SSI does.
>
> The problem here is that there is no way for the Apache::ASP
> script to catch the output from the apache subrequest to
> even try to compile it into its own script, even if you really
> wanted to do this. So this is why this is stays a separate
> feature to be handled by Apache::SSI, that it doesn't help
> at all to inline it into Apache::ASP, except some small
> performance benefit by not running the output through
> Apache::Filter
>
> -- Joshua
> _________________________________________________________________
> Joshua Chamas Chamas Enterprises Inc.
> NodeWorks >> free web link monitoring Huntington Beach, CA USA
> http://www.nodeworks.com 1-714-625-4051
>
