We Keep Coding

disable viewing past content/history in html

I've got an html from on a public access tablet.
Is there a way to reliably prevent a user from going back in history to view past form submissions?
I'm looking to solve it either server-side or using javascript, or combination of the two.
I tried javascript code that prevent the back action, but it only works on the immediate back, press and hold to view further back options still allows going back.
The form is set to remember values when submission fails, but should not be able to get them after a successful submit.
is this perhaps better to do using sessions and handle using php?

There are many ways to prevent re-submission of forms through clicking the back button:
One way is to set all the form fields to be empty, this can be done on load of the page.
You could use sessions to ensure that the user has already submitted the form.
Cookies and/or local storage can be used as well.
However, querying the database to check for duplicates or resubmissions, or setting the form fields to empty strings on the client side would be a better option, as a user could delete cookies and clear local storage.

how to maintain check boxes state across jsp pages whenever you come back on a page using javascript or jsf without storing it into database

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.

How to implement "Don't show it to me anymore" in GWT?

I am coding an application, there is a drop down in GUI contains values that are directly from back end data. However, there is a new requirement coming, when user is browsing the drop down and click delete button from keyboard/right click mouse, we should hide the value in drop down and don't show it anymore in GUI, but I don't want to delete the hided value in back end database.
The difficulty for me is how can I store the filtered drop down list values in my GWT java code? Any ideas? Thanks!

It sounds like you want each client to have data stored on what they've deleted. Instead of having to track each client's decisions in the database, you should have the information stored on the client's machine. This can be done in a preferences file, HTML5 Storage, etc depending on what kind of client it is. If the client changes computers, their data won't be saved, but I don't think that's unexpected behavior. It really depends on the application and what you expect. Either way, store the client and their deletions in a separate table or on their own machine.

Save Form Data for when user returns

Here is my problem...
We have a very large Form with many inputs and check-boxes, the problem happen when the user's pc disconnects he then need to restart the form.
After doing many Google searches I've found a few solution but i have no exp using any of the following and would like to know which solution is better used.
Save a session with post variables so that when user returns his data would be saved. (problem is with session destroyed when browser leaves page.)
Save the post variable to a temporary table, and if host name of user is there to populate the form to continue where he left off. (Probably the simplest way)
Session Storage and Local Storage, Both of these seemed like a good alternative but haven't seen any examples or any docs on how this can be used to populate forms.(No Exp with this.)
I'm thinking of using the second option and just wiping that table after 1 hour but would like to know which is better in terms of what is more widely used for this solution.
Thanks

you can send the data with the onBlur on the textfields with ajax post to a php file which writes them into the session or a coockie or a database.
Session ends when the Browser(not the tab) has been closed. Coockie must be aktivated by the user. So i think the temporary table is the best solution for you.

Internal web page to retrieve, save and store information?

(I apologize for any incorrect lingo)
I am creating an internal web page as a sort of intranet for me and another associate to use in our department to keep track of information. I have created "pages" using HTML to navigate and saved in our department folder. Doesn't need to be flashy just functional.
I have a table with 5 columns of information for each item we need filled out. I have created a pop-up window and form for these 5 columns to open and the idea is that when the the user (me) fills the form out and clicks the submit button, the information is transferred to the parent page, saved and stored for later tracking.
I'm assuming this isn't possible by just saving .html files into our network folders. I think i might need a database to "save" the information the user filled out.
I wouldn't necessarily need the window pop-up..
Is this way over my head?

You would at least need a server side language such as PHP. Using a Database is highly recommended.
In my very humble opinion - Yes, it does sound as if this is over your head right now.
Recommended readings:
http://www.amazon.com/s/ref=nb_sb_ss_c_0_3?url=search-alias%3Dstripbooks&field-keywords=php&sprefix=php%2Caps%2C129
Let me know if my answer is helpful.