I'm using some radio buttons to influence the behavior states of a jQuery widget.
That widget can be used in a form but, since these radios don't contain any actual data, I don't want them to submit noise to the server, or cause naming conflict to whoever will use the widget in his form.
Here are two potential solution starts, not yet satisfying though :
remove the name attribute : seems to work fine for other inputs, but turns my radios into checkboxes : it kills the link between them so selecting one doesn't unselect the others. Is there an HTML way (i.e. other than Javascript event) to bind them without a name attribute ?
disable the input : As expected, nothing is submitted, but the radios become grey and can't be clicked. Is there any way that they stay clickable yet unsubmittable, like disabled at submit time ?
As far as possible, I'm rather looking for a cross-browser solution.
Try call a function before submit, that disables the radio buttons.
function disableBtn() {
document.getElementById('idbtn1').setAttribute('disabled', 'disabled');
document.getElementById('idbtn2').setAttribute('disabled', 'disabled');
return true;
}
Then, in form:
<form action="file" method="post" onsubmit="return disableBtn()">
Try this:
<form>
<input type="radio" name="group1" value="1" form="">
<input type="radio" name="group1" value="2" form="">
</form>
This still uses the name attribute which is required for radio buttons, and it also leaves the inputs enabled for interaction. No JavaScript code, no during-submit patching of the document in hope that the submit will turn out fine and destroying the document before submit will leave no visible traces.
The form="" attribute indicates that these input elements are not included in their parent form. Actually you're supposed to put the ID of another existing <form> element in this attribute, but then again, by the HTML standard, you're probably not supposed to exclude radio buttons from a form. So this hack is the only solution to the problem. (Doesn't work in Internet Explorer, but what does today.)
I'm intending to use this method for radio button groups that are in a data table which is populated from a <template> element. In this case, there will be a radio group in each table row, so their number is unknown. But since the name attribute is the only way to build radio button groups, they'll need to get counting names assigned. Since the table data is put in a JSON field before submitting anyway, I don't need field names for a form submit. Radio buttons do need names for themselves, but this method will still exclude them from being submitted.
Related
How do I force md-select in multiple mode to behave just like
<select multiple required ... >
?
Here is the fiddle, to show what I mean. In this example, my browser doesn't let me submit form without selecting at least 1 option from the select tag.
I want md-select to behave similarly, but I don't know how can I do that - neither putting 'required' attribute nor adding 'ng-require' directive helps.
You can rely on Angular to do the validation for this, rather than the browser. Here's my forked example:
http://codepen.io/anon/pen/rVGLZV
Specifically:
<button type="submit" ng-disabled="myForm.$invalid">submit</button>
To keep the submit button disabled until the form is valid and,
<form novalidate name="myForm">
To name the form and tell the browser not to do its own validation on it.
You could even add some CSS class for ng-invalid to show red around the invalid fields.
EDIT: Make sure you put an ng-model on your <select multiple>, otherwise the required attribute won't work.
If you don't want to disable submit button but instead trigger error when submit button is hit, you can set the $touched property to true to trigger required alert
yourFormName.mdseletName.$touched=true;
Usually, a submit button works fine without a name attribute. However, there are occasions where there's a need to have two submit buttons for the same form, hence making use of the name attribute to identify which button was clicked on the server side.
To clarify I am talking about: <input type="submit" name="foo">
Yes, it is entirely acceptable.
The specification has explicit rules for how to determine which submit button was successful, which would be useless if you couldn't give the element a name.
I was under the impression that the server code (or at least PHP) that parses the POST of an HTML form cannot distinguish between a POST from a form with a checkbox whose value is not "checked" versus a POST from a form that doesn't include a checkbox by that name at all.
For example, take the following 3 forms. If they were all submitted as is, with no manual entry, just using the inital values, then forms f2 and f3 would send the same results:
<form name="f1">
<input type="text" name="txt_1" value="Hello">
<input type="checkbox" name="chk_1" checked="checked">
</form>
<form name="f2">
<input type="text" name="txt_1" value="Hello">
<input type="checkbox" name="chk_1">
</form>
<form name="f3">
<input type="text" name="txt_1" value="Hello">
</form>
In my real application, I'm submitting forms of the type f3, with a checkbox deliberately omitted (different checkboxes in different situations). For any checkbox I left missing, I wanted the back-end to just ignore it -- don't treat it as On or Off, just do nothing related to that field.
After I built it, I was almost going to throw out my work before testing, when I remembered that the back-end would treat a missing chk_1 exactly like it would an existing chk_1 that was unchecked -- and would turn Off the related value in the back-end.
But I went and tried it out, and IT WORKED! And I tried different variations, and they all work. They correctly disregard the fields related to missing checkboxes (while processing the fields related to existing checkboxes).
So, that's great, but I don't know how it's done (or whether it might stop working -- say on another browser, etc.). In PHP, I know that the code isset($_POST['chk_1']) will get the value of the checkbox, and it returns false in both cases: unchecked checkbox or missing checkbox. Is there a way in other server languages to distinguish? Why is this working?
The short answer is that PHP only gets what the Browser sends it. It doesn’t know or care about the form itself, just the data from the browser. The data comes as a collection of name=data values.
Among other factors, the browser will only send a button if
it has a name, and
it has been selected
If the button has no name, or if it was not selected, then PHP will never hear of it. This applies to
normal buttons (<button> or <input type="submit">)
radio buttons (where only one in a group can be selected: if none is selected, then this, too, will be absent)
checkboxes (only selected checkboxes are sent)
So, the short answer is that PHP will never know whether a checkbox is missing or simply unchecked, because neither will be sent to the server.
I have an input field that is filled in from a previous form(so the input is set to disabled on the second page) and we receive null for the value then. This works:
<input type="text" class="boxtpl" name="${field.name}" value="${user?.email}">
but this doesn't:
<input type="text" class="boxtpl" name="${field.name}" value="${user?.email}" disabled="disabled">
Is there a reason why this seems to break the framework?
Disabled controls shouldn't actually be submitted with the form, so what you're seeing is in fact normal behaviour. According to the HTML form specification:
When set, the disabled attribute has the following effects on an element:
Disabled controls do not receive focus.
Disabled controls are skipped in tabbing navigation.
Disabled controls cannot be successful.
The definition of successful can be found in the same document. It's a bit nonsensical to suggest that Play is broken because of this.
If you want to have a form field that user cannot edit while it should still be sent along when the form is submitted, you can use the read-only attribute, or use JavaScript to disallow user input.
Update: as pointed out in the comments, the following points may also offer a solution:
It's possible that Play still keeps the disabled control's form values in the request object, and just doesn't bind them (so you could retrieve them from the request if needed)
Use a hidden field to keep the form value in case you still want to submit the value, but do not want the user(s) to see the control
Suppose I have the following HTML form:
<form>
...
<input type="submit" name="queue" value="Queue item">
<input type="submit" name="submit" value="Submit item">
</form>
How do I know which button the user clicked (without using javascript)?
I looked at submitted data and it seems that when "Queue Item" is clicked then "queue" = "Queue Item" gets sent to the server. And when "Submit item" is clicked then "submit" = "Submit item" sets sent.
Can I rely on this behavior? Is it documented somewhere in the standard on HTML forms? How do you guys do it?
Yes, you can rely on this; it's fully documented here. The specific relevant lines say:
When a form is submitted for processing, some controls have their name paired with their current value and these pairs are submitted with the form. Those controls for which name/value pairs are submitted are called successful controls.
and
If a form contains more than one submit button, only the activated submit button is successful.
Yep you can rely on that behaviour.
When <input type="submit" name="queue" value="Queue item"> is clicked, the field "queue" will be set and "submit" will not be.
Whereas when the other gets clicked, the field "submit" will be set, and "queue" will not be.
If you're not assured by this, you can split them into 2 forms and work on it that way.
You can rely on this behavior. You get the value of the input. I would use javascript to toggle a hidden form value, but since you mentioned no javascript you do not have multiple choices.
It's a standard. Since it's an input tag, and has a value, that means you get the value submitted.
Split the form into two forms, replicating any other inputs needed by the other action. Or, if you really just need to know if the user wants to "queue vs. submit" the item, change both submit buttons to radio selections to toggle between the two options, and have a new, separate "submit the form" button.
In that situation if you want a one-click option, you could use Javascript to detect when one of the radio buttons is selected, and auto-submit the form instantly. (Using Javascript for user interface, rather than form handling)