General question about persistence

[Neil Gould]

Or... when is a script not a script?

I have several modules for managing different aspects of our club's website,
most of which are multi-page.

Does setting such things as server.ScriptTi meout or response.buffer values
at the start of the first page persist throughout the session, or are they
"reset" with each function or sub, etc.?

TIA.

--
Neil Gould
------------------------------
Terra Tu AV - www.terratu.com
Technical Graphics & Media

[Bob Barrows [MVP]]

Re: General question about persistence

Neil Gould wrote:

Or... when is a script not a script?
>
I have several modules for managing different aspects of our club's
website, most of which are multi-page.
>
Does setting such things as server.ScriptTi meout or response.buffer
values at the start of the first page persist throughout the session,
or are they "reset" with each function or sub, etc.?
>

Response.Buffer applies only to the page in which it is called. And it
is not something that is affected by functions or subs running on the
page.
I think the same applies to Server.ScriptTi meout ... the docs don't say
so explicitly, but it would be easy enough to whip up a couple pages,
the first of which sets the ScriptTimeout to some large number and the
second of which checks the setting.

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[Evertjan.]

Re: General question about persistence

Bob Barrows [MVP] wrote on 21 jul 2008 in
microsoft.publi c.inetserver.as p.general:

Response.Buffer applies only to the page in which it is called. And it
is not something that is affected by functions or subs running on the
page.
I think the same applies to Server.ScriptTi meout ... the docs don't say
so explicitly, but it would be easy enough to whip up a couple pages,
the first of which sets the ScriptTimeout to some large number and the
second of which checks the setting.

It seems to stand to logic that since:

Properties of the Response and Request objects are page wide,
properties of the Session object are session wide,
properties of the Application object are application wide,

properties of the Server object should be server wide,
so, [since ASP is the application at hand,
and not the physical server,]
in fact just application wide, too?

However I do not remember having caught MS
being completely logical in specs,
or even building exactly what their specs say,
so the test would be the taste of the pudding,
and reading the specs a mediocre second choice?

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Jon Paal [MSMD]]

Re: General question about persistence

response.buffer : Indicates whether the current page output is buffered.

server.ScriptTi meout : The ScriptTimeout property specifies the maximum amount of time any script in the application can run before
it is terminated.

[Neil Gould]

Re: General question about persistence

Thanks Jon Paal, Bob, and Evertjan,

"Jon Paal [MSMD]" <Jon nospam Paal @ everywhere dot comwrote in message
news:MP2dneGd4b YRKxnVnZ2dnUVZ_ jednZ2d@posted. palinacquisitio n...

response.buffer : Indicates whether the current page output is buffered.
>
server.ScriptTi meout : The ScriptTimeout property specifies the maximum

amount

of time any script in the application can run before it is terminated.
>

Perhaps my experience is being affected by what the defined boundaries of a
"page" vs. "script" vs. "applicatio n" 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? If I had set the
response.buffer off on that page, then what (not that it would make sense to
turn it off knowing that it would be turned on again, but this question is
about boundaries rather than proper coding)?

From your comment Jon, if I set the timeout on (or before) the initial page,
will it persist for all later routines and pages? If so, it would make sense
to set the value during the login procedure rather than for each of the
tasks that might be called later, but I don't know if I can trust that some
down-stream action won't time out because of being considered outside the
boundary of one of these elements.

Best,

Neil

[Neil Gould]

Re: General question about persistence

Hi,

"Bob Barrows [MVP]" <reb01501@NOyah oo.SPAMcomwrote in message
news:uvd1PL06IH A.5820@TK2MSFTN GP04.phx.gbl...

Neil Gould wrote:

Or... when is a script not a script?

I have several modules for managing different aspects of our club's
website, most of which are multi-page.

Does setting such things as server.ScriptTi meout or response.buffer
values at the start of the first page persist throughout the session,
or are they "reset" with each function or sub, etc.?

Response.Buffer applies only to the page in which it is called. And it
is not something that is affected by functions or subs running on the
page.
I think the same applies to Server.ScriptTi meout ... the docs don't say
so explicitly, but it would be easy enough to whip up a couple pages,
the first of which sets the ScriptTimeout to some large number and the
second of which checks the setting.
>

Thanks for your comments!


