I have a radio button field on a lotus notes form (say main form). If it is selected as "Yes", a link gets unhidden. On click of this link, another form opens up. If in the radio button, "Yes" is selected in the main form, the contents in the second form must be filled. So I need to write a validation if the radio button field is "yes" and the field inside the second form is not filled, then it should show a popup asking to fill the field in the second form. How do I get the value of the field in the second form on the main form for me to perform the validation?
You literally cannot do what you've described you want to do. The second (pop-up) form and its content no longer exist in the client (browser) context when you want to do validation on the first form's data. There are three possible ways to tackle the problem but only two of them are actually practical.
Let's dispense with the impractical method first. That would have the pop-up form write something back to its parent/opener, either as a JavaScript variable or as DOM content (a field outside of the Domino form or hidden element or some such) or, perhaps as a cookie value. Setting up the opener relationship reliably can be a problem cross-browser, but it is doable. The problem is that no matter how you do this, you have no guarantee that the value will be there when you need it (or expect it) except when the parent form is initially filled out. If the document is ever edited, you have no way of knowing whether or not the user has filled in the data on the pop-up. Anything you may have written to JS variables or the DOM during the initial session with the form only exist during the initial session. Cookies aren't permanent; they can be cleared by the user even if you try to give them eternal life via the expires value. No matter how you do it, you'd be telling anybody who has previously filled out the data you want that they need to fill it out again.
The second method would be to make a call back to the server to see if the pop-up form has been submitted and turned into a Notes document. That doesn't scale at all; even if everything is happening on a single server, there's no way to guarantee that the document you are looking for will have been written and indexed by the time you need it, and there is a time factor involved. If the user has already seen the validation nagging once, does what you tell them to do, and then gets the nag again, you're not making any friends.
The third method is to do everything you need to do on one form. (You can use CSS to do the pop-up if you're married to the pop-up idea.) And, you know, it really doesn't matter at all whether or not you would prefer to do it another way, it's the only way that will be reliable and make happy users. Yes, it will mean a little bit of extra work on your part. You're a developer - that's what you do for a living. You can even keep the structure of the existing application intact; WQO and WQS agents mean that you can glue documents together before sending them to your user, and pull them apart again before you save them. This is the only method that is guaranteed to be fast enough and reliable enough to be usable on the web.
Creating a custom user click tracking script. Need to know what is the best optimal solution to track user click without sending Ajax request to server on every click.
Don't require any code, just figuring out the optimal solution.
any suggestion will be helpful.
I would create an array or use localStorage in javascript to store all the clicks and targets, then simply store them every so often or when the user navigates away from the page window.onbeforeunload.
I have a bit of an issue with page formatting when I navigate away, and then hit browser back to a page.
Here is an example:
I have security questions on a form in a drop down list like so:
http://i.stack.imgur.com/ib32z.jpg
When the user selects [Type in your own question] from the drop down list, I have some jquery that animates a CSS change that pushes the form down, and makes visible a hidden field for 'custom security question'. When selected, the form looks like this:
http://i.stack.imgur.com/uVPKo.jpg
Now my dilemma is when I navigate away from this page, and then navigate back using the browsers back button, my formatting gets screwed up and looks like this:
http://i.stack.imgur.com/5Xhpi.jpg
The javascript that I have written does not trigger again on the back button so the browser doesn't know to move the form back down to accomodate the change in spacing. Is there anyway I can force the document.ready to reload or clear some kind of cache?
Thanks!
EDIT: Sorry guys, I need to reupload the images to a host and repost. Sorry for the delay.
There are basically four mechanisms for persisting state on the web:
Browser-based - the browser, if you're lucky, will save answers to form fields and re-display them when it sees an INPUT with the same name; also, some browsers will preserve some state between forward<=>back navigation
Cookie-based - pretty self-explanatory; you save a cookie with the state info, and check it later to recover the state
URL-based - navigate to a different hash of your URL, with the info you want in it (eg. "?roll_down=true")
HTML5/Local Storage - Look it up if you're interested :-)
We can basically throw 1 and 4 out, because they both rely too much on browser behavior/support, and we can't reliably rely on all browsers to handle them the way we want. That leaves #2 or #3.
Cookies allow you to save more info (as much as a cookie holds, ie. about 4k). URLs allow less info, but they have the added benefit of bookmark-ability; if the user saves the URL as a bookmark (or as a link they send a friend, or whatever), the state still gets preserved.
So, take your pick of the above, decide on how to persist your "my form is rolled down" state ... and then comes the part that (I think) you're really interested in: how do you check this state and fix things when the user clicks "back"?
That part I humbly defer to another SO post, which has already answered it:
Is there a way to catch the back button event in javascript?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am currently building a registration page where if the user leaves, I want to pop up a CSS box asking him if he is sure or not. I can accomplish this feat using confirm boxes, but the client says that they are too ugly. I've tried using unload and beforeunload, but both cannot stop the page from being redirected. Using those to events, I return false, so maybe there's a way to cancel other than returning false?
Another solution that I've had was redirecting them to another page that has my popup, but the problem with that is that if they do want to leave the page, and it wasn't a mistake, they lose the page they were originally trying to go to. If I was a user, that would irritate me.
The last solution was real popup window. The only thing I don't like about that is that the main winow will have their destination page while the pop will have my page. In my opinion it looks disjoint. On top of that, I'd be worried about popup blockers.
Just to add to everyones comments. I understand that it is irritating to prevent users from exiting the page, and in my opinion it should not be done. Right now I am using a confirm box at this point. What happens is that it's not actually "preventing" the user from leaving, what the client actually wants to do is make a suggestion if the user is having doubts about registering. If the user is halfway through the registraiton process and leaves for some reason, the client wants to offer the user a free coupon to a seminar (this client is selling seminars) to hopefully persuade the user to register. The client is under the impression that since the user is already on the form, he is thinking of registering, and therefore maybe a seminar of what he is registering for would be the final push to get the user to register. Ideally I don't have to prevent the user from leaving, what would be just as good, and in my opinion better is if I can pause the unload process. Maybe a sleep command? I don't really have to keep the user on the page because either way they will be leaving to go to a different page.
Also, as people have stated, this is a terriable title, so if someone knows a better one, I'd really appreciate it if they could change the title to something no so spammer inviting.
As soon as I saw the words "prevent the user" I started to wail in agony. Never prevent the user, only help them.
If they see your registration page and run off, that's their choice. Pop up a javascript confirm box if they've already filled in some data (because they might be navigating away accidentally) but leave it at that. If they haven't touched the form, leave them alone - they don't want to fill in your form.
Look at other methods of engaging users. If your form is huge and scary, break it into simple manageable chunks or better yet, simplify things so much that the user only gives you data when you need it. For example, you might not need their address until you want to post something to them.
By breaking it into multiple parts you can hook them with a simple form and once they've invested that time, they'll be more likely to continue the process.
But don't harass users. If they don't want to register, pestering them with pop-ups and jaavscript dialogues will just chase them off the site completely.
With that in mind, assuming you're just trying to stop people half-filling-in forms, there are a couple of options to genuinely help people:
Detect if the form has changed and ask them a simple confirm() message.
This is all you can do. A CSS "pop-in" just won't work because you can't control* the window location in the unload event.
*You can put an event listener on all your page's links to fire off something to check the form, but this only helps if the user clicks on one of those links. It won't help if, for example, the user clicks back or closes the window. You could do both CSS and javascript but you end up with a bit of a mess.
Persist the state of the form behind the scenes.
An extension to #1. Instead of squabbling with the user, let them go where they want but save the content of the form either to session or cookie (if it'll fit) and put something on the page (like SO's orange prompt bars at the top of the page) that reminds them that they've started filling in a form and gives them a link back to the form.
When they click that link, you load the data out of the cookie (or session) back into the form and let them carry on. This has the clear benefit of letting them do what they like on your site and keeps the data safe.. ish.
If they don't come back and their cookie/session expire, that's their fault. You can only lead a horse to water. It's not your job to force it to drink.
Don't do it.
But if you want, try this. Record mouse positions and detect a quick upward thrust -- the user is reaching for the BIG X or the top left or top right. Now might be your chance for an unobtrusive box in the screen.
I've seen this implement on the web and it is evil.
If you want to trap links, you could rewrite the links in the page to go to a "you really want to leave?" javascript function, passing the destination URL as an argument.
If you wanna keep users from using their "Back" button, or keep them from putting another URL in the address bar, stop. Stop now. (1) Browsers were made to prevent exactly that kind of obnoxious behavior, and (2) Even if they allowed it, see the last two words of (1). It's freaking rude. Your site is not that special, no matter how cool you think it is.
window.onbeforeunload = function() { return "Message"; };
Use a JavaScript like this to display a leave confirmation message.
Here are just a couple of approaches I could think of but they are not without flaw:
Whatcha Gonna Do technique
Detect the mouse position going towards the edges of the browser as the user might be going to close the tab, window, go back, navigate elsewhere among other things. If so, immediately prompt them that that may be a mistake and they are going to lose out on something very valuable. However, the catch here is that you don't know for sure what their intentions were and you might piss them off with that popup. Also, they might use a bunch of shortcuts such as Ctrl+W etc to do the same.
You've Got Mail technique
If you've managed to get hold of the user's email address before they closed the page, you've hit a jackpot. As soon as the user types anything into the email box and then leaves it, immediately send it to the server using AJAX. Save the state of the page into localStorage or on the server using a cookie or something so it can be recreated later. Every couple of hours send them an email giving them a direct link to the previously saved form, and maybe with special offers this time.
History Repeats Itself technique
Then there's the infamous history manipulation where you keep stacking the current page into the document history so the back button renders effectively worthless.
Don't Put All Your Eggs In One Basket technique
Another technique off the top of my head is to create multiple windows in the background with the registration form and keep them all in sync when any the fields in any one changes. This is a classical technique and really puts the "don't put all your eggs in one basket" saying into real-life usage.
Another advantage of this awesome technique is even if the user closes one of the windows, and later comes across an identical cloned window with all the fields they filled up-to-date populated, they might get confused and think that they never closed the page. And guess what, this time they might just go ahead and fill out the registration form. But you have to be cautious with this as anything more than 2 or 3 clones will make it obvious as to what's going on.
You're Winner technique
Another technique is to tell every user they they are the Xth visitor on the site and use a good rounded number for X such as 1000, 10000, 50000, etc. Tell them that they can claim their prize once they register on the site. Imagine how special each user feels when they land on your site. The prize doesn't have to be anything tangible, it can simply be free coupons that you find on the intertubes.
Where Do You Want To Go Today? technique 1
This is basically a rip-off of your answer. Use document.location.href = 'some url' inside your onbeforeunload callback to navigate to a different page before it is unloaded.
1 Firefox only.
Note: there is no silver bullet solution here unless you write your own browser with your own security policies, but these are all optimizations that you can do to make it utterly impossible for users to leave.
Not all browsers support a modal popup, without which your page would go ahead and navigate anyway.
This is real awful requirement. The sort of requirement that is reasonable in a desktop application but entire unreasonable feature of a web site. Imagine being unable to leave a website.
The answer is either use the horrible confirm box and lump it. Or don't ask the user to enter too much data per page. Use a step by step wizard style data entry, the loss due to accidental navigation is minimised.
You can change the Value of the url using document.location.href = "www.website.com"
I can accomplish this feat using confirm boxes, but the client says that they are too ugly.
If the problem is the ugliness of the standard JS popup boxes, try something like this: http://www.sohtanaka.com/web-design/inline-modal-window-w-css-and-jquery/
Apart from that I second what most people are saying: do this with extreme caution if you don't want to lose users.
I'm having hard time trying to figure out how to auto-save user data in a form when the browser is being closed or user changes the page. The onBeforeUnload event is OK when you want to open a dialog box, but by then it's too late to save the changes (except if you just block the browser in the onBeforeUnload handler long enough for it to pass the request to the server...but I'd rather not do that).
I am sure some of you have had to deal with the unsaved form problem. What do you do? Do you:
let users just lose their changes,
ask them using a modal window if they are sure they did the right thing,
save individual fields on the fly as they change,
or do you have some ultimate method to automagically save the data when it's about to be lost irretrievably?
•ask them using a modal window if they are sure they do the right thing,
Closing a window is an act of cancellation. As the user never actively submitted the form, theres no guarantee that they want the data saved (it may not be correct), and you saving the data could cause problems for the user.
I like your third option:
save individual fields on the fly as they change.
I'm having to deal with a similar situation, and that's what we are doing. The two main things that sell that to me:
Improved user experience - the user
will be impressed by a form that
does not lose changes. They are
'committed' once they are validated.
E.g., he types in a valid email
address, and it is saved instantly,
furthermore he is provided some sort
of feedback for each field that is
successfully been saved (a green
tick for example, appears next to
the field).
No more 'oh crap my browser crashed
and I lost all my info' situations.
Disadvantages: The extra man-hours involved in developing such a solution, and the possibly that it ends up not degrading as nicely as a simpler solution. That said, it is still worth it IMO.
In any browser I have used it in, onBeforeUnload provides you with a modal window which asks the user to confirm whether they want to leave the page or not. You can added your own text warning them that there is unsaved data, to help them decide. You don't want to explicitly save without the user's request, because a) the user did not attempt to save, and b) if you need to throw any validation errors it will be too late as the page is already in the process of navigating away.