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
Related
When I open my website I want to automatically start typing in my form instead of the default browser search bar.
from the scren:
I want to start typing in the Google bar for example.
scrn
There is an autofocus attribute in Html 5
<input type="text" autofocus>
From MDN:
This Boolean attribute lets you specify that a form control should
have input focus when the page loads, unless the user overrides it
(e.g. by typing in a different control). Only one form element in a
document can have the autofocus attribute, which is a Boolean. It
cannot be applied if the type attribute is set to hidden (that is, you
cannot automatically set focus to a hidden control). Note that the
focusing of the control may occur before the firing of the
DOMContentLoaded event.
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 have the following form text input like this:
<input name="name" type="text" value="test" id="name">
It will not show the value, if I change the name attribute to something else it works. It is hardcoded and there are no javascripts interacting with it.
Update: It works fine in Internet Explorer and Google Chrome, won't work in Firefox.
Update 2: I was able to replicate the problem.
For example, in my localhost I access /blog/login, the input name shows the value test, which is hardcoded, if I delete the value and reload, without submiting anything, then input name will be blank as long as I reload. If I navigate again to /blog/login, the hardcoded value will be show again.
This behavior doesn't happens in IE and Chrome.
I apologize if this was a silly question, but this is really strange, I guess.
Browsers add names and ids of form controls as properties to the FORM. This results in the properties of the form being replaced.
Browsers also may add names and id's of other elements as properties to document, and sometimes to the global object (or an object above the global object in scope). This non-standard behavior can result in replacement of properties on other objects. The problems it causes are discussed in detail.
A problem occurs when a form control's name conflicts with the a property name of the FORM object.
For example:
Simple Unsafe Name Example
<form action="">
<input type="text" name="name">
<input type="submit" name="submit">
</form>
Result
The element with name="name" replaces the value of the FORM's name property. A similar type of conflict happens with the FORM's submit method and the element with name="submit'. Which will win?
In most cases, the form control wins and the FORM's property is replaced to have the value of the form control, or, if more than one form control has that name, the FORM's property is replaced with a NodeList containing those form controls.
However, in some cases, the FORM's property is not replaced to have the value of the form control with the same name. The examples in this page show that the result depends on the browser, the property, and how the control is added.
http://jibbering.com/faq/names/
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 read a bit on this, but I can't seem to find anything solid about how different browsers treat things.
A readonly element is just not editable, but gets sent when the according form submits. A disabled element isn't editable and isn't sent on submit. Another difference is that readonly elements can be focused (and getting focused when "tabbing" through a form) while disabled elements can't.
Read more about this in this great article or the definition by w3c. To quote the important part:
Key Differences
The Disabled attribute
Values for disabled form elements are not passed to the processor method. The W3C calls this a successful element.(This works similar to
form check boxes that are not checked.)
Some browsers may override or provide default styling for disabled form elements. (Gray out or emboss text) Internet Explorer
5.5 is particularly nasty about this.
Disabled form elements do not receive focus.
Disabled form elements are skipped in tabbing navigation.
The Read Only Attribute
Not all form elements have a readonly attribute. Most notable, the <SELECT> , <OPTION> , and <BUTTON> elements do not have readonly
attributes (although they both have disabled attributes)
Browsers provide no default overridden visual feedback that the form element is read only. (This can be a problem… see below.)
Form elements with the readonly attribute set will get passed to the form processor.
Read only form elements can receive the focus
Read only form elements are included in tabbed navigation.
No events get triggered when the element is having disabled attribute.
None of the below will get triggered.
$("[disabled]").click( function(){ console.log("clicked") });//No Impact
$("[disabled]").hover( function(){ console.log("hovered") });//No Impact
$("[disabled]").dblclick( function(){ console.log("double clicked") });//No Impact
While readonly will be triggered.
$("[readonly]").click( function(){ console.log("clicked") });//log - clicked
$("[readonly]").hover( function(){ console.log("hovered") });//log - hovered
$("[readonly]").dblclick( function(){ console.log("double clicked") });//log - double clicked
Disabled means that no data from that form element will be submitted when the form is submitted. Read-only means any data from within the element will be submitted, but it cannot be changed by the user.
For example:
<input type="text" name="yourname" value="Bob" readonly="readonly" />
This will submit the value "Bob" for the element "yourname".
<input type="text" name="yourname" value="Bob" disabled="disabled" />
This will submit nothing for the element "yourname".
Same as the other answers (disabled isn't sent to the server, readonly is) but some browsers prevent highlighting of a disabled form, while read-only can still be highlighted (and copied).
http://www.w3schools.com/tags/att_input_disabled.asp
http://www.w3schools.com/tags/att_input_readonly.asp
A read-only field cannot be modified. However, a user can tab to it, highlight it, and copy the text from it.
If the value of a disabled textbox needs to be retained when a form is cleared (reset), disabled = "disabled" has to be used, as read-only textbox will not retain the value
For Example:
HTML
Textbox
<input type="text" id="disabledText" name="randombox" value="demo" disabled="disabled" />
Reset button
<button type="reset" id="clearButton">Clear</button>
In the above example, when Clear button is pressed, disabled text value will be retained in the form. Value will not be retained in the case of input type = "text" readonly="readonly"
The readonly attribute can be set to keep a user from changing the value until some other conditions have been met while the disabled attribute can be set to keep a user from using the element
The difference between disabled and readonly is that read-only controls can still function and are still focusable, anddisabled controls can not receive focus and are not submitted with the form