Is it possible for client side to store a local copy of the webpages after a server-side request, without manually saving the webpage (right click + save as...)?
I have multiple clients that displays a loop of webpages coming from the server. Each page have different media files such as images and swfs. As an alternative to the default cache mechanism, I would like for the client side, during the first load of webpages from the server, to store a copy of the webpages to the local of client side. That way I can reduce the requests coming from the clients every tiem the loop loads a web page request.
Whenever there are changes in the content, the server would tell the client side to request for the pages again and overwrite the local copy of the client side.
Well, you could do something like this:
localStorage['this_page'] = document.querySelector('html').innerHTML;
This will, of course, only work in modern browsers that support localStorage. There's no other browser API that will offer a way to store large amounts of data. Cookies are too small. You could use window.name as an alternative, but that's more a hack than anything else.
document.querySelector can, of course, be replaced with document.getElementsByTagName('html')[0], but just use querySelector since its supported everywhere localStorage is.
Related
I have created a django application. There are two different html pages, which run different scripts in each other. I want to share data between the two script files, so while I update the variables in one script, I can send the updated data to the other script file, and make the corresponding changes to the variable present in the other script file.
As I researched, one way I found to do that is to use websockets, where a regular connection is built with the django server and the client. But, it is limited to single client. So, through websockets, I can not share data between two different client pages. What other methods, can I use to share data between the two script files in the client?
Edit 1: The changes in one script file has to be reciprocated instantly or after really less time delay in the second script file.
Edit 2: The clients for the server can be running on different devices(one on phone and other on computer). Thus, having a solution to save data in localstorage doesnt work
Edit 3: I tried making api calls. The instant change in variable happens in one script file, an api call is made that makes change in the database. While, the other script is constantly making api calls at regular intervals to get the value of the variable that is saved. But, this creates a time delay, and therefore, was looking for a websocket like solution, where instead of communication between server and client, we have communication between two different clients operating in the same server
Use built in window.localStorage to store things on the clients browser for the life of the session. See https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage for reference.
I'm using a javascript scripting engine for a MUD i'm playing, they have a javascript client hosted on their server. I'm wanting to store some information in a database and access it from the client (or inject it somehow into the client) but I'm not seeing how I could do that.
Basically I can write javascript files into the trigger section of the website and they fire. It has Javascript and JQuery options. It does not have a database option on their end, which is why I'm trying to add it myself.
I know client side javascript has a lot of restrictions on it, so I'm not sure how far I could really go with this.
I think you might be able to do this, but it's going to be hacky.
If you're able to attach a script node to the dom, you can trigger GET requests with no origin restrictions wherever you want. You would do that to your own backend.
You would have to throw away all good practices and use GET requests with a lot of query params so send data to that (your) backend.
You would have to write the backend so that it does whatever you want with the data, e.g. store it in the db.
You would have to make sure you return valid js to the client, even if it's only to dismiss it.
Alternatively...
you could load an iframe to a site you control, and change the iframe src with the data, and then do with the data whatever you want (like sending it to some bakcend of yours properly) in your site (that's loaded in the iframe) by detecting changes in the url...
I have a flash application that uses a large set (~1.5MB) of data. This data is likely to stay the same for a long time so I would like to use a caching method. The data should stay cached even if the user closes his browser (and restarts his computer).
At the moment, I'm using javascript files that are dynamically created and contain the data that will be transfered to flash later on. The server checks the If Modified since argument and returns a Not Modified if possible.
This method has the drawback that I still have to wait for the request to finish - I would like to rely on the old data while everything is set up and check for a new version later on.
tldr:
Is there a possibility to store data in a local cache (in the browser or my flash application) so that it isn't deleted when the browser is closed and is available without another request to the server?
You can use web storage.
I have stored more than 300 records for the same domain without problems in localStorage.
Here is a good document about web storage http://diveintohtml5.info/storage.html
I have never used it from flash but I found this at github https://github.com/shoito/as3webstorage
When I fetch a page using GET request in javascript, does the browser cache it the same way as it does when I click that link or type it in address bar?
If not, since I have already fetched the page, is there a way that I can add it (programmatically) to the browser cache?
When the browser fetches web pages, it is also using a GET request. Chances are that all GET requests go through the same caching mechanism in the browser, though there is no specification that formalizes how that works.
There is no programmatic way to add something to the browser's own cache other than just requesting the resource and letting the browser's cache do its normal thing with it. If you want to know if all common browsers will cache it in this way, then you need to make sure the server-side header settings are set appropriately (to allow it to be cached) and then test each browser to make sure it's cached like you want.
If you are staying within the same page and want to make sure something is not requested more than once from the same page, you can implement your own cache within that page's javascript code. You just store the result in a javascript variable the first time it is requested and then a function you implement to fetch this resource just checks your own local storage object to see if the resource is already here. If not, it requests it via a GET and then saves the result. You could make a simple version of this that was hardcoded to one particular resource or a more general version that saved the URL and result and a timestamp and implemented more typical caching behaviors.
If you want it to be cached across pages and your testing finds that the built-in browser caches are not adequate, then you can use Local Storage to store the data (probably with a timestamp) and then just check the local storage before requesting it with a GET request.
Imagine that your web application maintains a hit counter for one or multiple pages and that it also aggressively caches those pages for anonymous visitors. This poses the problem that at least the hitcount would be out of date for those visitors because although the hitcounter is accurately maintained on the server even for those visitors, they would see the old cached page for a while.
What if the server would continue to serve them the cached page but would pass the updated counter in a non-persistent http cookie to be read by a piece of javascript in the page that would inject the updated counter into the DOM.
Opinions?
You are never going to keep track of the visitors in this manner. If you are aggressively caching pages, intermediate proxies and browsers are also going to cache your pages. And so the request may not even reach your server for you to track.
The best way to do so would be to use an approach similar to google analytics. When the page is loaded, send an AJAX request to the server. This ajax request would increment the current counter value on the server, and return the latest value. Then the client side could could show the value returned by the server using javascript.
This approach allows you to cache as aggressively as you want without losing the ability to keep track of your visitors.
you can also get the page programmatically via asp or php out the cache yourself and replace the hitcounter.