ansaurus

Question

How can I "Go Back" without using Response.Redirect

Answer 1

+1 A:

If you are using MVC, you will have to refill the model from the submitted values in Request.Form.

If you are doing the classic WebForms, you need to generate your form.html dynamically inserting the previously submitted values into it.

You could put your submitted values into session:

Session["UserName"] = Request.Form["UserName"]

Then you do redirect to your form.aspx:

<input type="text" value="<%= Session["UserName"]" />

This will however return the page as form.aspx. But it shouldn't be a real problem, it's just the name.

User 2009-07-17 10:14:00

Answer 2

+2 A:

You say that form.html can't use any javascript on form.html - does that mean you can't use Javascript at all in this solution?

My answer would be to output a javascript snippet from your processform.aspx that simply calls history.go(-1).

Example:

if(valid) 
{
    Response.Redirect("success.html", true);
} 
Response.Clear();
Response.Write("<html><body><script>history.go(-1);</script></body></html>");
Response.Flush();
Response.End();

If, however, you cannot use Javascript at all... the options are rather limited.

RFC 2616 defines HTTP 204 "No Content" - you could attempt to send that, but this is a success status, and behaviour from browsers might vary. Theoretically, however, the content should stay the same. Users might be very confused, however, because there's no visible feedback.

If you could explain the reasoning behind these restrictions, perhaps we could produce a better solution.

Will Hughes 2009-07-17 10:21:36

This is an excellent solution, however I was hoping to not have to use javascript at all. I can't use javascript with the form.html, but I could use javascript within the processform.aspx page. I might wait a while, see if anyone else has any other ideas. This is my first question on this site and I nearly fell out of my chair with a great answer in less than 10 mins from posting!

Tim 2009-07-17 10:40:05

Welcome to the fun ;)

borisCallens 2009-07-17 11:15:46

Clarified my answer. Looks like you might be able to get away with sending HTTP 204. See how that goes.

Will Hughes 2009-07-17 11:34:40

I think I'm going to have to rethink the whole way I'm going about this. I will post another question with the full description of what I am trying to achieve over the weekend. Thanks for your input. Cheers, Tim

Tim 2009-07-17 11:49:51

Answer 3

+1 A:

My approach would be to have the form submit to itself - that is, <form action="" method="POST">. The form, if retrieved using GET, simply displays itself. If it is retrieved using POST, it validates the posted information and, if there are any problems, re-displays itself as for GET, but with the errors flagged (and with the user's input preserved). If there are no validation errors, it does whatever it does with the information, and then uses Response.Redirect() to send the user to whatever the next page after a successful submission may be.

NickFitz 2009-07-17 11:12:04

I used this method before but it has som x-browser issues

borisCallens 2009-07-17 11:17:13

@Boris: Really? I've been using this approach since 1997 (the days of Netscape Navigator 3) and never encountered any issues. What problems have you encountered?

NickFitz 2009-07-17 11:21:33

My form must be plain html (it can't be an aspx page), therefore I can't process the form data using the same page (the validation must be done within the processform.aspx page). So the only solution so far is to process the form data on the processform.aspx page and then "go back" if there are any validation errors.

Tim 2009-07-17 11:26:57

According to the HTML specs the action element has to be set to a URL, so an empty action is not valid. But as NickFitz states this works in all browsers.http://www.w3.org/TR/html401/interact/forms.html#adef-action

Jan Aagaard 2009-07-17 11:39:48

You might be right. I don't really recall what the issue was. But I remember using it a while back and for some reason taking an other approach. Sorry for the confusion and this rather vague post. I should learn to think before I write ;)

borisCallens 2009-07-17 12:26:47

Answer 4

A:

How about posting the form to another target? E.g. form target="_blank"

In the new window, perform the form data processing and then manipulate the html form page depending on the result.

It's untidy, but might just work for you.

PS: Do note that form target attribute is deprecated in HTML 4.01.

o.k.w 2009-07-17 12:34:13

Answer 5

A:

Merge the two files into one, and show posted values in the form. Eg. <input type="text" name="lorem" value="<?=Request.Form["lorem"] ?? "default value" ?>">

If you have the form in a "dumb" html-file, you will not be able to inform the user of any validation errors, thus if the user enters incorrect data and submits the form they will get back to the form without any information whatsoever on what went wrong, and that's a no-no!

svinto 2009-07-17 12:54:46

Answer 6

+1 A:

I would look at Server.Transfer. It will internally reroute the request to another page without a redirect. Use this to transfer to the page containing the form HTML.

spoulson 2009-07-17 13:00:02

ansaurus

tags:

views:

answers:

How can I "Go Back" without using Response.Redirect

related questions