Neil said:
Hi Bob,
Bob Barrows said:
Neil Gould wrote: [...]
Perhaps my experience is being affected by what the defined
boundaries of a "page" vs. "script" vs. "application" might be.
For instance, on a "page" (mix of ASP and HTML code) that selects
files via a form and calls an ASP file that processes the form but
has no direct user interaction (is that also considered a page?), I
received an error that the response buffer can't be turned off once
it is turned on. Well, it was turned on by an file included on the
form processing file. So, that implies that the boundaries of the
ASP file (page?) are defined by the includes as well. OK, makes
sense.
But what about the form that called the routine?
It's a different page...
I.E. the requesting form is not part of the response.
Ah, but it *can* be part of the response,
No it can't. This is just silly.
What you're saying is analogous to saying that when a sub or function calls
another sub or function, the calling function becomes "part" of the called
sub or function. It is easy to demonstrate that this is not the case:
option explicit
sub caller()
dim callervar
callervar = 3
called 4
end sub
sub called(passed)
response.write callervar + passed
end sub
A request can contain data that is passed to the response, but that does not
make any actions the calling page performed "part of the response".
since a form's action can
refer to itself and process correctly.
No, it is not referring to itself. I don't see where you are getting that.
When a form performs a post or get action, it may include data from itself
to be included with the request, but that is a far cry from being "part of
the request". Think about it. Can server-side code access any of the
client-side (or even server-side) properties of the calling form that were
not passed in the Form or Querystring collection, or persisted to
Application or Session variables?
Does that make it "2 pages"
from an ASP perspective?
Absolutely. Again. From the web server's standpoint, a "page" is defined by:
Everything that occurs from when a response starts until a response ends.
The response starts when the page is requested from the server (even when
the request is being made by the html form that was generated by a previous
request for the same page), and it ends when all the html, hard-coded or
generated, has been sent to the client (or it encounters an explicit
Response.End statement in the code).
That property is in effect until the response ends. Period. See for
yourself:
<%@ Language=VBScript %>
<%
if currbuff = Response.Buffer
Response.Buffer = Not currbuff
Response.Write "Buffer initially set to " & currbuff
Response.Write "<BR>"
Response.Write "Buffer now set to " & Response.Buffer & "<BR>"
%>
<html><body><form method=post>
What's puzzling me is the concept of a "page" where there are no
contents other than routines. The closest I can come is to consider a
"page" to be the 'P' in 'ASP'. ;-)
An ASP page generates html to be sent to a client via the Response object.
If your file contains nothing but routines that do not write data to
Response, then this file is probably an include file that is becoming part
of the ASP page that IS writing data to Response.
Think about it this way: when you include a file in an ASP page, you are in
essence creating a new file in memory that contains the contents of both the
included file and the called file: a single page.
I agree with your conclusion, which implies that Server.ScriptTimeout
(and what other Server methods???) is not persistent. Thanks!
Huh? Methods perform actions. They don't persist unless the action they
perform causes something to be persisted.