I have an ASP.NET form that the user can make lots of changes to, each time they make a change the page PostsBack and the details are updated.
If the user hits the browser back button they go back through all the previous versions of the page.
Is it possible to stop each PostBack being treated by the browser as a new page?
So the would make any changes they like and if they hit the back button it brings them to the previous form and not the same form but a different version?
I know I could use AJAX to update values but I'm not an advanced coder so trying to keep things simple as I haven't used AJAX before.
Ajax is your only solution.
There is no way to remove a page from the browser history. Javascript is explicitly denied the capability.
Now, you could, potentially, stop them from using the back button at all. Although this might result in unhappy users and I'm not 100% certain it works in all browsers.
function body_onload(){
window.history.forward(1);
}
You could use a trick to do it.
On postback you can set a session bit to true saying they submitted that form. On your postback check to see if that value is set. If it is they are trying to do it again and you can just abort it. It wouldn't prevent the postback per se but you could control the logic and prevent it from DOING anything.
I personally would explore ajax as Jquery provides some nice ways to do it and it'd be a learning experience but I suppose this would work as you are asking. On a per session basis. If you only want 1 submission ever use a database to store the activity.
You could use UpdatePanel: http://msdn.microsoft.com/en-us/library/bb386454.aspx
Related
I'm building a website in jquery mobile. It is a SOA application and on 'pageshow' event I call the web services get the data and populate labels and dropdown lists with it. However, say for instance, when a user clicks back and the app takes him back to dashboard, the ajax call is made again and the labels are unnecessarily populated again. What I want to ask is, can I prevent this behaviour of populating the same labels with the same data over and over again? Does jquery mobile have this 'viewstate' behavior built in?
Thank you for taking the time to answer my question.
You could use HTML5's localStorage / sessionStorage API to actually persist data between callbacks.
Personally I think that if you'd use JQM's page idiom (having only data-role=page and not loading any new ajax pages), you wouldn't have this problem at all (but rather the opposite, how to reset all fields).
I am using a ScriptManager control to load search results from server web services. There is a text box and button on the page where the user enters their search terms. When they submit their search there is a Response.Redirect that is called to the search page. I use the ScriptManager's history function to track filtering that the users can do. If you are familiar with this function the URL ends up looking something like this:
http://somesite/search.aspx?q=giant+dog#color=red&hair=long
My problem is that if the users deices to do another search with the text box and button on the search.aspx page, which causes a response.redirect, the query string changes but the hash history stay a part of the URL. This does not make sense to me because from what I understand of the Response.Redirect("someURL") it should act like it is sending you to a new page regardless if it is going to the same page it left.
I know I can set window.location.hash = "#" but I was hoping there was a cleaner way than that on the server side.
Please help! :-)
This is an old post, but I thought that I would add the solution in case anybody else was looking for this. I ran into the same problem, where the history point was being maintained across post backs to the server when a Response.Redirect() call was made. I'm not sure why this is happening and it seems counter-intuitive to me. But I believe the ScriptManager is doing something to carry the history point over.
The answer is to put your control that's issuing the Response.Redirect() call in an UpdatePanel. So, in my case, I have a button that has an event handler where a redirect is being issued. Without the UpdatePanel, the history point is preserved. With the UpdatePanel wrapping the button, all works as expected.
You can invoke AddHistoryPoint method of the ScriptManager, before Redirect.
Is there any pattern or kind of "least requirements list" to follow for ensuring an asp.NET application to support BACK button of the browser for each aspx page?
thanks
In general, the back button on the browser will take you to the previous HTML GET or POST that occurred. It navigates by page-wide transactions, so anything done dynamically cannot be navigated that way. Also, the back button doesn't rewind code execution, so if you are determining something based off of a Session variable or something similar, that won't be rewound either. Obviously, it won't rewind database transactions either.
In general, if you want to support the back button, you'll need to make sure to divide everything you need to navigate between with said button is divided by an HTML transaction of some sort.
Again, you're going to run into issues if your page display is dependent on server-side control that changes from one post to the next. This is one reason you see some forms feed a 'Page has expired' error when you try to navigate back to them.
Not really... It depends on your application flow.
There are things that make supporting the back button more awkward.
for example using pure ajax to change the majority of the content on the page,
will look like a 'new' page but wont be compatible with the back button (though you can fudge it)
another example is posting back to the same page more than once, as this can make it appear like the back button is not working, and at the same time re-doing your request (and therefore database transactions)
Fundamentally it depends on your application requirements.
How can I perform a redirect with Server.Transfer() to the same page that is currently shown?
I want to have A cleared form after submit.
What other/better methods can I use to achieve the same?
Why Server.Transfer? Response.Redirect(Request.RawUrl) would get you what you need.
http://en.wikipedia.org/wiki/Post/Redirect/Get
The most common way to implement this pattern in ASP.Net is to use Response.Redirect(Request.RawUrl)
Consider the differences between Redirect and Transfer. Transfer really isn't telling the browser to forward to a clear form, it's simply returning a cleared form. That may or may not be what you want.
Response.Redirect() does not a waste round trip. If you post to a script that clears the form by Server.Transfer() and reload you will be asked to repost by most browsers since the last action was a HTTP POST. This may cause your users to unintentionally repeat some action, eg. place a second order which will have to be voided later.
I have a page with a few fields and a runtime-generated image on it. The contents of this page are inside an UpdatePanel. There is a button to take the user to a secondary page, which has a button that calls javascript:history.go(-1) when clicked.
The problem is, the first page does a full request instead of a postback or just using the state it was in before navigating away from it. That is, the fields are all reset to their default values, thereby confusing the user. I'd like their values to be retained regardless of navigation. I do not want to create a new history state for every field change.
Any ideas?
The only other option would be to track the field state in a client side cookie using JavaScript (which has limitations). It would be best to have an AJAX call that was executed prior to navigation to your secondary page that would allow the server to save the state of the page so that when your reverse navigation occurred you could properly render that state to the browser.
I think I'll try the AJAX idea when I have a little more time to work on it. I'll probably just send back the viewstate field :P Thanks for the input.