I have a form that sets input fields as enabled / disabled based on some radio buttons and a checkbox. If the user navigates forward then hits the back button, the field values are retained but the enabled state reverts to the default. Is there a way to handle this via javascript?
You could try invoking your javascript function that enables/disables DOM elements based on radio button selections in the DOM ready event (window.onload). This event will be executed when loading the page from cache and normally it should wire up the enabled/disabled state of those elements.
The best answer here is: "It depends".
I'll explain.
This depends on how wide a browser audience you want to support. In most modern browsers, you could try and capture the DOM elements and values of the buttons in a Javascript / JSON block then push that into a location like window.localStorage or even in a cookie ( a cookie would be your best bet if you want this to work on older browsers ).
Once the user then traverses back, you could check for the value or values and re-establish button state then on load of the page.
However, if you are using a Javascript framework such as jquery, I would recommend taking a look at this:
http://archive.plugins.jquery.com/project/DOMCached
This will allow you to perform the same stunt as I just described, where you could capture the button parameters into a JSON / Javascript data object, store via DOMCached then access later when the user returns to the page itself.
Related
When filling out a form on google chrome/edge(doesn't happen on firefox), then pressing the back page button, then forward page button you get a weird situation where the browser maintains the information in the form. The issue comes when on submitting the form none of the values are saved to the $scope values associated to them.
How can I either disable google/edge from doing this or make it so when they do it the $scope is updated?
I agree with what Dean Van Greunen has said. Configuring autocomplete inside <input> will only disable the autocomplete feature of the attribute-applied <input> element. You will not worry about the browser's autocomplete feature.
What's more, "Forwarding" the "backwarded" page will preserve your data according to this doc:
For example, if the user makes changes, clicks Back and then Next, those changes should be preserved. Users don't expect to have to re-enter changes unless they explicitly chose to clear them.
So if you don't want the browser to preserve your data, you can either clear the data before "backwarding" the page or simply disable the input autocomplete feature. Also, simply moving the page back and forth will not trigger the $scope to update.
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.
Assume I have a dialog with some checkboxes, radio buttons, text inputs etc that represent some options. I open this dialog by clicking some link on the page. I want to be able to save options as well as cancel by clicking Save and Cancel buttons inside the dialog.
Processing Save button looks straightforward - I just go through the controls and get current values. What I wonder about is how I should better control Cancel button. So, I change some options inside the dialog, then change my mind and click Cancel button. Obviously I need to return all controls to their state before changing.
How do I better do this? Should I save current state on dialog loading to some hidden fields or attributes? Please share your thoughts.
I would make a copy of the current state when opening the dialog, modify the copy in the dialog, and when the user presses a button, replace current state with the new state or simply delete the copy accordingly.
You could just use the built in reset to return the form values to default, then process a save, which would essentially return the state to the original values before changes were made.
You can save the currently saved state within data attributes. In HTML such attribute looks like data-something="some value", but you can simply access it from JavaScript. Eg. jQuery has shortcut for it, which looks like jQuery(element_selector).data('something'). You can also set it from JavaScript like jQuery(element_selector).data('something', 'some other value').
Using that mechanism you can initially set these values and with each save overwrite them. In case someone clicks "cancel", you will just restore your controls / form elements to the state matching the value you store as data associated with that element.
Just keep in mind such data is associated with DOM elements, so deleting them you will delete data, but it is very clean and flexible approach in such cases.
More:
on data- attributes: http://ejohn.org/blog/html-5-data-attributes/
jQuery's implementation: http://api.jquery.com/data/
I use a small JS to mark entries as Read upon click, before the user goes to the entry page.
When the user clicks Back, the removeClass I used doesn't seem to keep its effect.
Is there a way to force this on Back behavior?
IE 8, Firefox and other browsers remember form entries on a back button press. You can use this to store some state in a page for when the user hits refresh or back.
Create a hidden textarea on the page somewhere and store your extra state in there. I use onbeforeunload to stash the state and then pull it out again with onload.
Unfortunately IE6 and 7 don't support remembering your form values on back or reload, so you would have to resort to something like cookies if you care about those browsers. Remember to keep the amount of data you store in the cookies small since it will be sent to the server on every request. You will also want to have some way of clearing out that cookie.
When I want to keep a large amount of disparate state, I use JSON.stringify from Douglas Crockford's json2.js.
When the user clicks Back, the browser reloads the page from scratch (except Firefox, which remembers form values), and the old page's Javascript and its effects are gone.
To work around this, you can persist the page's state in a cookie, then read the cookie when the page loads and restore the state, using a Javascript cookie library.
As suggested, you can use cookies. Or if you don't want to do that, you can store the info in hidden form field(s), and on page load (or domready) read the value and set the page state as necessary.
The only way to do this with JS is by storing a cookie with the items a user accesses and mark the entries in the cookie as "visited" when the page is loaded. The drawback is that there will be a small delay between the items loading into view and them being marked as visited (kinda like the one here on StackOverflow with a user's ignored and favorite tags).
Other than this, you could use some server side code to remember the visited entries in session.
If the entries are <a> elements, you can style them with:
a:visited {}
I have a page that uses jQuery to create a number of <input> DOM elements dynamically based on what user picks from a <select> box.
Let's say the user picks 4 from the select box, my script dynamically shows 4 input boxes.
The problem is when the user refreshes or goes back to this page (with the browser back button). The elements that are created dynamically are not repopulated to their last values, while all the other 'static' elements are.
I was thinking I could create a hidden input that would be serialized through javascript with the contents of the dynamic boxes, then read from it on $document.ready and then repopulate my boxes.
Is there a better way?
legenden - there are a number of possible solutions to this, I would check out these history plugins for one:
History Remote
jQuery History plugin
Deep Linking plugin
They are a little fidgety, but you should be able to hack up something positive. I will also add, that this can probably be done by storing the dynamically elements in a cookie(s) and somehow repopulating. Check out the jQuery Cookie plugin. Hope that helped you get started.
You need to manage history yourself if you want things to work in this way. You need Really Simple History.