I know, localStorage supports up to 5MB only. In our application we are planning use localStorage (sessionStorage doesn't fits for our need, since we support multiple tabs). Currently there is only one big javascript object serialized and stored in localStorage, in the future it may exceed up to 15 objects but definitely not more than that.
The problem is, clearing the localStorage. Since our application allows user to login in multiple ways (SSO etc...). So without landing in Login page, they can login into our application and as well as signing off in other application will sign off in our application too or close the browser. For security reason, we need to clean the localStorage once the user session is over.
So we planned to store the personId in localStorage, in every page request along with the html response we send the personId from the server, and if it doesn't match with the localStorage's personId then it will clear the localStorage.
My doubt here is, search in localStorage is not asynchronous so will it take much time to search personId out of 15 keys (Which has some large string as value)?
localStorage.setItem("personId", 1234);
localStorage.setItem("object1", "A very big serialized form of javascript object gets stored");
Writing values is really fast and there is no significant difference between large and short values: http://jsperf.com/local-storage-set
You can test the search on this site too... You could share the search code too, so others can take a look on it.
Related
I have an ASP.net MVC application with a "Wallboard" screen. The problem is that this particular page takes a long time to load (it has to cycle through a bunch of databases and calculate several numbers to be displayed).
When I clicked on the "Wallboard" menu item, the browser wheel would spin for ~30 seconds before bringing up the page. I know this is very obnoxious for users, so I decided to store the previous values of the strings being displayed (last time the page was loaded) in a cookie and instantly load the page with those strings while an AJAX call retrieved newer values.
The page indicates that it's retrieving newer values, but these values don't change that often, so it's useful for the user to be able to see older values right away.
It's working but my question is, are cookies the best way to store this data? The server doesn't really care at all what values are stored, just that the page instantly loads instead of hanging. If the page has never been loaded then the wallboard is blank until the AJAX call completes.
No, it is likely not a good idea, unless it is very small amount of data.
I more appropriate solution would be to use the Caching
For example, this will cache the database data for 30 minutes, at which point the cache will expire, so any one who access the page will get a cached version and that will speed up your web site dramatically.
Cache.Insert("key", "database-data", null, DateTime.Now.AddMinutes(30), TimeSpan.Zero);
Cookies are not the right way to store large amounts of data on the client side as they are transferred to the server with every request.
I recommend you to take a look at the Local Storage API.
If you need to store a significant amount of data and require common database features, take a look at
IndexedDB.
I wrote an application for my friend who works in a car showroom. He wanted some sort of program to keep track of the cars coming in and out with their details and stuff using tables like excel so I did just that using JavaScript.
The thing is everytime you close or refresh the browser all of the tables inserted are gone obviously. What do I do and what do I use to make everything stay the same whenever he reopens the application locally?
Is it cookies or HTML5 application cache or what exactly I've looked everywhere and haven't found an answer. I don't have any server or database which I can use.
You can use any of the following:
PouchDB
LocalStorage API (no polyfills)
IndexDB + Localstorage: localForage
Hood.ie
jQuery Store
store.js
There are so many other ways to store data (cookies, WebSQL, etc.) that it's really a matter of preference; each method has its advantages and disadvantages. For example, if you're storing only small amounts of data and need cross-browser compatibility, cookies are probably the best option; conversely, if you are storing large amounts of data, such that you may exceed the 20MB limit, then IndexDB or one of the polyfill libraries above will be a good fit (note that most of them avoid the 20MB limit through clever "hacks").
You can use the localStorage object.
The localStorage object stores the data with no expiration date. The data will not be deleted when the browser is closed, and will be available the next day, week, or year.
// Store
localStorage.setItem("lastname", "Smith");
// Retrieve
var userLastName = localStorage.getItem("lastname");
When is it appropriate to use the many different ways that modern day AJAX based applications are storing data? I'm hoping for some specific guidelines that I can give developers. Here's what I'm seeing so far, and it's getting messy.
PHP Server Side Session: PHP Session data is probably the oldest way to store session based information. I'm often passing in parameters through various AJAX calls from JavaScript/jQuery objects - to store in PHP Session. I'm also returning objects of data (some session information) back through as a response/result to JavaScript/jQuery methods.
Browser based Local Storage: This is often used to store data that needs to persist on the front end, yet I'm uncertain at times when to use it. One good use was to store geolocation information from navigator.geolocation. I've been storing a lot of information here, but I am not certain that is wise. It never seems to expire, but can be deleted from Resources.
JavaScript Object with config parameter(s): I've been building JavaScipts objects with an init method that sets-up a 'settings' parameter. This is very useful as I usually build it from data passed in from PHP. With jQuery Mobile this data can even persist from page to page and change with AJAX request responses.
So, what guidelines would you give on usage of each?
PHP Session data is NOT Permanent Data storage as when you destroy the browsers session you will loose the Data. This is useful if you dont
want to permanently store data.
Browsers Local Storage is Permanent unless you delete the data yourself or you clear the browsers cache. Some users clear the cache from time to time so this can be a problem.
Any other method Such as Objects is not permanent Data storage.
Other Browser related Permanent storage are COOKIES (if you don't
expire them at session close), IndexedDb (Check here for current browser support http://caniuse.com/#feat=indexeddb).
So depending on your Website or App you need to decide what data needs to be
stored for a short time, or for long time or forever until you deleted it manually.
As an example, you will use LocalStorage if you were storing
Bookmarks, and if you were Storing Geolocation points you use Cookies
and expire them after you close the browser or the App.
If you were Logging in to an Account using PHP then best practice is to create a PHP
Session, and even change the session timeout when the user clicks
(Remember me).
These are just a couple of examples from thousands of possible needs.
I'm working on a web based form builder that uses a mix of Jquery and PHP server side interaction. While the user is building the form I'm trying to determine the best method to store each of one of the form items before all the data is sent to the server. I've looked at the following methods
Javascript arrays
XML document
Send each form item to the server side to be stored in a session
The good, the bad and the ugly
Depends on your application functionality and requirements, but Javascript would probably be the best way. You can use either arrays or objects or whatever in javascript. It's server independent and it will preserve data over a long period of time as long as client session stays present (browser window doesn't close for whatever reason) but this can be quite easily avoided (check my last paragraph).
Using XML documents would be the worst solution because XML is not as well supported on the client side as you might think.
Server side sessions are good and bad. They are fine if you store intermediate results from time to time, so if client session ends because of whatever reason, user doesn't loose all data. But the problem is that it may as well expire on the server.
If I was you, I'd use Javascript storage and if needed occasionally send JSON serialized results to server and persist them there as well (based on business process storig this data somewhere else than session could be a better solution). I'd do the second part (with sever side combination) only if I would know that user will most probably build forms in multiple stages over a longer period of time and multiple client sessions. but can be used for failure preventions as well. Anyway. Javascript is your best bet with possible server-side interaction.
Preserving data between pages on the client
Be aware that it's also possible to preseve data between pages on the client side. Check sessvars library for this. So even if the page gets refreshed or redirected and then returned all this can be stored on the client side between these events like magic. Marvelous any rather tiny library that made my life several times. And lessened application complexity considerably that would otherwise have to be implemented with something more complex.
I used TaffyDB to store data, and it's just wonderfully easy to implement.
Hope this helps you
You may want to check out PersistJS, which exposes a cross-browser persistent storage object. Of course, being persistent, data stored with this library survives sessions, not just page changes.
The latest version (0.2.0) is here – note the version in the above linked post is 0.1.0.
A combination of #1 (although I'd use objects, not arrays necessarily) and #3 would seem like a good approach. Storing the data locally in the browser (#1) makes it immediately accessible. Backing that up with session-based server-side storage defends you from the page being refreshed; you can magically restore the page just as it was.
For my web application, I need to store form inputs spanning across multiple pages, until I finally process/manipulate them to produce some results (its mostly formatting the data entered and presenting it in some layout). The options I think I have are -
Keep sending user's inputs to the server, store it there in some database, do the final manipulation there only, and show the result.
Store the inputs in browser's storage as the user fills the forms, and finally use this stored data to manipulate and show results.
I very much want to use the second method, and perhaps a possible way is using cookies, but I'm afraid I might just hit some upper limit of cookie data storage. I'm also open to understanding the merits of the first method, or any third method.
thanks.
Use webstorage (you can client-side store around 5MB of text or binary data)
Firefox demo: http://codebase.es/test/webstorage.html
DOM Storage is supported in these web browsers:
Internet Explorer 8
Firefox 2 for sessionStorage, 3.5 for localStorage
Safari 4
Just google for sessionStorage and localStorage objects.
Also modern webkit browsers supports client-side sql.
Edit:
I'm not sure about what you want to do but using AJAX you can store everything in javascript variables and serverside databases or sessions are a good choice.
Hitting the storage limit of the cookie could indicate you are trying to store too much on the client side. It might be prudent to store it serverside, in something like a session. The key to the session could then be stored in a cookie.
An alternative method is to not have the requests span multiple pages, and just store the data on the client side, not as a cookie, but as different form fields and/or text fields (they could be hidden). The merit of such a method is it doesnt hit the cookie limit as you have. It also makes your serverside code easier/cleaner, since it doesn't have to keep track of state (something you'd always have to do if spanning across pages, and thus the reason you are hitting the cookie limit in the first place).
You could use a small Flash Movie to store some data via Flash's Shared Memory Api or have a look at Google Gears.
Maybe also consider, that every byte you store in the cookie have to be transmitted everytime you website makes a request to the server.
Generally cookies have a max size of 4k so you could store quite a bit of data in there.
Be careful with validating all information that lives cookies - all the information resides on a client browser and can easily be manipulated by users of the site at any time.
You didn't say which platform you use. Spring Webflow does exactly the kind of form processing that you want:
http://www.springsource.org/webflow
Even if you don't use Java you could use some of the principles.
Edit: One more drawback of big/complex persistent cookies is that you have to make sure that any new code you deploy is backwards compatible with all the cookies that are out in the wild.
I would suggest storing the data in a session variable until you get to the final step rather than a cookie. I think this would be safer for your data as the user does not have direct access to the data, so you can validate as you go.