General question about persistence

Discussion in 'ASP General' started by Neil Gould, Jul 21, 2008.

  1. Neil Gould

    Neil Gould Guest

    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
    Neil Gould, Jul 21, 2008
    #1
    1. Advertising

  2. 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.
    Bob Barrows [MVP], Jul 21, 2008
    #2
    1. Advertising

  3. Neil Gould

    Evertjan. Guest

    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)
    Evertjan., Jul 21, 2008
    #3
  4. Neil Gould

    Neil Gould Guest

    Thanks Jon Paal, Bob, and Evertjan,

    "Jon Paal [MSMD]" <Jon nospam Paal @ everywhere dot com> wrote in message
    news:...
    > 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
    Neil Gould, Jul 21, 2008
    #4
  5. Neil Gould

    Neil Gould Guest

    Hi,

    "Bob Barrows [MVP]" <> wrote in message
    news:...
    > 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
    Neil Gould, Jul 21, 2008
    #5
  6. Neil Gould wrote:
    > Thanks Jon Paal, Bob, and Evertjan,
    >
    > "Jon Paal [MSMD]" <Jon nospam Paal @ everywhere dot com> wrote in
    > message
    > news:...
    >> 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.
    Bob Barrows [MVP], Jul 21, 2008
    #6
  7. Neil Gould wrote:
    > Hi Bob,
    >
    > "Bob Barrows [MVP]" <> wrote in message
    > news:...
    >> 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"
    Bob Barrows [MVP], Jul 22, 2008
    #7
  8. "Neil Gould" <> wrote in message
    news:uXfvJD$...
    > Hi Bob,
    >
    > "Bob Barrows [MVP]" <> wrote in message
    > news:...
    > > 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
    Anthony Jones, Jul 22, 2008
    #8
  9. Neil Gould

    Neil Gould Guest

    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:p...
    > 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, Jul 22, 2008
    #9
  10. Neil Gould

    Neil Gould Guest

    Hi Bob,

    "Bob Barrows [MVP]" <> wrote in message
    news:...
    > 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
    Neil Gould, Jul 22, 2008
    #10
  11. Neil Gould

    Evertjan. Guest

    Neil Gould wrote on 22 jul 2008 in
    microsoft.public.inetserver.asp.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)
    Evertjan., Jul 22, 2008
    #11
  12. Neil Gould wrote:
    >>

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


    Sort of. The end-boundary is defined by the act of sending the final
    piece of html content to the client. If Buffer is on, then no html is
    sent to the client until the response ends. If buffering is off, html
    can be sent to the client before the end of the response by
    Response.Flush. In that case, the response continues until Response.End
    is called or asp.dll runs out of code to process in the file.

    The "page" starts when asp.dll starts processing a file requested from
    the webserver.

    > If so, I understand why a form that calls
    > itself would be considered 2 pages from an ASP perspective.


    Think of it as being from the web server's, or really, the asp.dll's
    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.Contents.Items (or Application...).


    Huh? Now it seems as if you are confused about scope. Variables declared
    within functions/subs are only accessible within those functions/subs.
    Variables declared outside of functions/subs are accessible to all code
    in the scope of the page in which they are declared.

    dim globalvar
    globalvar=5
    function useglobalvar()
    response.write globalvar
    end function

    Maybe I'm not getting what you are talking about: could you provide a
    repro to make clear what you are talking about?


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


    By "call a file", are you talking about loading text from a file via
    FileScriptingobject? or are you talking about a server-side include
    (ssi)?

    > that contains HTML that is sent to the client, and in such a case, it
    > is clear that there are two or more pages.


    .... and they are sending that html to the client via the response that
    was begun when the initially-called file was started to be processed by
    asp.dll.

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


    Any file that is processed by asp.dll starts and ends a response. Even a
    file that makes no explicit mention of the Response object. In such a
    case, when the response ends, an empty page is seen by the client
    (unless an error occurs). If you are requesting that page using Ajax or
    xmlhttprequest, then you will likely not even look at the responsetext
    property when calling this file. However, that html is returned - an
    empty string is html.





    --
    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.
    Bob Barrows [MVP], Jul 22, 2008
    #12
  13. Neil Gould

    Neil Gould Guest

    Hi Anthony,

    "Anthony Jones" <> wrote in message
    news:u2CKAf$...
    >
    > 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("WhatToDo")

    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.ScriptTimeout dispute this notion? If his ASP
    calls itself, as in the above example, what is the expected result?

    Best,

    Neil
    Neil Gould, Jul 22, 2008
    #13
  14. Neil Gould wrote:
    > Yes, but *values* set for those variables sometimes get dumped before
    > the subsequent functions/subs can use them. In order to guarantee
    > persistence, I've had to set those values as


    During the same execution of that page?
    Show me.

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

    >>
    >> Any file that is processed by asp.dll starts and ends a response.
    >>

    > This is clear.
    >
    > So, a multi-function ASP file may start and end the asp.dll multiple
    > times,


    No. Only if it is called (requested) multiple times.

    >thus making that file appear as several "pages", and the HTML
    > is not a delimiter...or am I still conceptually off-base?
    >

    Something is surely escaping me here. You really need to show me what
    you are talking about.



    --
    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.
    Bob Barrows [MVP], Jul 22, 2008
    #14
  15. Neil Gould wrote:
    > Hi,
    >
    > "Evertjan." <> wrote in message
    > news:Xns9AE3B0A14FB23eejj99@194.109.133.242...
    >> [...]
    >> 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.
    >>

    > This is the aspect that I'm dealing with most often in trying to get a
    > handle on persistence issues. Sometimes, variable values that aren't
    > stored as session items get "lost", and are reported as empty when
    > tested with response.write or some other means.
    >

    Show us.
    --
    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.
    Bob Barrows [MVP], Jul 22, 2008
    #15
  16. Neil Gould

    Neil Gould Guest

    Hi Bob,

    "Bob Barrows [MVP]" <> wrote in message
    news:uNFJkb$...
    > 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.Contents.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.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.
    >

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

    Best,

    Neil
    Neil Gould, Jul 22, 2008
    #16
  17. Neil Gould

    Evertjan. Guest

    Bob Barrows [MVP] wrote on 22 jul 2008 in
    microsoft.public.inetserver.asp.general:

    > Neil Gould wrote:
    >> Hi,
    >>
    >> "Evertjan." <> wrote in message
    >> news:Xns9AE3B0A14FB23eejj99@194.109.133.242...
    >>> [...]
    >>> 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.
    >>>

    >> This is the aspect that I'm dealing with most often in trying to get a
    >> handle on persistence issues. Sometimes, variable values that aren't
    >> stored as session items get "lost", and are reported as empty when
    >> tested with response.write or some other means.
    >>

    > Show us.


    Indeed. Show us an example.

    I never lost a value yet,
    that is what I value about scripting languages,
    as compared to linguistic languages,
    where values are often handled like garbage.

    Many scripting languages make use of a garbage collector,
    but only to collect variables that are already orphaned.


    --
    Evertjan.
    The Netherlands.
    (Please change the x'es to dots in my emailaddress)
    Evertjan., Jul 22, 2008
    #17
  18. "Neil Gould" <> wrote in message
    news:...
    > Hi Anthony,
    >
    > "Anthony Jones" <> wrote in message
    > news:u2CKAf$...
    > >
    > > 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("WhatToDo")
    >
    > SELECT CASE DoWhat
    > CASE 1
    > DoThis1
    > CASE...
    > DoWhatever...
    > CASE X
    > DoThisX
    > END SELECT
    > %>
    > -----------------------------
    >


    I think you are really struggling with the nomenclature here. The above
    ASP doesn't "only contain functions" The Select Case code is in the global
    space and will execute as part the a response to a form post. An ASP page
    that contains only functions would only contain code bracketed by
    Function/End Function and therefore when executed would do nothing.

    What you mean is an ASP page that contains no significant text outside of <%
    %> which would be sent to the response. (Note that whitespace such as is in
    your code above can be sent).

    Are you saying the code does nothing to the Response object or that the code
    only use Response.Write etc to generate output?

    Note that effectively anything between %> <% (that is anything outside of
    the script delimiters) effectively becomes a Response.BinaryWrite which
    sends the bytes found between a closing %> and an opening <%. The parser
    having replaced %> <% and anything in between with such a psuedo binarywrite
    now has pure script that it can parse. (Actually its a little more complex
    than that but its a good working mental model).




    > > 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.ScriptTimeout dispute this notion? If his

    ASP
    > calls itself, as in the above example, what is the expected result?
    >



    I'm not sure how an ASP calls itself? It has created functions which are
    then called by the code. This all happens as part of the processing of a
    single request. If you changed ScriptTimeout outside of a function and
    then checked it value inside a function you would find it has the same
    value.

    Once the request processing is completed the Script context is reset
    including the ScriptTimeout, the only data that can persist beyond that is
    Session and Application.





    --
    Anthony Jones - MVP ASP/ASP.NET
    Anthony Jones, Jul 22, 2008
    #18
  19. Neil Gould

    Neil Gould Guest

    Hi Bob,

    "Bob Barrows [MVP]" <> wrote in message
    news:#...
    > Neil Gould wrote:
    > >>

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

    >
    > Sort of. The end-boundary is defined by the act of sending the final
    > piece of html content to the client. If Buffer is on, then no html is
    > sent to the client until the response ends. If buffering is off, html
    > can be sent to the client before the end of the response by
    > Response.Flush. In that case, the response continues until Response.End
    > is called or asp.dll runs out of code to process in the file.
    >
    > The "page" starts when asp.dll starts processing a file requested from
    > the webserver.
    >

    This is how I understood the "page" to be defined from the literature.
    However, some unexpected results of treating ASP code in this manner raised
    the questions that I've been asking, particularly regarding the persistence
    of certain aspects such as variable values, results of processing, etc.

    > > If so, I understand why a form that calls
    > > itself would be considered 2 pages from an ASP perspective.

    >
    > Think of it as being from the web server's, or really, the asp.dll's
    > perspective.
    >

    Got it. But, that implies that a single ASP file can be "seen" as more than
    one "page" if it contains multiple functions. And, that describes the
    behavior that I've observed and am struggling to grasp.

    > > 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.Contents.Items (or Application...).

    >
    > Huh? Now it seems as if you are confused about scope. Variables declared
    > within functions/subs are only accessible within those functions/subs.
    > Variables declared outside of functions/subs are accessible to all code
    > in the scope of the page in which they are declared.
    >

    Yes, but *values* set for those variables sometimes get dumped before the
    subsequent functions/subs can use them. In order to guarantee persistence,
    I've had to set those values as Session.Contents.Item(s). Works, but I don't
    know why the variable values were lost, except for the possibility that the
    single ASP file is "seen" as several "pages", and those values don't persist
    across pages.

    > Maybe I'm not getting what you are talking about: could you provide a
    > repro to make clear what you are talking about?
    >

    I think we're getting closer to talking about the same thing (as below).

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

    >
    > Any file that is processed by asp.dll starts and ends a response.
    >

    This is clear.

    So, a multi-function ASP file may start and end the asp.dll multiple times,
    thus making that file appear as several "pages", and the HTML is not a
    delimiter...or am I still conceptually off-base?

    Best,

    Neil
    Neil Gould, Jul 22, 2008
    #19
  20. Neil Gould

    Neil Gould Guest

    Hi,

    "Evertjan." <> wrote in message
    news:Xns9AE3B0A14FB23eejj99@194.109.133.242...
    > [...]
    > 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.
    >

    This is the aspect that I'm dealing with most often in trying to get a
    handle on persistence issues. Sometimes, variable values that aren't stored
    as session items get "lost", and are reported as empty when tested with
    response.write or some other means.

    Best,

    Neil
    Neil Gould, Jul 22, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Simon Harvey
    Replies:
    5
    Views:
    456
    Sebastien Lambla
    Apr 2, 2004
  2. Steve Mauldin
    Replies:
    7
    Views:
    497
    Steve Mauldin
    Jan 23, 2006
  3. javaguy44
    Replies:
    10
    Views:
    978
    Michael Berg
    May 18, 2004
  4. Amy Johnson
    Replies:
    3
    Views:
    414
    Sudsy
    Dec 1, 2004
  5. Kenneth P. Turvey

    Java Persistence API and persistence.xml

    Kenneth P. Turvey, Mar 15, 2008, in forum: Java
    Replies:
    2
    Views:
    17,309
    Kenneth P. Turvey
    Mar 16, 2008
Loading...

Share This Page