As in my other reply, I'm trying to get a handle on how the boundaries of
these are defined, because it doesn't always work as one might expect. You
can imagine how much I love having to hack the answers to that which should
be clearly documented! ;-)

Best,

Neil

[Jon Paal [MSMD]]

Re: General question about persistence

The Active Server Pages (ASP) framework provides six built-in objects:

Application
ObjectContext
Request
Response
Server
Session

Info about the scope of COM Objects in ASP Pages can be found here:

http://msdn.microsoft.com/en-us/library/ms525036.aspx

and here

http://msdn.microsoft.com/en-us/library/aa480423.aspx

[Bob Barrows [MVP]]

Re: General question about persistence

Neil Gould wrote:

Thanks Jon Paal, Bob, and Evertjan,
>
"Jon Paal [MSMD]" <Jon nospam Paal @ everywhere dot comwrote in
message
news:MP2dneGd4b YRKxnVnZ2dnUVZ_ jednZ2d@posted. palinacquisitio n...

>response.buffe r : Indicates whether the current page output is
>buffered.
>>
>server.ScriptT imeout : The ScriptTimeout property specifies the
>maximum amount of time any script in the application can run before
>it is terminated.
>>

Perhaps my experience is being affected by what the defined
boundaries of a "page" vs. "script" vs. "applicatio n" 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.

Yes, includes become part of the page/file

>
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.

If I had set the
response.buffer off on that page, then what (not that it would make
sense to turn it off knowing that it would be turned on again, but
this question is about boundaries rather than proper coding)?

The docs are pretty clear about Buffer. The property is
Response-specific.
The boundaries for a page are from when the page is requested (and the
response begins) to when the response ends. I'm not sure what is
puzzling you about this.

A form or browser sends a request to the server, which loads the
requested page, in which the server-side code runs and sends output to
response. When complete, the response ends.

>
From your comment Jon, if I set the timeout on (or before) the
initial page, will it persist for all later routines and pages?

Despite this being a property of the Server object, I don't think so.
This is where the docs have let me down.
I'm pretty sure the scripttimeout can be set for one page without
affecting it on other pages. I believe I have done this in the past. The
default setting in the website's metadata is in effect unless a page
sets scripttimeout on that particular page..
But again ... take two minutes and try it out. Don't depend on my
memory.
Oh, never mind ... here is a simple test. Run and refresh a page
containing this code:

<%@ Language=VBScri pt %>
<%
Response.Write Server.ScriptTi meout
Server.ScriptTi meout = 100
Response.Write "<BR>"
Response.Write Server.ScriptTi meout
%>

I get 90 (the default) and 100 every time I run this page. It's pretty
clear the scope of the setting is the page.


--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.

[Neil Gould]

Re: General question about persistence

Hi Jon Paal,

Thanks for the pointers. Most of this is the same as in the ASP
documentation that I have. At this point, I'm chasing down a combination of
my misconceptions and anomalous results from following these structures...
it's hard to tell which is which sometimes!

"Jon Paal [MSMD]" <Jon nospam Paal @ everywhere dot comwrote in message
news:p8ydnW9AZ_ XsRRnVnZ2dnUVZ_ jOdnZ2d@posted. palinacquisitio n...

The Active Server Pages (ASP) framework provides six built-in objects:
>
Application
ObjectContext
Request
Response
Server
Session
>
Info about the scope of COM Objects in ASP Pages can be found here:
>

http://msdn.microsoft.com/en-us/library/ms525036.aspx

>
and here
>

http://msdn.microsoft.com/en-us/library/aa480423.aspx

>
>

[Neil Gould]

Re: General question about persistence

Hi Bob,

"Bob Barrows [MVP]" <reb01501@NOyah oo.SPAMcomwrote in message
news:OZHamL26IH A.5276@TK2MSFTN GP05.phx.gbl...

Neil Gould wrote:

[...]

Perhaps my experience is being affected by what the defined
boundaries of a "page" vs. "script" vs. "applicatio n" 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, since a form's action can refer to
itself and process correctly. Does that make it "2 pages" from an ASP
perspective?

If I had set the
response.buffer off on that page, then what (not that it would make
sense to turn it off knowing that it would be turned on again, but
this question is about boundaries rather than proper coding)?

