Passing data through a Server.Transfer

[Pete]

Any ideas on how I can set some data in 1.asp, then have 1.asp do a
server.transfer (or .execute, come to that) to 2.asp, and have 2.asp
access the original data?

I'm aware that the Session object fits the bill but want to avoid using
this if I can. Having said that, the nature of the data is very much
per-user so things like the application object are definitely
inappropriate.

Another way I can do this is redirect/querystring, but the additional
roundtrip here is not attractive.

Any other (sensible) methods anyone can think of?

TIA,
Pete

 

[Steven Burn]

None using Server.Transfer etc, that I can think of. You might want to use
something along the lines of;

Page1.asp

<input type="text" name="myname" value="<%thetext%>">

Page2.asp

Dim thetext
thetext = Request.Form("thetext")

--
Regards

Steven Burn
Ur I.T. Mate Group
www.it-mate.co.uk

Keeping it FREE!

Disclaimer:
I know I'm probably wrong, I just like taking part ;o)

 

[Pete]

Nice idea. I should have added, though, that I don't want 1.asp to do
any UI at all.

The role of 1.asp is to kick off some back-end stuff (a db write, say),
the role of 2.asp is to render stuff. It's actually the result of the
"back-end stuff" that I want to pass through. So 1.asp writes data,
2.asp reads/displays data.

If you imagine a page with a form on it, for example. The form gets
posted to 1.asp, which takes care of storing the form to a database
(say). 1.asp then calls 2.asp, which displays something useful. So 2.asp
doesn't know/care about the form that was just submitted, but it might
need to be able to alert the user as to the success/failure of the
operation.

I'm aware, by the way, that I could do a .transfer to different pages
based on the result. But there could be many results, so that's just not
scalable.

 

[MDJ]

Well, I don't think there's an issue with passing one or more variables in
the querystring then, it's certainly the way i'd do it if I wanted to avoid
cookies. Forget how 'attractive' it might be, although if you really want to
make the whole thing compact for compactness sake just put all your
functions into one page and control them with querystrings, form posts and
other variables in the page. A useful web application WILL in my experience
almost always use redirects from one place to another. I have little
experience with Server.Transfer but from the little I have I remember you
can't pass querystrings in it, just use Response.Redirect("page.asp?ID=" &
Request.Querystring("ID")) and <a
href="page.asp?ID=<%Request.Querystring("ID")%>">Link</a> to maintain state.

 

[dlbjr]

Why not do it all in one asp code?


-dlbjr

Discerning resolutions for the alms

 

[Brynn]

I would do the form thing with hidden fields and do the javascript
thing to auto-submit the form ... let me know if you want a sample
javascript.

You may want to consider the very rare case that someone may have
javascript off or something and have a "if this doesn't redirect,
click here" image to submit.

Brynn
www.coolpier.com

 

[MDJ]

Why not. It just depends how the programmer likes to arrange his/her
application.

 

[Pete]

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!