I want to hide some form fields by default, and only reveal in groups them depending on a checkbox.
If a user shows some fields, fills them in, but then rehides them using the checkbox, will the data submit anyway if the fields have something in them or should I empty them using JavaScript?
The fields will send anyway, but your service which is receiving the post should just look for the value of that checkbox and ignore the values at that point. Either that or you will need to clear the fields.
According to the html spec a field is submitted if it meets the following criteria:
It is contained in the form being submitted
It is of type input, select, button
It contains a non-blank name attribute
If it is of <input type="checkbox" or type="radio"/> it must be checked.
Visibility is unimportant. In fact there are many reasons why something may be invisible incluiding being off-screen. Some techniques such as honeypot fields require this.
So to fully answer your question, if some form interaction demands that you only submit what is visible, you can do one of the following:
Move "visible" elements to be children of the form (prefered way) move them to another parent when not visible (after animation hides them). This should be easiest way I think especially if using jquery. Remember for animations, move hidden elements around to appropriate parents, then animate. Furthermore hidden elements can be easily manipulated with minimal performance since the browser does not attempt to re-render them until they are made visible anyways.
Clear out data (lose user input)
Clear out names of input fields, and re-create the names when they are unhidden.
The third technique is a bit much. I'd do either first or 2nd depending on your specific needs with a preference given to the first.
To keep it short and sweet, use javascript to remove the field. This is easy and quick, and you won't have to extend your server side script to determine what went through. If you want too, store the removed html into a global var, so when they toggle the option the script's back. Hope this helps!
If the form is just getting visibly hidden, yes, the data will still submit despite having hidden them. You need to empty them via JS.
Related
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.
I have a form that has hidden elements in it to create a pseudo-array of comma-separated values that will be submitted to the server through post, where the hidden elements will then be decoded into arrays and processed for storage. To fill the hidden elements, I use visible elements and a button that javascript handles to add values to the hidden elements, clearing the form every time the button is pressed.
Here is the question: How do I get the visible elements NOT to be submitted to the server and only submit the hidden elements in an effort to save bandwidth? Is there a way to create a text entry field that doesn't get submitted with the rest of the form, but that javascript and normal form controls can still access? The goal here is to prevent unnecessary repeats of the same data being sent when the submit button is clicked, AFTER javascript has filled the pseudo-arrays with the data I need.
EDIT: Thanks for the help. The first two answers I got were good, but I chose as an answer the one I thought was a little more detailed and helpful to myself and anyone else who may be looking for the same solutions.
PLAN: I'll have an onsubmit script that disables unneeded fields just before submit so that they don't get sent to the server, thereby saving (a tiny bit of) bandwidth and reducing the amount of information my server-side script needs to do. This keeps it possible to easily use javascript to clear the fields I want cleared while constantly keeping the hidden fields loaded with the CSV's I need.
There are two provabilities that I can think of now:
Put visible input elements outside form tag, leave only submit button and hidden fields inside.
Create an event onsubmit on form element to set disabled property on visible fields. On some browser that may require to additionally remove that event, return false and trigger form submission manually.
You can set the "disabled" property of the elements to true in order to prevent them from being submitted.
So given a layout like so:
How can I include the value of ComboBox in the submission of the form.
Things that have occurred to me:
Include the combo box as part of the form in terms of markup and position it absolutely. I'm don't get how this would work if the page needs to resize and the combo should remain where it it is in this title bar.
On submission use JS to grab the value and insert it in a hidden field as part of the form submission. This would clearly break without JS but the page is client facing and we are willing to stipulate that JS is required.
I believe I have stated all the restrictions so given that is there another approach? If not how should I choose between the above options?
You obviously could use a a giant form tag.
OR
Two forms, changing the combo and submitting does a full post and adds a hidden to the main form. Then sexy it up with JavaScript (prevent the full post back, and remove the submit button on the combo form)
OR
CSS Positioning as you suggest.
With out seeing some HTML its hard to determine the layout you have. But my first thought would be to use Absolute positioning with CSS.
The other option would be to incorporate the entire page as a part of the form, but this may not be possible due to other functionality on the page that may be necessary
I would say use javascript.
have a hidden input field in the form.
on page load, that input is populated with the ComboBox value.
update the value if the ComboBox select is changed.
A little web design dilemma: I have a form with a lot of options, mainly radio buttons but not only.
I want the form to open up gradually, meaning at the beginning only two radio buttons are visible, and after the user picks one, more options appear under the chosen radio button. If the user then switches the pick, the page updates and shows the options under the new pick.
This happens on several levels, say 4 or 5 levels, and at the end there is a submit button that submits only certain inputs according to the branches the user chose. Also some of the branches have identical components even though the initial choice was different.
These are the options I could think of:
Build the complete form in the html body and use jquery to hide and show them according to the choices of the user. This means I have to write sections that repeat themselves twice.
Write nothing in the body, and append new elements when the user makes certain choices. This means the JavaScript is more complicated, because I have to make sure nothing appends twice.
Write an HTML skeleton of the form, and use append to fill it. Then use jquery to show and hide elements. This has none of the disadvantages but seems a bit unaesthetic.
Which one should I pick? Any better ideas?
It really comes down to your knowledge of javascript. The cleanest way would be to append to form using javascript. This way you can avoid having duplicates in your form.
If you are not that familiar with javascript and don't know how to append the form, then I would use javascript to show/hide the different parts of the form.
I think using javascript to append would be the correct way, but I don't see anything really wrong with using javascript to just hide parts of the form.
Probably going to use http://wiki.jqueryui.com/w/page/12137997/Menu
or JStree (http://www.jstree.com/) which I found out about from here http://wiki.jqueryui.com/w/page/12138128/Tree
In my asp.net MVC application I am using in place editors to allow users to edit fields without having a standard form view. Unfortunately, since I am using Linq to Sql combined with my data mapping layer I cannot just update one field at a time and instead need to send all fields over at once.
So the solution I came up with was to store all my model fields into hidden fields, and provide span tags that contain the visible data (these span tags become editable due to my jquery plugin). When a user triggers a save of their edits of a field, jquery then takes their value and places it in the hidden form, and sends the whole form to the server to commit via ajax.
When the data goes into the hidden field originally (page load) and into the span tags the data is properly encoded, but upon the user changing the data in the contenteditable span field, I just run
$("#hiddenfield").val($("#spanfield").html();
Am I opening any holes this method? Obviously the server also properly encodes stuff prior to database entry.
Assuming your server is properly detecting and dealing with XSS attempts, there's no way a malicious user could submit an attack for another user. Unless someone wants to hack themselves(?), it seems secure to me.
I find this approach pretty unsavory. I guess the overall soundness of this scheme depends on what fields you're actually populating this way --
For example, if you store fields that are supposed to be set only once (at the time of record creation) and never changed, this will allow a (malicious) user to change the field values mid-stream by editing a hidden field before posting (very easy to do, for example, with Firebug).
There's no difference here than if you were providing visible input fields and having that form submitted. Simply shuffling the data into hidden fields vs. visible ones would not make a difference.