>
The docs are pretty clear about Buffer. The property is
Response-specific.
The boundaries for a page are from when the page is requested (and the
response begins) to when the response ends. I'm not sure what is
puzzling you about this.
>

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'. ;-)

A form or browser sends a request to the server, which loads the
requested page, in which the server-side code runs and sends output to
response. When complete, the response ends.
>

From your comment Jon, if I set the timeout on (or before) the
initial page, will it persist for all later routines and pages?

>
Despite this being a property of the Server object, I don't think so.
This is where the docs have let me down.
I'm pretty sure the scripttimeout can be set for one page without
affecting it on other pages. I believe I have done this in the past. The
default setting in the website's metadata is in effect unless a page
sets scripttimeout on that particular page..
But again ... take two minutes and try it out. Don't depend on my
memory.
Oh, never mind ... here is a simple test. Run and refresh a page
containing this code:
>
<%@ Language=VBScri pt %>
<%
Response.Write Server.ScriptTi meout
Server.ScriptTi meout = 100
Response.Write "<BR>"
Response.Write Server.ScriptTi meout
%>
>
I get 90 (the default) and 100 every time I run this page. It's pretty
clear the scope of the setting is the page.
>

I agree with your conclusion, which implies that Server.ScriptTi meout (and
what other Server methods???) is not persistent. Thanks!

Best,

Neil

[Bob Barrows [MVP]]

Re: General question about persistence

Neil Gould wrote:

Hi Bob,
>
"Bob Barrows [MVP]" <reb01501@NOyah oo.SPAMcomwrote in message
news:OZHamL26IH A.5276@TK2MSFTN GP05.phx.gbl...

>Neil Gould wrote:

[...]

>>Perhaps my experience is being affected by what the defined
>>boundaries of a "page" vs. "script" vs. "applicatio n" 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).

>

>>If I had set the
>>response.buff er off on that page, then what (not that it would make
>>sense to turn it off knowing that it would be turned on again, but
>>this question is about boundaries rather than proper coding)?

That property is in effect until the response ends. Period. See for
yourself:
<%@ Language=VBScri pt %>
<%
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><fo rm method=post>
<input type=submit></form></body></html>

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.

<snip>

