Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP General > General question about persistence

Reply
Thread Tools

General question about persistence

 
 
Neil Gould
Guest
Posts: n/a
 
      07-21-2008
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.ScriptTimeout 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


 
Reply With Quote
 
 
 
 
Bob Barrows [MVP]
Guest
Posts: n/a
 
      07-21-2008
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.ScriptTimeout 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.ScriptTimeout ... 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.


 
Reply With Quote
 
 
 
 
Evertjan.
Guest
Posts: n/a
 
      07-21-2008
Bob Barrows [MVP] wrote on 21 jul 2008 in
microsoft.public.inetserver.asp.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.ScriptTimeout ... 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)
 
Reply With Quote
 
Neil Gould
Guest
Posts: n/a
 
      07-21-2008
Thanks Jon Paal, Bob, and Evertjan,

"Jon Paal [MSMD]" <Jon nospam Paal @ everywhere dot com> wrote in message
news:(E-Mail Removed) acquisition...
> response.buffer : Indicates whether the current page output is buffered.
>
> server.ScriptTimeout : 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. "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? 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


 
Reply With Quote
 
Neil Gould
Guest
Posts: n/a
 
      07-21-2008
Hi,

"Bob Barrows [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.ScriptTimeout 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.ScriptTimeout ... 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



 
Reply With Quote
 
Bob Barrows [MVP]
Guest
Posts: n/a
 
      07-21-2008
Neil Gould wrote:
> Thanks Jon Paal, Bob, and Evertjan,
>
> "Jon Paal [MSMD]" <Jon nospam Paal @ everywhere dot com> wrote in
> message
> news:(E-Mail Removed) acquisition...
>> response.buffer : Indicates whether the current page output is
>> buffered.
>>
>> server.ScriptTimeout : 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. "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.


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=VBScript %>
<%
Response.Write Server.ScriptTimeout
Server.ScriptTimeout = 100
Response.Write "<BR>"
Response.Write Server.ScriptTimeout
%>

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.


 
Reply With Quote
 
Bob Barrows [MVP]
Guest
Posts: n/a
 
      07-22-2008
Neil Gould wrote:
> Hi Bob,
>
> "Bob Barrows [MVP]" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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).

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


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


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


 
Reply With Quote
 
Anthony Jones
Guest
Posts: n/a
 
      07-22-2008
"Neil Gould" <(E-Mail Removed)> wrote in message
news:uXfvJD$(E-Mail Removed)...
> Hi Bob,
>
> "Bob Barrows [MVP]" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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, 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 compartmentalise 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.ScriptTImeout 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


 
Reply With Quote
 
Neil Gould
Guest
Posts: n/a
 
      07-22-2008
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 com> wrote in message
news(E-Mail Removed) acquisition...
> 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
>
>



 
Reply With Quote
 
Neil Gould
Guest
Posts: n/a
 
      07-22-2008
Hi Bob,

"Bob Barrows [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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, 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=VBScript %>
> <%
> Response.Write Server.ScriptTimeout
> Server.ScriptTimeout = 100
> Response.Write "<BR>"
> Response.Write Server.ScriptTimeout
> %>
>
> 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.ScriptTimeout (and
what other Server methods???) is not persistent. Thanks!

Best,

Neil


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
General....very general.... no important for u forever hi Python 0 03-18-2009 08:21 AM
Java Persistence API and persistence.xml Kenneth P. Turvey Java 2 03-16-2008 12:08 AM
Question about data persistence in Public variables Steve Mauldin ASP .Net 7 01-23-2006 07:46 PM
EJB persistence versus Database persistence? javaguy44 Java 10 05-18-2004 07:08 PM
Question about persistence and a global variable Simon Harvey ASP .Net 5 04-02-2004 03:01 PM



Advertisments