At first i am not sure if using cookies is the right way.
What i basically need is a variable that i store from one page , and then to use it on another page.
If it can be done without cookies then its great , if not then i will just have to do it with cookies.
For setting cookies within JavaScript have a look at here.
Remember, that the data you store in cookies is transmitted with every request for that page or domain. So if you want to store larger amounts of data, maybe local storage is more suitable.
Related
My idea is to reduce the number of requests to the server from the web client. Say, a view/component that shows user data (first retrieved before this view/component is rendered), if the user reloads the page (F5) then the whole application is reloaded and initialized again, so another request to the server to get that data again, is there any way to maintain or "caching" that state locally?.
I don't know how to implement this.
you can try redux presist link : https://github.com/rt2zz/redux-persist
or you can use localstorage : https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
Like others have said, local storage is probably your best bet, but I don't think it's a very good idea. If the users reloads the page, that's essentially a blank slate for your app. You could get the data from local storage but how do you know it's still up to date? You'd need to check with the server anyway.
You should definitely look into a redux/store solution where you can store data for use while the user is using your app, so you can share data between components and don't have to fetch the same data every time. But actually storing it locally just reeks of bad practice, IMO.
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.
Ok, Here is what I want to do. I have a very complex database. I am reading from the database using php and store the data in a variable (Ajax). Now when I go to another page I loose the variable.
Here is what I know (not sure how correct I am): the scope of a variable is the function it is in. If not specified the scope will be the window object (which changes for every page). Is there any higher level than window? (something like session in php but in the client side)
There are many way to storage your variable such as:
Use client cookie
Use server session or cookie
HTML5 storage
Query string such as ?var1=blah&var2=blah
Maybe you can use cookie. Actually php sessions also utilize cookie as well. As far as I know the scope beyong window is cookie.
Or you can use some HTML5 technologies, such as WebStorage, but that may break on some old browsers.
Normally I would avoid storing state in javascript and instead cache the result on the server. Some sort of application or user level cache might be recommended in this case, so that the other page may benefit from the db result. If it's per user then I would look into session. Otherwise it might be better to store it at the application level in some sort of cache
I would like to create a local data and when user access the same page, the local data is retrieved.
There is absolutely no need to send the data to the server.
Will cookie be able to achieve that?
Thanks.
A cookie will be sent to the server with every request. If you don't mind that, then cookies are fine. If you'd rather avoid that, you'll need to look into localStorage.
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.