I agree with your conclusion, which implies that Server.ScriptTi meout
(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.


--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"

[Anthony Jones]

Re: General question about persistence

"Neil Gould" <neil@myplaceof work.comwrote in message
news:uXfvJD$6IH A.1196@TK2MSFTN GP05.phx.gbl...

Hi Bob,
>
"Bob Barrows [MVP]" <reb01501@NOyah oo.SPAMcomwrote in message
news:OZHamL26IH A.5276@TK2MSFTN GP05.phx.gbl...

Neil Gould wrote:

[...]

Perhaps my experience is being affected by what the defined
boundaries of a "page" vs. "script" vs. "applicatio n" 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, since a form's action can refer

to

itself and process correctly. Does that make it "2 pages" from an ASP
perspective?
>

If I had set the
response.buffer off on that page, then what (not that it would make
sense to turn it off knowing that it would be turned on again, but
this question is about boundaries rather than proper coding)?

The docs are pretty clear about Buffer. The property is
Response-specific.
The boundaries for a page are from when the page is requested (and the
response begins) to when the response ends. I'm not sure what is
puzzling you about this.

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'. ;-)
>

I can understand the confusion. The P in ASP does stand for Page but
strictly speaking an ASP is simply an active script file. I think ASF was
already taken though.

The best approach is to forget the term Page altogether just think of them
as script files that receive some special pre-processing before being used
as a script.

In the case where you have a ASP (a script file) containing only functions
you will have to include that as part of another script for it to be of use.
The ASP.dll will build up a script by lexically inserting the includes (and
nested includes). Once the completed script text is built it converts it to
a form of script that can actually be parsed by the choosen scripting
language. Its then executed.

So in this case all server objects are common to all the scripts used as
includes. In addition the scripts share the same script context hence the
identifier namespace is shared between them also. When using includes you
need to watch out for name collisions where two or more of the files may
define the same variable or procedure name. I tend to use Classes in
include files to compartmentalis e the namespace.


Another way use supplementary ASP file is to use Server.Execute. In this
case though the executed script has an independant script context. All the
same server objects are exposed in the new context (so for example if
Server.ScriptTI meout was modified earlier during this request processing its
value will remain at the modified value) but none of the calling scripts
variables and procedures would be visible.



Apart form value modified on the Session object and the Application object
nothing else is persisted between individual requests.






--
Anthony Jones - MVP ASP/ASP.NET

[Neil Gould]

Re: General question about persistence

Hi Anthony,

"Anthony Jones" <Ant@yadayadaya da.comwrote in message
news:u2CKAf$6IH A.1196@TK2MSFTN GP05.phx.gbl...

>
In the case where you have a ASP (a script file) containing only functions
you will have to include that as part of another script for it to be of

use.

>

Well, not so fast. For instance, an ASP containing only functions can
process a form that calls it based on parameters set in the form. All that
is necessary to do this is that the tail end of that ASP process via
Request.Form (or a specific action sans Request.Form).

The ASP contains only:
------------------------
<%
FUNCTION DoThis1
....
END FUNCTION
%>

....

<%
FUNCTION DoThisX
....
END FUNCTION
%>

<%
DIM DoWhat
DoWhat = Request.Form("W hatToDo")

SELECT CASE DoWhat
CASE 1
DoThis1
CASE...
DoWhatever...
CASE X
DoThisX
END SELECT
%>
-----------------------------

The ASP.dll will build up a script by lexically inserting the includes

(and

nested includes). Once the completed script text is built it converts it

to

a form of script that can actually be parsed by the choosen scripting
language. Its then executed.
>
So in this case all server objects are common to all the scripts used as
includes. [...]
>

Does not Bob's test of Server.ScriptTi meout dispute this notion? If his ASP
calls itself, as in the above example, what is the expected result?

Best,

Neil

[Neil Gould]

Re: General question about persistence

Hi Bob,

"Bob Barrows [MVP]" <reb01501@NOyah oo.SPAMcomwrote in message
news:uNFJkb$6IH A.3816@TK2MSFTN GP03.phx.gbl...

Neil Gould wrote:

[...]

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:
>

That isn't how I was using "part", and I agree with you regarding functions
or subs.

I'm trying to grok the boundaries of such things as a "page", and in the
case where a form calls itself, there appears to be only one "page" from an
HTML point of view.

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.
>

I get that from a form's action that posts to the page containing the form
and processes the user input.

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).
>

Are you saying that the "page" boundaries are defined by HTML content sent
to the the client? If so, I understand why a form that calls itself would be
considered 2 pages from an ASP perspective. On the other hand, the only way
that I've been able to get parameters to persist reliably between functions
even in a single ASP file with no HTML is to set them as
Session.Content s.Items (or Application...) . So, I'm unclear about the
boundaries of a "page" in this context.

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.
>

Not what I'm asking about. See the example in my reply to Jon Paal. I have
ASP files (pages?) that do not contain HTML and perform other actions on the
server side (logging, updating a database, setting variables, etc.). Those
ASP files may have functions that call a file that contains HTML that is
sent to the client, and in such a case, it is clear that there are two or
more pages. But, what about the ASP file itself, since it is not an include
with the calling file, sends nothing to the client, and has no Response
properties or methods?

<snip>

I agree with your conclusion, which implies that Server.ScriptTi meout
(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.
>

Sorry for the confusion... written pre-coffee. I know that ScriptTimeout is
the only property of the Server Object.

Best,

Neil

[Evertjan.]

Re: General question about persistence

Neil Gould wrote on 22 jul 2008 in
microsoft.publi c.inetserver.as p.general:

Are you saying that the "page" boundaries are defined by HTML content
sent to the the client?

An ASP page is a text string being interpreted by the asp engine on a get
request, usually being the content of a single serverside file that bears
the name of the requested file.

So why a "page" and not a file? Because that file can be augmented by
includes including the text content of other files. Or the "page" can be
any other string that is imported by such file or by instructions in the
404.asp error system.

In effect the whole compount "file" that is constructed to be read by the
ASP-engine is the page, usually rendering and sending a header plus HTML
content [including clientside scripts] to the requesting client, could also
send any other header plus byte stream.

And the ASP-engine could be instructed to do serverside things unrelated to
the rendered content, like manipulating Session or Application variables
using ASP statements, and like file manipulation, database manipulation or
sending an email, all using specific ASP-external components.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)