Loading ...
Sorry, an error occurred while loading the content.
 

Re: caching form data? (etc.)

Expand Messages
  • Josh Chamas
    ... subroutines that have variables they are using that are improperly scoped will be retained in subsequent requests. Improper scoping of variables can result
    Message 1 of 8 , Oct 4, 2002
      dave_apache_asp wrote:
      >
      > I had already made sure this wasn't a browser-caching issue with a
      > random number display; it is definitely server-side. Per Joshua's
      > suggestion, I took the subroutine out of the ASP and that seems to
      > have solved the problem. Apparently subroutines compiled in ASPs
      > retain their original variables?
      >

      subroutines that have variables they are using that are
      improperly scoped will be retained in subsequent requests.
      Improper scoping of variables can result in my closure behavior.

      As long as all variables in a subroutine are accessing
      global variables ( like $main::Response ) or my()
      scoped variables, then that subroutine should be able to
      be written in a ASP script fine. Moving subs to a real
      perl module/package avoids these problems by forcing
      variables to be properly scoped during compilation.

      Regards,

      Josh
      ________________________________________________________________
      Josh Chamas, Founder phone:925-552-0128
      Chamas Enterprises Inc. http://www.chamas.com
      NodeWorks Link Checking http://www.nodeworks.com


      ---------------------------------------------------------------------
      To unsubscribe, e-mail: asp-unsubscribe@...
      For additional commands, e-mail: asp-help@...
    • dave_apache_asp
      I added this line to my subroutine, which also fixes it: my $Request = $main::Request; I have been using strict all along, but referring to $Request in a
      Message 2 of 8 , Oct 4, 2002
        I added this line to my subroutine, which also fixes it:

        my $Request = $main::Request;

        I have been using strict all along, but referring to $Request in a
        subroutine without fully qualifying it seems to be the problem. That
        was apparently causing the first $Request to be cached.

        thanks so much,
        -dave

        > As long as all variables in a subroutine are accessing
        > global variables ( like $main::Response ) or my()
        > scoped variables, then that subroutine should be able to
        > be written in a ASP script fine. Moving subs to a real
        > perl module/package avoids these problems by forcing
        > variables to be properly scoped during compilation.



        ---------------------------------------------------------------------
        To unsubscribe, e-mail: asp-unsubscribe@...
        For additional commands, e-mail: asp-help@...
      • dave_apache_asp
        Actually, that line doesn t work after all... I went back to removing the subroutine which is the only thing that has seemed to work. The only variables that
        Message 3 of 8 , Oct 4, 2002
          Actually, that line doesn't work after all...

          I went back to removing the subroutine which is the only thing that
          has seemed to work. The only variables that aren't declared as 'my'
          in the subroutine are the intrinsic objects so I don't know how it
          could be a scoping issue. I guess I'm stumped. I'll just shut up
          now.

          thanks for tolerating me,
          -dave

          --- In apache-asp@y..., "dave_apache_asp" <dave_apache_asp@y...>
          wrote:
          > I added this line to my subroutine, which also fixes it:
          >
          > my $Request = $main::Request;
          >
          > I have been using strict all along, but referring to $Request in a
          > subroutine without fully qualifying it seems to be the problem.
          That
          > was apparently causing the first $Request to be cached.
          >
          > thanks so much,
          > -dave
          >
          > > As long as all variables in a subroutine are accessing
          > > global variables ( like $main::Response ) or my()
          > > scoped variables, then that subroutine should be able to
          > > be written in a ASP script fine. Moving subs to a real
          > > perl module/package avoids these problems by forcing
          > > variables to be properly scoped during compilation.
          >
          >
          >
          > --------------------------------------------------------------------
          -
          > To unsubscribe, e-mail: asp-unsubscribe@p...
          > For additional commands, e-mail: asp-help@p...


          ---------------------------------------------------------------------
          To unsubscribe, e-mail: asp-unsubscribe@...
          For additional commands, e-mail: asp-help@...
        Your message has been successfully submitted and would be delivered to recipients shortly.