Can one aspx page post to another aspx page? 2

[drew10]

Can one aspx page post to another aspx page? I have a form on one page, and I would like it to post to another aspx page, but if I change the action, it still submits to itself. Could I do a response.redirect if it is not a postback? Would the posted data be there? Thanks for any input!
-Drew

 

[sthmpsn1]

If you used session variables you could do this. I have a 2 page application where the relevant data is passed through session variables. Works good for me. Otherwise if it is a simple application you may want to look into using aspanels, which would keep everything on one page.

 

[Zarcom]

I have noticed the same thing drew. However, I dislike using sessions when it is unnecessary for performance reasons.

Instead I use the response.redirect and use query strings to send my data across to the other page.

ie.
dim sb as new stringbuilder
sb.append("mypage.aspx?data=&quot
sb.append(txtdata.text)
sb.append("&otherdata=&quot
sb.append(txtotherdata.text)

Response.Redirect(sb.tostring)


Seems to work quite well for me. If I need to pass sensitive data such as a password then the password goes in the session variable but everything else still gets sent through a querystring. That'l do donkey, that'l do
Mark
If you are unsure of forum etiquette check here faq796-2540

 

[sthmpsn1]

Mark's way of doing it is a much better way because of performance! Unfortunately for me all my dad is sensitive that is being passed.

 

[Zarcom]

Thanks Sthmpsn That'l do donkey, that'l do
Mark
If you are unsure of forum etiquette check here faq796-2540

 

[Custom24]

Hi
Zarcom's solution is the one I use most of the time.
However, you should use this slight modification

dim sb as new stringbuilder
sb.append("mypage.aspx?data=&quot
sb.append(server.urlencode(txtdata.text))
sb.append("&otherdata=&quot
sb.append(server.urlencode(txtotherdata.text))

Response.Redirect(sb.tostring)

This is because the query string needs to be encoded into a format a url can accept

As for sending sensitive information, I've not yet seen an example of using the POST method in ASPX. But here is an interesting link to a method which uses server.transfer and some wizardry which allows you to access the data of the sending page...

http://aspnet.4guysfromrolla.com/articles/050802-1.aspx

Hope this helps
Mark

 

[Zarcom]

Hey other Mark.
What do you mean by the query string needs to be encoded into a format a url can accept. Do you know what server.urlencode does? Just wondering cause I havn't ever had any trouble without it. That'l do donkey, that'l do
Mark
If you are unsure of forum etiquette check here faq796-2540

 

[Custom24]

Hi Zarcom
You need to encode a string when you send it in the query string. Otherwise a lot of the characters the user will routinely type in cannot be sent because the url is not valid. For example, a url cannot accept spaces, CrLf, tabs, etc. So these characters get encoded. The rules are complicated, so the easiest way is to let the server.urlencode method do the work for you.

You don't have to use server.urldecode because when you call request.querystring("key&quot, it is done automatically.

As far as I know this was around in classic asp as well.

You will not have had any problems using the simple way if you've only been passing ids or short simple codes over the query string (see the url for this page as an example - there are no special characters in it)

A similar thing occurs when you are talking to a db via a command object. If you just set up the SQL string as plain text, weird things will happen when the user enters stuff you do not exprect (like for example a semicolon). So the approach here is to use parameters.

Hope this helps
Mark

 

[Zarcom]

Good thing to remember That'l do donkey, that'l do
Mark
If you are unsure of forum etiquette check here faq796-2540

 

[Isadore]

This is a good argument, the use of QueryStrings and Session state for management of data. I use Session variables for the most part, but create and eliminate them at first opportunity.

I have also read that Session variables is the number one draw back in scaling up a site -- but so far I have had no trouble.

What do you think the general ball park number would be for an average user having, say, 30 Session variables in play -- 500 per day? 5,000 per day? Obviously it will depend on whether you're on SQL Server, etc....

As a general rule should one avoid Session and choose Querystrings? I guess I'm not real sure how intensive a Session variable or variables can be on the Server resources? Is it "alot" or "somewhat"...anyway, trying to get a feel for this as this is an important area.

 

[link9]

It's all a direct function of how much memory your server has... the more RAM, the better the performance. RAM is cheap, so load it up w/ as much as it will hold.

I don't know of a solid "byte to variable" ratio, however.

 

[link9]

Actually, I guess that was pretty silly of me to say. It will correspond directly with how big the variable is... if it's a 32 byte integer, it will take up 32 bytes of memory space.

 

[Isadore]

Thanks Paul. Most of my Session state variables are either simple integer numbers, or one word "strings". As I mentioned, they are created and at the first opportunity, e.g., a Cancel, or Save event, I put in:

Session.RemoveAll

to clear them out. I have found that inserting is much faster with Session variables than say, inserting data from form textboxes (the former: 2 secs per records over a 24K bps connection, the latter, 6 seconds).

I suppose when you can use Querystrings without a problem, such as passing 12-15 numbers to the next aspx page, is probably preferable. But my observations are that Session variables are handled quite smoothly and very fast - so I suppose you want to use them when you can without jeopardizing performance --

 

[link9]

I'm of the same mind. Used sparingly and sensibly, session is an extremely useful tool.

I'm also of the mind that budding developers should be steered away from them, as using them is a little too easy to get carried away with. I disagree with the willy-nilly usage of session in "training" books. Datasets and the like are just slammed into session with no mention of the drawbacks. It's irresponsible of the authors, IMHO.

 

[Isadore]

The only time I put a DataSet into play is in Cache, just before ChartDirector picks up the Array for a chart -- I have not yet put a DataSet into Session and so far only reserve for single digit and simple string variables.

However, as a result of this discussion, there are places where the QueryString can carry over variables just as easy, and it sounds like the practical thing to do.

As mentioned, I have notice a substantial time difference between Insertion of Session variables versus textbox strings and so will use them and remove them in these situations.

If someone gets statistcial performance data on this subject it would be interesting to see, perhaps draw up a FAQ for it. Good discussion.