Is it possible to use javascript:location.reload(true) as a action= for a form without having the browser say "In order to reload this page, information must be resent" or something similar to that? Form action is currently being handled by onsubmit= instead.
Reload will always ask the question about information being resent if the user came from POSTing data. It's hard to answer anything specific as I don't know what you are trying to do. This is something that is in the browser's history and can't be prevented.
A better solution is to use the PRG pattern.
http://en.wikipedia.org/wiki/Post/Redirect/Get
If you just want to reload the page without submitting the form try window.location=window.location;
It seems you are handling your form with an AJAX request in the onsubmit event, which begs the question why since nothing is gained if you have to refresh the page anyway. I would suggest either using a normal post from the form, or use #Bob 's solution (which he saved me from typing by posting first). If you use window.location=window.location be sure to call it after whatever happens in your onsubmit method has completed or you may introduce a race condition where it redirects before your onsubmit method has finished sending the data.
Edit:
Just read your comment that provided more information. Again, reloading the whole page in response to an AJAX submit completely defeats the purpose of using AJAX. You really should consider using a Javascript Library like jQuery to help you with this. Basically the pattern would be as follows:
Handle submit with AJAX
When request completes, request only the changed portion of the page with AJAX
Replace or Append the content on the page with the response to the second AJAX call
Empty the form so it can be filled in again
Related
thanks for answers, question needed some more code examples to be resolved
You can replace the default submit button behaviour with your own function like this or even just don't use <form> at all and use on click listener on a normal button.
In that function you can then send the data to your backend yourself by using an XmlHttpRequest, example and documentation.
This is a matter of which page you will be directed to and which ejs structure you will use. If you call the same page after the post process, you will call a page that uses that api. This causes the data you previously posted to be sent again. Instead, if you return to the first submitted api url source of the form, you can both re-render the page and prevent the form data from being resubmitted.
If you use this in the same api after post processing, it will cause you to send the data again:
res.render("index.ejs");
try returning to the first page source instead:
res.redirect("/")
I hope it was understandable.
I have 'black-box' type ASP framework, let's say I cannot modify it. But I can add HTML modules to it. I've made HTML module using AJAX for user logon and fetching data. The problem is I need to intercept submit event of the logon form. Then it has to call web service, return token and store it in a cookie before the page reloads.
First I need to stop the page from reloading. So I need to unbind events which cause the reload. But how? I don't have access to code which bound the events. It's not mine.
I was able to attach my own event handlers to submit button, login and password fields. They do their job - they start the AJAX request which should perform my logon procedure. Well, at least they try, because almost always my AJAX call is killed before it can finish, the page reloads, and my module has no token it should have by then. 1 in about 20 calls - it succeeds, so it looks like possible to do.
If there was a way to prevent page from reloading until the AJAX callback completes, it would probably be enough for it to work.
Is there absolutely no way of killing events which I din't bind in my code?
Well, I've found the way to achieve the goal without actually unbinding any events.
I needed to replace the form action attribute with '#', the same with special submit link href ('#'), and... DONE! After my AJAX call completes (or fails), it restores original hrefs and submits the naughty form.
So the question I asked was wrong - my fault. I needed to prevent a form from being submited and this is way easier than removing alien events!
TL;DR - kill hrefs first, then restore them :)
In all of the sample code I have seen, it appears that the only function of onbeforeunload is to serve up an alert dialog box prior to the person leaving the page. Is that the only thing that can be triggered by the event or is it possible to do something else, like an unobtrusive function that sends off partial form data?
I am trying to capture abandoned shopping carts in Yahoo! Small Business and unfortunately I do not have access to any server side scripting, so I'm forced to work client-side only.
I was also thinking of doing an ajax posting of data after the email field was changed, and then comparing the list of all forms partially submitted against completed carts to determine which were incomplete.
You can save the partial form data in localStorage. Then, when another page is loaded, you could check for the presence of that data and AJAX it to the server, deleting it from localStorage on success. Or you might be able to just use that data in JavaScript, without involving the server, but that depends on your setup.
<body onbeforeunload="return ('You will lose all your data')" onunload="alert('You have gone away!')">
</body>
Onbeforeunload uses for alert box. Onunload for anything else.
You can technically fire off an ajax event, but there is no guarantee that it will complete before the page is actually reloaded.
Is there a difference between me using Javascript to redirect to URL + "?Querystring=value" versus using whatever mechanism ASP.NET uses?
If there is a difference, how can I make the rendered ASP.NET page be submitted to the same URL with a different query string by javascript?
If you want to do a post back just like a asp control like a asp:Button you can use the javascript functions included by the framework to do so:
__doPostBack('ControlIDOfEventYouWantToRaise','');
You can read more about the __doPostBack in this article:
Doing or Raising Postback using __doPostBack() function from Javascript in Asp.Net
Just doing a form.submit() will not be exactly the same as using __doPostBack.
To answer the first part of your question there is no difference doing a redirect if you are just doing a Response.Redirect as the will both do a GET. The difference is if you use a asp:Button control for instance, it will access your page first to handle the button (a post back) and then do a GET on the redirected page.
If you want to submit to the same URL (eg post your data) then you should use the __doPostBack method. If you don't require the data to be posted, then just do a redirect in javascript to the same URL with a modified query string (which will just do a basic GET) but your data will not be posted.
The only potential difference is that a querystring parameter is sent via GET, a form is (usually) sent by POST.
GET has a much smaller data limit as browsers have a max URL length (it varies)
You could use javascript to do a form.submit() which shoul emulate what ASP.Net does
I somewhat disagree with Basiclife's answer; if you have any code inside something like
if (IsPostBack) {
it's not going to be equivalent, ie the code is going to be executed if you're just setting the URL. Also, controls keep their state across postbacks but are freshly initialized if you're calling the URL again. This is due to ASP.NET trying to emulate a "normal" application, so the way to make sure a normal call and a postback have the same effect might result in "de-ASP.NET-ing" the entire page.
I'm not sure if what you want works. There probably is a way. But I heavily suspect there's a better way of doing this. If you get a postback for free, and can transmit data, why is it crucial that the data shows up in the URL, instead of being comfortably posted? I can see how you want a page to respond to a URL parameter, and how you might want to change the same parameter later on based on what's happening on that page, but since you always know you're posting back, you can eg override that URL parameter in that case, by something you're posting back. This doesn't sound so nice, but it might actually be less messy. Particularly since you seem to have a reason to not abandon the postback at all (otherwise you could just use a link, right?).
First off, let me say that I know this does not seem like an uncommon issue. I do not intend to clutter these forums with questions that have already been answered, but, I have worked through probably about 3 dozen threads with similar issues and have been unable to reach a solution.
The short description of my issue is this: I am trying to redirect after submitting a form using php's header(location:) function, and it's not redirecting. It is a little bit complicated because the form is submitted via AJAX. The steps my code goes through are as follows:
User submits form > form data sent via AJAX > form processing page validates data > if valid, form processing page inserts data into database > if submission is successful, form processing page adds redirect URL to $_SESSION > form processing page returns a 'redirect' variable > javascript/AJAX checks for redirect variable, and refreshes page if found > page header checks $_SESSION for redirect URL, and if found, sets appropriate headers and exits.
I guess the first thing I want to ask is, is this the right way of going about this? It seems to me that there should be a simpler way of doing this. It's obviously much simpler to pass the redirect URL to the javascript and do a window.location redirect, but I read that it's much better/more secure to handle that on the server side, so I'm trying to do that.
Assuming I'm going about this in the right direction, what could be going wrong here? I've checked for leading and trailing whitespace, BOM characters, I've even tried output buffering and I still have the same issue.
What happens on form submission is, the page refreshes, but it returns to the original form page rather than the redirect url. I have turned on the most detailed error reporting and get no errors at all.
One thing that may or may not be of interest, I have an error_log function set up to log all headers to a file right after I set the Location: header. When I redirect outside of AJAX (which works), the accept: header is set to html, but when I try to do it via AJAX, the accept header is set to JSON. Could that cause a problem?
Thank you so much for taking the time, and again, apologies if this is a dumb question. I have used this forum for years and have never once had to post a question on it because it has always solved my problems until now. Thanks in advance!
PHP is too generous to include in your code not only HTML code, but also JavaScript code. I'll explain one thing. When you send data by ajax, it is often difficult return Boolean data (whether true or false, depending on the conditions we work side server with php in some file established in our direction ajax) to give a final answer.
On the other hand, returning to the generosity of PHP, always when we try to validate data server-side and through ajax, we can manipulate the section where work freely to show some response message, a redirect to somewhere on your page or create a session. Anyway, whatever.
What I mean is that in your controller section where you will work with AJAX, you can set different conditions. That is, if the user data are correct, then you could send to call a script from Javascript to redirect him with a location.reload (); and also assign a session automatically. If the user does not have the correct data, then what we should do is return a warning message or alert to the exit AJAX, usually it goes after a:
function (response) {
$ ('.answer').html(response);
}
Note that it is not necessary require, for example, a $ ('.answer').html(response); to return an answer, because ajax only sends data to the server and if there is a reply message well, and if not well. Many times what I do, is to send messages via console, although it is often convenient to do so, because as often work with several conditions and that depends on the result of our request, we will be forced to show some response in some element within our code.
What I advise you is that you work javascript in PHP, and hence redirect to other pages, assign sessions or simply return a message. Remember that an ajax request is not only asynchronous, but repetitive and can send it to call as often as you need. The fact that you sent your ajax call php file and you have returned an answer, does not mean you can go back to work with it once you finish your ajax request.
It is the right way to do what you want, it is often easier to manipulate our server-side code that client side. Greetings.