Sorry, but when you're a user in Hong Kong waiting several tens of
seconds for a web server in London to serve you a page across a crappy
wan, performance is definitely an issue. And to keep performance
optimal, the fewer round trips you make the better, which means avoiding
response.redirect where you can.
I'd venture to suggest that this kind of thing should be a concern even
if you're not aiming at a particularly slow network. There are
circumstances for using response.redirect but I don't believe it should
be a first choice.
The idea of a single asp page is one I'd thought of, but I just want to
keep the granularity of a single page doing a single thing. If you know
Java, think of the way you'd traditional split a servlet and a jsp. But
I agree it's possible to do things this way - it's even possible to keep
the granularity just by adopting a #include approach, albeit this way is
a bit of a fudge. We may end up going this way.
I did try cookies - 1.asp would set a cookie and call .transfer, 2.asp
would load (2.asp can't see the cookie - I tried this) but with an
onload event getting executed client-side script to look inside the
cookie and do its stuff. And this worked, only problem was once the
cookie was there it was difficult to (100% reliably) get rid of the
blooming thing!
Thanks for the responses. I think it'll either be a single page, or a
case of Sod this I'm turning on the session object!
*** Sent via Developersdex
http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!