I have a problem with the pop-up:
This page is asking you to confirm that you want to leave - data you have entered may not be saved.
I am using JavaServer Faces and JavaScript, and after navigating away (and saving every data that I need) if on the next page I click on any button, I see the pop-up. So it doesn't even appear on the page when the data was given, but on the next one, where I have just a few buttons to select the next action.
Does any easy way exist, to find out which part of the data is not saved?
Related
1) Enter text in the search
2) it is saved in localStorage
3) press "search", and the page is reloaded,
4) the text entered there in the search bar.
It is working correctly.
But if I start to click on other pages of the website, the search bar is still populated with a value from localStorage.
How can it be removed at the next reboot?
What should I use (not localStorage)?
In your comment you've clarified you want to do:
enter data
press "Enter"
reload page
data entered in the search bar
the next reloading of the data should be deleted
It sounds to me, then, like you don't want to use localStorage or sessionStorage at all. Instead, when sending the data to the server at #2 above (I'm assuming that's what pressing Enter does), return the search bar data when the page reloads at #3 above; use that to populate the search bar. Subsequent refreshes of the page won't have that data (because you won't have sent it, so you won't have echoed it back).
A less reliable solution would be to save the data in web storage (either localStorage or sessionStorage) at #2 above, then on page load see if the data is there, use it if so, and delete it. Then it won't be there on subsequent page loads. I say that's less reliable because if for some reason your page doesn't reload at #3, or while the data is being sent the user opens another page on your site with this search bar thing, they could see search data. That's why including it in the response to the search makes sense.
I have a few divs on a form that are hidden by default (style="display:none;"). When the user clicks a certain radio button, an onclick event executes and exposes the divs. The user is then taken to a review page upon form submit that shows him any errors. If there are any, he clicks the BACK button on his browser to go back to the form and correct them. Caching is enabled so that all of his form contents are there. The problem is, since the form is looking for an onclick event, all of the previously exposed divs are hidden again. Is there any way to make sure they stay exposed when the user clicks back to the form from the review page? I thought a document.ready function would do it, but no joy.
As Yair mentioned, you can use cookies. It cannot be done with pure JS. However, you can also use PHP.
Before the user is transferred to the second page, have JS scan the divs in question, and find which ones are visible. (I'm assuming they all have individual IDs). Store these IDs in a comma-delimited string, or array, and send it as a _POST or _GET to the new page.
Have PHP store it as a hidden value somewhere. You could use a hidden input, or a data-x on something ... as long as it's there.
Have JS on that page that watches for the back click, stops it, and then redirects the user to the previous page, and sends the string or array back to it. Have PHP on that page print it as a JS value, and have JS on pageload show all divs with matching IDs.
Cookies or localStorage if you aim for only modern browsers:
localStorage
Is there any way to make sure they stay exposed when the user clicks
back to the form from the review page? I thought a document.ready
function would do it, but no joy.
You can use cookies in order to manage state in a web-browser. Cookies will help you save the desired user's state.
All javascript code is reinitialized on browser reload. You cannot identify whether the user comes back through the browser.
You can use cookies or local storage to save a value when initial display happens and show/hide the div later on document.ready.
If I have a form, and don't click submit before hand, using standard javascript history.
<button onclick="history.go(-1);">Back </button>
will bring me back to the previous page. However, if I click submit, and error come out (validation).
the back button will bring me back to the same page (the page before the submit error happen).
How can I create a back button where it always bring to the previous page, regardless error of validation.
Thank you
Going by the actual history isn't a great way of doing what you want. What you see happening here, is of course expected behavior, since submitting the form over and over will just add the page with the form to the history over and over. And by design, for security reasons, there isn't a way to check arbitrarily far back to the last page the user was on on your site that wasn't the form.
Therefore, I think a solution in Cake would be better. If the user can only arrive on the page from one place, you could make the button just link back to that page, rather than depending on the history. Alternatively, I would store in session the page that the user came from originally, and be careful to not rewrite it as long as the user stays on the form, and then link to that on the back button.
Here's the situation.
A user goes to the #new action, clicks submit form, and the object is created. The user is shown the show page
The user realizes something is wrong, so they click back (even though there's clearly an edit button there)
The user fixes whatever needs fixing and clicks submit again, thus creating a new object
What I want to do is have the user directed to the edit action when they click back on the show page. It's also got to be IE 7+ compliant. Is this possible?
Another alternative I was considering was creating a random string on a hidden field on the #new page, and using that to check whether the object's already been created.
Thoughts?
I would use in javascript
document.referrer
on the new page to see where the user came from and if it's the created page, you can then do whatever is necessary to go to the edit view.
I have a set of three apps/scripts.
The first allows the user to select a value. That value is passed to the second script, which takes the value, reads a database, and produces XML which is then posted to an Eclipse/Java/RAP application immediately, without user intervention using Javascript "onload'.
After the RAP application is loaded, to the user the back button doesn't seem to work. The back button takes the user to the second script, which gets the same values it did the first time and then immediately forwards to the RAP application again.
We want the back button to work as the user expects, i.e. to take the user back to the first script.
Since using the back button submits exactly the same information as it did in the first pass, including the referrer, the only way I can see to do this is to use cookies.
Is that it, or is there a better way?
Thanks,
Sean.
On page B set a cookie
On page A, detect the cookie. If it exists, clear the cookie then redirect.
One issue: Page A doesn't know if you got there by pressing BACK or if you navigated there directly. If you can live with that, it will work.