Site Unload?

[Ross M. Greenberg]

I want to have an onUnload that runs only when the site is left, not when
the current page is unloaded. Any ideas?

Thanks!

Ross

[Evertjan.]

Laurent Bugnion wrote on 20 dec 2004 in comp.lang.javas cript:

OK, that's the case in ASP.NET too (each Page object is deleted at the
end of every call, and of course its members too), but you also have
Session objects, for example you will save there DB connections, file
contents, "global" variables, etc... IIRC, ASP also have the Application
and Session objects, doesn't it? So my question was, how do you know
when to room the resources saved in the Session object if you don't know
when the said session has timed out?

Simple, Laurent, you don't.

Data is needed outside the present session should not be kept in session
memory.

The concept of "having a connection" with the client is a flawed one, as
the connection is not ASP but HTML. [I think hiding this fact of live is my
main objection to asp.net, while sold by MS as a bonus. But let our focus
stay on classic ASP.]

All pertinent data that is not to be lost, should be saved during the asp
execution fase of a single page to a serverside database or other file.

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

[Laurent Bugnion]

Hi,

Evertjan. wrote:

Laurent Bugnion wrote on 20 dec 2004 in comp.lang.javas cript:

OK, that's the case in ASP.NET too (each Page object is deleted at the
end of every call, and of course its members too), but you also have
Session objects, for example you will save there DB connections, file
contents, "global" variables, etc... IIRC, ASP also have the Application
and Session objects, doesn't it? So my question was, how do you know
when to room the resources saved in the Session object if you don't know
when the said session has timed out?

Simple, Laurent, you don't.

Data is needed outside the present session should not be kept in session
memory.

The concept of "having a connection" with the client is a flawed one, as
the connection is not ASP but HTML. [I think hiding this fact of live is my
main objection to asp.net, while sold by MS as a bonus. But let our focus
stay on classic ASP.]

I didn't mean connections between the client and the server (I am aware
that HTTP is stateless), but rather connections to databases, which can
remain open for example as long as a certain page is displayed, to avoid
re-connecting to the DB every time the page is refreshed. THis is only
an example, BTW. I can think of multiple reasons to cache data in the
Session object.

I am not sure I understand your objection to ASP.NET, maybe you mean
that it gives the programmer the impression that there is a connection
between the client and the server, since the events are redirected to
the correct event handlers automatically, thus hiding the fact that
there is a Request object and a whole HTTP GET or POST process behind
all this. If that's what you mean, then I can ensure you that this basic
fact of life is hidden only from very basic programmers who make very
small Web Applications. As soon as your application is a bit bigger, you
need to have a good knowledge of the exact processes between every
request/response, believe me ;-)
All pertinent data that is not to be lost, should be saved during the asp
execution fase of a single page to a serverside database or other file.

That's not very efficient to say the least.

Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
Private/Malaysia: http://mypage.bluewin.ch/lbugnion
Support children in Calcutta: http://www.calcutta-espoir.ch

[Evertjan.]

Laurent Bugnion wrote on 20 dec 2004 in comp.lang.javas cript:

I didn't mean connections between the client and the server (I am
aware that HTTP is stateless), but rather connections to databases,
which can remain open for example as long as a certain page is
displayed, to avoid re-connecting to the DB every time the page is
refreshed. THis is only an example, BTW. I can think of multiple
reasons to cache data in the Session object.
I don't think you can keep a database connection open between pages even
while refreshing the same page [as stateless HTML does not see the
difference between same and other, as long as the page is refetched from
the server.]
I am not sure I understand your objection to ASP.NET, maybe you mean
that it gives the programmer the impression that there is a connection
between the client and the server,
YES
since the events are redirected to
the correct event handlers automatically, thus hiding the fact that
there is a Request object and a whole HTTP GET or POST process behind
all this. If that's what you mean, then I can ensure you that this
basic fact of life is hidden only from very basic programmers who make
very small Web Applications.
I don't think so. It is the reason for ASP.Net, me thinks.
As soon as your application is a bit
bigger, you need to have a good knowledge of the exact processes
between every request/response, believe me ;-)

That is why ASP is more logical, since it doesn't hide those things from
view.

All pertinent data that is not to be lost, should be saved during the
asp execution fase of a single page to a serverside database or other
file.

That's not very efficient to say the least.

Perhaps, but it is a fact of stateless HTML life.

Save it or sometimes loose it. The data, I mean.

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

[Tim Williams]

"Evertjan." <ex************ **@interxnl.net > wrote in message
news:Xn******** ************@19 4.109.133.29...

Laurent Bugnion wrote on 20 dec 2004 in comp.lang.javas cript:

I didn't mean connections between the client and the server (I am
aware that HTTP is stateless), but rather connections to databases,
which can remain open for example as long as a certain page is
displayed, to avoid re-connecting to the DB every time the page is
refreshed. THis is only an example, BTW. I can think of multiple
reasons to cache data in the Session object.

I don't think you can keep a database connection open between pages
even
while refreshing the same page [as stateless HTML does not see the
difference between same and other, as long as the page is refetched
from
the server.]

It's a common mistake to cache DB connections in the session object.
By doing this you prevent another user from re-using the connection
and actually end up putting more load on the server and the DB by
having to carry a larger number of connection.

If you let it, Windows will handle your connection pooling for you:
when you close a connection it will keep it open for a short time and
re-use it for the next request instead of creating a whole new one.
Once you put the connection object into the session your pooling is
shot.

Tim.

[Evertjan.]

Tim Williams wrote on 21 dec 2004 in comp.lang.javas cript:

Once you put the connection object into the session your pooling is
shot.

Do you mean in a session variable?

Since a session variable is only a string,
how can you put an object in a string?

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

[Laurent Bugnion]

Hi,

Evertjan. wrote:

Tim Williams wrote on 21 dec 2004 in comp.lang.javas cript:

Once you put the connection object into the session your pooling is
shot.

Do you mean in a session variable?

Since a session variable is only a string,
how can you put an object in a string?

No, he means (I think) the Session object. In ASP.NET, each Page is an
object, and has one property named Session (of type HttpSessionStat e),
and this object is a collection in which you can store pretty much
everything you want, including references to other objects.

To Tim: We were not talking necessarily about storing things in the
Session, but rather on the server generally between requests. Other ways
exist in ASP.NET, for example the Application object, static variables,
etc...

Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
Private/Malaysia: http://mypage.bluewin.ch/lbugnion
Support children in Calcutta: http://www.calcutta-espoir.ch