Defining file paths with ASP

[Paul]

I am using several INCLUDE FILE statements on a page
(which I'll call Default.asp for this example), but since
the pages I am including and the graphics in them are in
different directories, it is not working. One of the
INCLUDE FILE lines from Default.asp is shown here:

<!--- #INCLUDE FILE = ads/b_spon_160x300-2.htm --->

The page and any text in it are displayed where I want on
Default.asp, but the graphics defined in the included
page "ads/b_spon_160x300-2.htm" will not appear. I
believe the problem is due to the need for different
paths to the graphics from Default.asp vs. from the
Include Page. Is there an ASP command to tell
Default.asp to temporarily change the default path for
the page before the <!--- #INCLUDE FILE =
ads/b_spon_160x300-2.htm ---> command, and then to set it
back to normal after that line? Or is there another way
to do this short of moving all the files into the same
directory?

 

[Thomas A. Rowe]

You have define the path to the images based on the page the include page
will be included in, not the include page.

One thing that I do, is create a path configuration file that is included in
all my .asp pages, where I define the URL path, since my local setup is
slightly different from the publish web.

Example (pathconfig.asp):

<%
Dim SitePath

SitePath = "http://www.livesiteURL.com/"
'SitePath = "http://client/localsiteURL/"

%>

Then in my include pages, I specific hyperlinks and image links as:

<img src="<%=SitePath%>images/imagefilename.gif">
--

==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
WEBMASTER Resources(tm)

FrontPage Resources, Forums, WebCircle,
MS KB Quick Links, etc.
==============================================

 

[Thomas A. Rowe]

Paul, see below for my replies to you 2 questions.

Also there is a option to use

<!--- #INCLUDE VIRTUAL ....

However, I don't use the above since I could never get it to work for me.
--

==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
WEBMASTER Resources(tm)

FrontPage Resources, Forums, WebCircle,
MS KB Quick Links, etc.
==============================================

Thanks for your reply and suggestion, Thomas. I have two
quesions: 1) Do I understand that your path configuration
file is its own asp file which is referenced in all other
pages through an Include statement?

Yes, this is a separate asp page that include in all pages, and the link is
adjusted based on the folder location within the web.


2) In your example,

it looks like you used two values for the same
variable "SitePath." I don't understand how this can work -
can you explain?

The first SitePath is the one that is active on the live site, with the
second one comment out using the ' . On my local copy it is reversed. This
comes in handle for me with working with sites that need to use https, which
I don't have locally, so I am still able to develop and test, before
publishing to the live server.


Thank you.

 

[Paul]

Thanks for the detailed answers, Thomas. This is very
helpful.

 

[MD WebsUnlimited.com]

Thomas,

You may wish to consider using the Application Path and making all links
relative to it. It negates the need to create and maintain a separate
pathing file.

 

[Thomas A. Rowe]

Mike,

Sound interesting, where would I set that up for classic ASP and can it
handle multiple path statements as well? Keep in mind that I am also working
with FP Include Page component as well as the ASP/SSI Include files.

I also store other info in the configuration file beside just path info,
such as fonts, font colors, link colors, cell background colors, etc.

--

==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
WEBMASTER Resources(tm)

FrontPage Resources, Forums, WebCircle,
MS KB Quick Links, etc.
==============================================

 

[Thomas A. Rowe]

Mike,

Not to get into a long discussion on this with you, but the ASP.dll has been
greatly improved under IIS 5 and up in how it parse files, so even with the
just using ASP to process the including of dynamic content, the impact on
the server should be the same as using SSinc.dll, just that the ASP.dll can
do a lot more besides just handling dynamic include content.

--

==============================================
Thomas A. Rowe (Microsoft MVP - FrontPage)
WEBMASTER Resources(tm)

FrontPage Resources, Forums, WebCircle,
MS KB Quick Links, etc.
==============================================

 

[MD WebsUnlimited.com]

We had this discussion before so I too do not wish to have a long discussion
about it An as you can see I continue to hold that using ASP to do nothing
more than include content is a misuse of ASP. If you're not processing
script then don't use an ASP extension. The ASP "include" is not a
replacement for SSI.

Obviously, asp.dll, must do extra work to see if the page contains script
code. I agree that the efficiency of the parser may have improved but it
still is an additional overhead not only in processor usage but in memory as
well. An if you take that overhead to 300+ web sites, on a shared web
server, the impact can be significant.

Note, unlike ssi.dll, asp.dll must also parse any included content files.
SSI would only stream the content, e.g. simple reads and writes.

There are other difference also. Permissions and objects come to mind. To
process an ASP page requires that the folder containing them have execute
script permissions. SSI does not require any such permissions so does not
incur the permissions check hit. ASP pages instantiate objects for the life
of the session (use memory). Every invocation of an ASP page creates at
least a response object, a request object and a server object. SSI has no
such object creation, memory usage.