I have form with checkbox used in both add/edit mode but have scenario when in edit mode disable the checkbox with its value like checked or unchecked.
I have tried as below but not succeeded,
<input type="checkbox" disabled="disabled" checked="checked">
If an element is disabled, it's value is not posted along with the form, so while the checkbox appears checked, that information is not in the form data.
You may want to store the value in a hidden element, or (better, I think), let the server side script determine the proper default value if it is omitted.
Related
I have the following code:
<input type="checkbox" [(ngModel)]="i.checkt" [ngModelOptions]=
{standalone:true} (change)="recovery(i.checkt,i.TherapeuticArea)">
{{i.TherapeuticArea}}
The problem I am facing is that with standalone:true every checkbox is checked by default and when standalone is false, the checkbox isn't working. Is there any way of setting the checkbox value to unchecked while having full functionality for the user?
You need to set the checked attribute on the input like the following:
<input type="checkbox" [(ngModel)]="i.checkt" [ngModelOptions]={standalone:true}
(change)="recovery(i.checkt,i.TherapeuticArea)" [checked]="i.checkt">
But I would recommend #Florian's comment of using a FormControl to manage inputs from the UI. It will save you a lot of time and makes it easier to maintain in my opinion.
I read about value attributes documentation here. It does not clearly mention why is it required for the input tag.
According to the documentation
"value attribute specifies the value of an element" what exactly does it mean by "value"?
Is it a just for humans to know what exactly a checkbox is for?
Or does the value has anything to do with the backend database?
Is the value attribute just for front end purpose only?
I know this question has been asked previously, but not all aspects of what a "value attribute" is were discussed. So I would like to raise the question again, and have another discussion about it.
Is it a just for humans to know what exactly a checkbox is for?Does value attribute is just for frontend purpose only?
The value property sets or returns the value of the value attribute of a checkbox/radiobutton.
For checkboxes and radiobuttons, the contents of the value property do not appear in
the user interface. The value property only has meaning when
submitting a form. If a checkbox/radiobuttons is in checked state when the form is
submitted, the name of the checkbox/radiobuttons is sent with along with the value
of the value property (if the checkbox/radiobuttons is not checked, no information
is sent).
For example, when you are using <input type="button" name="foo" value="Click"/>, this will assign name 'Click' to your button. Same goes for text field: <input name="subject" type="text" value="Default text" /> will show you a text field with 'Defaul text' in it.
Value is where the actual value of the field is stored. Try changing it with jQuery or even with firebug and you will see that the submitted value will be changed!
Given <input type="checkbox" name="foo" value="bar"> the submitted data for the checkbox will be foo=bar if the form it is inside is submitted and the checkbox is successful (the main additional criteria for which is that it is checked). The server side form handler can then use that information.
The value is not exposed to the user of the browser (unless they use a developer tool of some kind). That is the job of the <label> element.
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.
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
Here's the html for my button, according to Chrome:
<input checked="" type="radio" class="edit bindable" id="communicationAddresses[0].defaultAddress" name="EMAIL.default">
When I run this in my javascript console, the output output is "false"
$("input[type=radio]:first").attr("checked")
The actual UI element is visibly not selected. When I run this code, the button becomes visibly selected:
$("input[type=radio]:first").attr("checked", true)
Looking back at the html in Chrome, I see almost exactly the same thing I saw before. The only difference is that "checked" is now at the end of the tag instead of the beginning?
<input type="radio" class="edit bindable" id="communicationAddresses[0].defaultAddress" name="EMAIL.default" checked="">
A bit more information: there is another radio group lower down on the page. When I remove this second radio group, the first acts as expected. They are distinct groups. It is possible to manually select buttons from each one.
What's going on here? Why wasn't the button visibly selected to begin with?
##### EDIT
The button was selected to begin with, but wound up getting deselected due to a bug in some event binding code I was running.
The checked attribute corresponds to the checkbox's default checkedness, not its current checkedness.
In other words, the checked attribute corresponds to the defaultChecked javascript property, and not the checked property.
jQuery's $("foo").attr("checked", true) sets the checked javascript property, but doesn't affect the checked attribute.