I have graph with data in welcome page like widget(/welcome). when the user clicks the graph the page change to /home/default and the same graph should be displayed along with some extra data which is populated by Ajax call. What I want is to persist the graph data from /welcome into /home/default page. I don't want the data to go controller and back to the /home/default page. Kindly suggest.
In a nutshell, you need to set some state for the user and then when the /home/default page is rendered, you need to check that state and make corresponding changes to the presentation of the page.
This can be done either server-side (in the rendering of the page) or client-side (via Javascript adding things to the page).
If you do this client-side, then the state can be stored in a cookie, in LocalStorage or in a query parameter in the URL when you redirect. Then, you place Javascript code into /home/default that checks that state and adds content to the page dynamically based on the state.
If you do this server-side, then the state can be stored in a cookie or in some server-side data store and then when the /hoome/default page is rendered, your server side page rendering process can check the state for this particular user and modify the rendering of the page to include the desired content.
You have a plethora of options. The best solution depends on how your application is currently implemented -- whether in a framework or not, with sessions or not, etc. The principle whatever method you choose is almost identical: store a value and then retrieve it later.
Single Page Application (SPA)
If you aren't already using a framework, I would urge you to consider migrating to one as tasks like these are made infinitely more elegant in their implementation.
Service / Data Store
If you are building an SPA then you may not have to consider any of the options below... so long as it doesn't matter if the data is lost if the user performs a 'real' navigation that cannot be intercepted by the framework (for example, refreshing the page).
In Angular you can maintain a temporary data store in the form of a service. Simply store the data and then pick it up later from another controller. Similar functionality can be achieved in all other popular SPA frameworks:
Angular
Ember
React
Local Storage
Local Storage is available in IE8 and above and has a really simple API.
Angular: angular-local-storage
React: react-local-storage
Ember: ember-local-storage-adapter
jQuery: jStorage
IndexedDB
If you're into the cutting edge and aren't tied down by browser support, consider using IndexedDB. I don't recommend using this unless you are wanting to persist large amounts of data remotely on the client's machine. (It really does have bad support at the moment.)
Angular: angular-indexed-db
React: ???
Ember: ember-indexeddb-adapter
jQuery: jquery-indexeddb
Cookies
If your application is inflexible then cookies will be the easiest and least time-consuming. However Local Storage may be a contender.
Angular: $cookie service
React: react-cookie
Ember: ???
jQuery: jquery-cookie
Related
i want my all check boxes checked whenever i come back from other pages, i want to maintain their states across pages using javascript.
I think you are asking how to store state for an individual session between requests. In this case, that state is checkbox values.
You have a choice to make first: do you want to store the data on the client (in the browser) or on your server?
Server Side
You can store this state on the server side with or without a "database" depending on how pedantic you want to be about the term.
If what you want is to avoid configuring an SQL RDBMS, you might find that the built-in storage options from most Java Servlet containers will work. In Tomcat, you can just use your Session objects as normal, but configure a "File Based Store" instead of a "JDBC Based Store." This will store session data to disk in files. Alternatively you can use StandardManager which uses in-memory storage, but does not persist session state across restarts.
Put simply, these will create a Java Map for each JSESSIONID issued by your server, and then keep the maps in memory, on disk, or in a JDBC database. For more information see: https://tomcat.apache.org/tomcat-7.0-doc/config/manager.html
Client Side
Here you have a few options as well. The driving factor is what level of browser you wish to support. If you can tolerate restricting your users to those who use a browser with HTML5 web storage and JavaScript enabled, things are pretty easy. If not, you can accomplish the same thing with a cookie.
The big downside to client-side storage is trust. Users (or software on their computer) can modify client-side storage. This goes for cookies, localStorage, and sessionStorage. Many developers forget this and introduce security vulnerabilities because of it. If this is for a real production web application, you'll want to wrap your state in an authenticator.
Here's a the first in a three article series on a way to convince your servlet container to put session state into cookies in a way that is transparent to your servlets. It is missing authentication, but you can add it by following guidance such as this bit from Rob Winch.
Now What?
Ok. You've decided to use client- or server-side storage for your checkbox values. Now what?
A simple (usually wrong) option is to store the checkbox input names and values in a map:
{"boxFoo": true,"BarBox":false}
The reason this is usually wrong is that it fails to distinguish which form your user was visiting. It means that if you apply this strategy to more than one form on your site, you'll have to worry about name collisions.
The next evolution is to have a structure keyed by form name and then field name. This would be a map like the following:
{ "formA": {"boxFoo": true,"BarBox":false},
"formQ": {"checkAlpha":true,"BetaCheck":false } }
This works, but will have annoying behavior when your users use multiple tabs. You can make that behavior more predictable for your users by using per-tab identifiers -- at the expense of space in your session object -- or by using AJAX to keep the fields in sync -- which has its own perils. Or you can do what most people do an just assume that the last submitted form overwrites the state from all previous ones, tabs be damned. That's much simpler to code, but more annoying to users.
I can propose some ways :
send http params (in hidden field) with check boxes flags which must stay checked in each new page requested by your application . You can factorize it with a function but it stays cumbersome to do.
store the check boxes marker flag in the http session. If the check boxes must stay checked in all the life of your user, it may be a suitable solution. Use may use a backing bean session for it as you use JSF.
Nevertheless, store the minimum of information in it.
store the information in a shared applicative cache to retrieve it. In this way, you stay stateless and you have not the drawback of the session if you use clustering in your servers.
There is maybe better as alternative.
You have to bind the value with a backing bean. As long as the backing bean is having the appropriate scope it will be retained on the page when you navigate to it.
We had a silverlight application that maintained state when clicked on links and come back to it.
I was wondering if there's a way to implement something like that using Asp.net MVC? Basically right now user goes to a search page using a link in the banner, in the search page we display some items.. user clicks on one of them and another page opens up taking him to the main page that list that items information. From there the user can again click on search but this time of course a new search window opens up.
Am wondering if there is a way to load existing content form the already opened window into the new search window?
If it makes any difference the search page is ajax enabled.
As Shyju has pointed out, Http is stateless. There are several ways to store and share data between multiple pages in web applications.
Just to name a few, you can use:
Cookies (do not save security sensitive data such as passwords in
cookies)
Sessions
Browser's local storage (http://www.w3schools.com/html/html5_webstorage.asp)
In MVC, you can use ViewBag, ViewData or TempData
You can pass data as query parameters in URL
You do not want to maintain the state in ASP.Net MVC. It is a bad practice.
If you want to pass state between action methods, you can use TempData.
It uses Session State under the hood, and clear it automatically right after you retrieve the data.
ASP.Net offers some addition methods in addition to TempData. You can read more here. In your scenario, TempData is a best choice.
As we all know, HTTP is a stateless protocol, each HTTP request does not know about the previous request.
ASP.NET also provides state management techniques that can help us to maintain data when redirecting from one page to another. There are several ways.
Hidden Fields (is used to hide your data on client side. It is not directly visible to the user on UI but we can see the value in the page source).
Cookies (are used for storing the data but that data should be small. It is like a small text file where we can store our data, This are stored on client side memory in the browser).
Query String (generally used to pass value from one page to the next).
View Data (helps us to maintain the data when sending the data from controller to view. It is the dictionary of objects derived form ViewDictionary).
View Bag (same as View data, except the only difference is that view bag is the object of dynamic property).
Temp Data (is also a dictionary object as ViewData and stores value in key/value pair. It is derived from TempDataDictionary. It is mainly used to transfer the data from one controller to another controller).
For rapid prototyping of my concepts, I'm using Express with Mongo and so far have set up a mongostore cookie storage system.
My question: Is it possible, after logging in/authenticating/etc, to have everything occur on the same page, aka '/game'? I still want multiple views and routes to be rendered, but using different areas of the screen, or overwriting elements on the screen, with the base game.jade still visible.
I essentially want to have the user on the same URL the entire time, but still use multiple routes and views. I looked into stuff like '/game/:stuff' but that still changes the URL I think.
FYI this is called a single-page web application.
One common way to do this is to route to different views using the hash token. For example, all of the following URLs would be part of the same page:
/game#introScreen
/game#level1
/game#level2
Your client code can respond to changes in the hash portion of the URL and change the display accordingly. The page does not reload and all your JavaScript code (and variable state) remains in place.
If you're using a framework like angularjs it can help do the routing for you.
I have two html files which are the two pages in my application
Page 1 = Home.html
Page 2 = Stats.html
When Page 1 is loaded, I am making AJAX calls to the Facebook API which returns some data and then I want to build a table using that data.
I then want to keep the table in memory and append it to a div on Page 2 when the user navigates to Page 2.
In this way, the wait time for the user is drastically reduced because in the time it takes them to navigate from Page 1 to Page 2, the majority of the work by the browser has been done.
Stats.html page should look into cached data which is fetched from Home.html. This is technically perfectly possible.
Before I give some details, ensure that the code that fecthes data from Facebook API is the same used between your two pages. The idea is to create a function that:
Looks for cached table data and retrieve it if found
If not found, fetch data from Facebook API and store it in the cache
Return the table data
Remember clearing or overriding the cache time to time.
In order to properly store data, there are two main ways:
Cookies
This is the traditional way to store data across a website. These are sent to your server at each request, which is not actually necessary but still helps you client-side. Cookies are controversial because subjects to many security flaws, so I wouldn't recommend using them.
Local storage
This is more modern in browsers, but less compatible with old browsers. This allows you to store data across a web site. This method is getting more and more common, I think you should use this. On top of that, I recommend using an helper library in order to ease the storage, like store.
More info about web storage at Mozilla's.
I'm controlling a d3JS interface from another platform. The workflow: Data->Python to create JSON->d3JS to generate graphic->load the html page locally in a browser.
Is anyone aware of a way within this workflow to force a page reload when the JSON data is updated?
This is essentially a problem of how to push updates from the server to the client.
There are two approaches:
Fake it. You could use AJAX polling to periodically ask the server whether new data is available.
Do it for real. You could use WebSockets to push the data from the server to the client when an update occurs.
With the new data in hand, it should be simple to bind in D3 via the General Update Pattern. See http://bl.ocks.org/mbostock/3808218
If you must reload the page, you can also use either of these approaches to trigger it.