I have an HTML page which when loaded triggers some AJAX calls, results of those calls are either stored in hidden text-area (mainly for JSON output) or into div (for ajax calls returning HTML content).
What I'm trying to do is to avoid having to make those AJAX calls when leaving the page and then using the back button.
This actually works for the AJAX output stored in text-area, where in fact after a back data is still stored in those fields without having to re-call those AJAX requests, but for what is directly outputted in a DIV it is not the case, meaning that the request will have to be re-called.
What advice can you give me for managing this?
Thanks
This actually works for the AJAX output stored in text-area, where in fact after a back data is still stored in those fields without having to re-call those AJAX requests, but for what is directly outputted in a DIV it is not the case, meaning that the request will have to be re-called.
Browsers "cache" content of form fields under certain conditions; but they won't "cache" dynamically added HTML elements.
What advice can you give me for managing this?
With an appropriate caching policy making the AJAX request a second time should not be too costly - the browser will figure that he already has this resource in his cache, and it should be available almost immediately, without any delays caused by an extra HTTP request.
Related
I have a view set up to work with datatables; it accepts the data posted by datatables in JSON format, so I use:
json.loads(request.body.decode('utf-8'))
to grab the data I need to search, sort, and paginate my tables via ajax. All of this works, but I'm worried that loading the body of the request in this way could leave me open to attacks, especially since I could be loading arbitrary data in that line.
What can/should I do to make sure this doesn't leave the code open to exploitation?
Note: I am using csrf tokens in each request. I'm worried more about direct attacks from a malicious user of the system.
Lets assume I want to design a web page with stock ticker. I need my webpage to continuously as for fresh updates for stocks. How to do it ?
From my limited knowledge, AJAX wont be of much help.
What I am looking for is what sort of 'poller' can be used ?
What makes you think AJAX is inappropriate?
You can write a function that dispatches an XMLHttpRequest GET request to the relevant endpoint (let's call it /stocks), and sends the ID of the most recent datum as a query string parameter (e.g., /stocks?later_than={id}).
Your server-side code can return all data later than the ID'd datum.
You can use window.setInterval to call that function at a regular interval, or renew the request in a callback executed when the previous request receives a response.
It sounds like you might be asking about WebSockets. Here is a StackOverflow discussion of the relative merits of AJAX and WebSockets.
Here is another great StackOverflow resource covering different approaches to polling.
Ajax could be a easy and working solution. Only need to make multiple Ajax call to check for stock change.
Design your page with a div container inside. Create a javascript function which will get the stocks via AJAX, display them on the container, wait i.e. one minute and make this function call itself.
Only need to launch this beautiful function when the page load.
Title question asks it all, what's the process going on under there? Why do I have to use AJAX if I wanted to submit that form asynchrously?
It's due to the way HTTP was designed. Back then, JavaScript was not as ubiquitous and not as powerful as it is today.
As it is, when you POST data to a page (a path), you are issuing a request to a server. The server can then respond in a variety of manners. There is the simple "return some content", whether it be HTML, text, JSON, XML, etc. There is also the possibility for the server to return a redirect, sending you to a different location.
What AJAX does is simply to run this request in the background and hide the fact that data was submitted to the server and a response was returned from the user's perspective.
I have the HTML template resource "steg3rad.html" stored in my appcache manifest. In my javascript file I fetch the template file using an jQuery AJAX GET request. Sometimes jQuery adds a callback parameter to the GET request. This results in Chrome not managing to load the resource from the appcache, see screenshot below. This causes errors in my pages.
Why can Chrome/the appcache not handle the parameters?
It looks like the Ajax cache option is set to false.
I think the whole point with the callback parameter we see in the screenshot is to make each call unique, and there is little point in caching something that is always unique. (Read more about the cache option in the Ajax API documentation.)
So, essentially you're telling the browser to cache something in one place (the appcache manifest) and you're telling it to not cache that same thing in another place (the ajax request). Maybe you get the behavior you want if you remove the ambiguity by setting the Ajax cache option to true?
I've done several forms that follow a similar pattern:
two interdependent form fields, let's say "street address" and "location" (lon/lat).
when user fills in one field, the other is updated via an ajax call.
(eg. if the user fills in street address, do a request to a geocode API and put the result in the location field; if the user fills in the location (eg. via a map UI), do a request to a reverse-geocode API and put the result in the address field.
No problem so far, these are easy to hook up to blur and/or focus change events.)
The problem occurs if the form is submitted before an ajax call completes. In this case one field will have a correct value and the other will be stale. The handler on the server needs to detect that this has happened and update the stale value. We can't just check for the default value because the user might have changed both fields any number of times.
There are two possible solutions I've thought of, and I don't much like either one. I'd love other suggestions.
Solution 1. Use hidden fields as flags to indicate freshness: set the value to 0 by default, reset it to 0 before the ajax request is sent, and set it to 1 when the response comes back. On the server side, check these fields and recompute any field whose freshness flag is set to 0. There is still a potential race condition here but the window is greatly narrowed. I've used this technique and it works (eg. http://fixcity.org/racks/new/). It is annoying though, as it requires more code on both client and server and is another possible source of bugs.
Solution 2. Use synchronous AJAX calls instead ("SJAX"?). Not appealing since AJAX here is just a UI convenience, it's not strictly necessary for the application to work, so I'd rather not make things feel slow - then it becomes UI *in*convenience.
Solution 3. Always do server-side postprocessing. If it's expensive, use caching to make it cheaper - eg. if the value is not stale, that means the client just made the same request via AJAX so we should have populated the cache if needed during the AJAX handler.
This one currently seems the most appealing to me, although it has two limitations:
it can't be used for things that are not safe and idempotent - eg. if the AJAX request was doing a POST; and it can't even be used for this example because we have two interdependent fields and no way to know which is correct and which is stale.
When the user presses submit, have it run a validation function that decides what state the form is in by examining the form fields and the state of the ajax call (set a flag, such as ajaxBusy).
You could enhance your AJAX call to both disable the form submit button and set a global var to to true that is checked on form submit~ That way the user can't submit the form before AJAX completes. I would add a loading graphic for UI sake.
You should validate what is submitted on server-side anyway. If both fields are related 1-1, then you can designate one of them as "master", and submit it alone, while the other one is calculated server-side.