I'm using jQuery with a Rails 3 backend and I have the following scenario:
User see's a comment on their post and wants to delete it
User clicks the delete button and deletes the comment from the database
jQuery uses remove() to remove the item from the DOM as an AJAX success response to step 2 above
User navigates to a different page
User hits the back button to go back to the page with the comment
The old comment is still there, even though it was removed from the server and from the DOM
The comment in this scenario is obviously being cached by the browser and so it shows up even though it was previously deleted (and it doesn't exist on the server either).
How do you prevent the comment (or prior cached objects that have been removed from the DOM) from showing up when the user hits the back button?
By the way: Please don't say, "don't cache any pages" :) That is not an option.
if you are using rails page cache then you should clear it on Create, Update and Delete actions. see link for more details
Answer One: If a user is uses a back button, they shouldn't be surprised when they see things from their past.
Answer Two: It's a little heavy handed, but you could try an ajax call in $(document).ready() that checks for outdated content. I'm not certain that would work. If not, you could set up an interval the ping to server to double check there's no outdated content on the screen. (I've had good performance with pings as frequent as 7 seconds)
I don't think there is a non-heavy handed way to do this (other than preventing caching ;)
I don't know whenever it depends on browser, and it may break your RESTful routes, but what you can do, is issue a PUT/POST to the same URL the post originated from, and in the AJAX response disable caching (using the Cache-Control header). It should invalidate this URL in the browser's cache, as browsers usually don't discriminate using HTTP verbs.
Related
I am currently using jQuery's AJAX to send and receive data when making a new post. However, when I open two browser tabs of the same website, I notice that the second tabs doesn't update itself after I do something with the first tab.
For example, if I "like" some posts in the first tab, the posts in the first tab will update its "post number" after receiving data from server via AJAX, but the second tab still stays the same as if nothing happens, unless I refresh the second tab.
I understand that one of the method is by using HTML5's WebSocket. I am just curious if it's possible update all the browser views simultaneously with jQuery's AJAX?
No there is no way to update second browser tab based on action in first tab. But for listening changes from server you should make use of WebSockets to establish connection with server and server will push changes on your connection. Websocket is supported in html5 version. other way to do it old way which is long polling where you keep calling server to get updates & hidden frame approach also (you can get more detail on this by googling it). apart form there are other methods also to do this stuff.
I suggest make use of SignalR which is provided by Microsoft, it includes all the way to handle requirement of Server to multiple clients. you can check here : Introduction to SignalR
I have a happy javascript based client that talks to my Django server-side code. I use several XMLHttpRequests for interactions and everything is fine there. Now there is one user interaction where I'd like to receive user-sent info at the server, but I don't need/want a response.
As I understand Django all views MUST respond with an HttpResponse item. I can send back a blank one, or a HttpResponseNotModified response. But anything I receive back seems to prompt the browser side to change to a blank screen.
I don't want to change pages, reload or anything. Just leave the browser session alone. I don't need a confirmation, and don't mind if some of the POST sends are even lost among a large population of responses.
I COULD do an XMLHttpResponse and catch the response and ignore it. But I'm wondering if there is any way around that.
You should return a Http204/No Content, which tells the browser that your server acknowledged and processed your request but it didn't return anything and handle that appropriately in your application (however you want to).
If you're using jQuery (for example), then this will automatically go to your success handler, and if you have no control over that, you've done the best you could.
Read the full list of status codes here
I am writing a web application which retrieves a lot of data using AJAX which substantially modifies the loaded page depending on what button the user clicked (Let's say that clicking on button1 takes the page from state0 to state1 and so on..)
Further, if the button number is passed to the server as a GET variable, the server returns the page in the correct state.
Needless to say, the back / forward browser buttons do not work because the URL is not changed during state changes accomplished through AJAX.
So, my question is, how can I make the browser back / forward buttons work?
Is it possible to supply the browser with the correct URL every time the state changes; but stop the page from reloading?
Please note that this question is only about browser back / forward buttons. I can create custom back / forward buttons but that is not what I want to do.
Take some time to go through some. of. the. previous. questions. on. this. topic.
Hint: use the hash man! (window.location.hash that is)
You will have to use # capabilities of your URL to store your intermediate Ajax requests in browser history. If you use any Javascript library there will probably be a solution in the library itself or in a form of a community extension/plugin.
For instance there's a plugin for jQuery here.
Google for browser history ajax
We have a POST to a PL/SQL database procedure that (a) does some database operations based on the POST parameters and (b) redirects the user to a page showing the results.
The problem is, when the user does a browser "refresh" of the results page, that still has the original request, so it calls the database procedure and resends the parameters.
There are things we can do with saving state so bad things don't happen if the request gets sent in again. But that got me wondering.
Is there a way to tell the browser to set the url to the redirect call, not the original user request? This would probably be in either the redirect itself, or in Javascript on the target page.
You don't mention what you are using to serve the page, but make sure you perform an EXTERNAL redirect. Some platforms will internally redirect within a site.
For instance, with Apache HTTP Server, you need to specify the force-redirect flag in mod_rewrite: http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html#RewriteRule
The 4th response here has a decent explanation of this as well.
The canonical solution is described pretty well on Wikipedia. See Post/Redirect/Get. You want the code that's handling the POST to redirect to a GET when it's work is done, as refreshing a GET will not resubmit form data.
I have an ExtJS grid on a web page and I'd like to save some of its state information back to the server when the users leaves the page.
Can I do this with an Ajax request onUnload?
If not, what's a better solution?
You can use an Ajax request, but be sure to make it a synchronous request rather than an asychronous one. Alternatively, simply save state whenever the user makes a change, this also protects the data if the user's browser crashes.
There's an answer above that says to use a synchronous ajax call, and that is the best case scenario. The problem is that unload doesn't work everywhere. If you look here you'll find some tricks to help you get unload events in safari... You could also use Google Gears to save content user side for situations where the user will be coming back, but the only fully safe way to keep that information is to continuously send it as long as the user is on the page or making changes.
You could also set a cookie using javascript on unload. I think the advantage ajax has over cookies is that you have the data available to you for reporting and the user (if logged in) can utilise the data across different machines.
The disadvantage of using ajax is that it might slow down the actual closing of the browser window, which could be annoying if the server is slow to respond.
It depends on how the user leaves the page.
If there is a 'logoff' button in your GUI, you can trigger an ajax request when the user clicks on this button.
Otherwise I do not think it is a good idea to make a request in the onUnload. As said earlier you would have to make a synchronous request...
An alternative to the cookie solution would be an hidden text field. This is a technique usually used by tools such as RSH that deal with history issues that come with ajax.