In my HTML markup I have an input of type text which has a two-way binding (using ng-model) to a decimal property. The object which contains this decimal property is fetched using a Breeze query on the client side. I can see that the Breeze query has successfully fetched the data and can see the initial value of the property (i.e. 1.25) in the text input. If I delete the decimal point and try to type it in again it will not allow me to do so and at this point I can only type in a number - effectively what I end up with is an integer value.
Can anyone tell me if Angular or Breeze is doing something behind the scenes that is limiting a text input to only being able to accept numbers instead of any text. I've inspected the input element in question in the browser to see if anything extra was "bolted on" that may have caused this but nothing jumps out. The "fix" or workaround would be change the input type to number and set the step attribute to "any" but nevertheless I would still like to understand the cause so any help will be greatly appreciated.
Thanks
I'm having the same issue and I think the problem is that due to the two-way binding the value is expected to be valid at any given moment. Apparently "1." is not a valid number so it doesn't like it. If you type "125" and then go back and insert the "." it will accept "1.25".
My current solution is to use debounced updates:
<input type="{{type}}" ng-model="ngModel" ng-model-options="{ updateOn: 'default blur', debounce: { default: 1000, blur: 0 } }">
If you do not want timeouts at all you could use just:
ng-model-options="{ updateOn: 'blur' }
More on this here: https://docs.angularjs.org/api/ng/directive/ngModelOptions
Depending on your localization settings, the numeric input field may accept only numbers and commas (not decimal points). As the validation is done on unser input, angular is able to set the value with the decimal point without failing.
By the way, why would you want to use breeze, when AngularJS has all you need to link your fields to the model?
Related
This has confused me since the early days. Maybe it's just in my head, but it seems to me as if this has varied over time, between browsers, and possibly even depending on the local language/locale.
Basically, whenever I need to check if a HTML input of type "radio" or "checkbox" has been set, I always do:
if (isset($_POST['the_name']) && trim($_POST['the_name']))
// do stuff
This just makes sure that the POST variable is sent whatsoever (which in itself doesn't mean that it was actually checked/selected, as far as I can tell, since its "value" can be an empty string) and that it's something other than '' (empty string). It seems like this has worked for a long time, but I have two problems with it:
It's ugly. I need to abstract it into a function, but then I want to know if it's a good idea in the first place, or wrong somehow.
It makes the assumption that any non-empty string value means "checked" or "selected", whereas the standard may say a specific string value such as "on", or maybe any number of such strings depending on the language/locale.
Are there cases where my above code falls apart? Do browsers ever submit POST forms where they include names which have no user input/selection in the HTTP request? Or does the existence of a name in the POST blob mean that that "field" has been actively changed/set/checked/selected?
The idea behind checkboxes is that the value is sent over to the server only if the checkbox was checked when submitting the form. The value can be anything, even an empty string. As long as the field is part of the transmitted form it means the box was ticked.
The value attribute is one which all <input>s share; however, it serves a special purpose for inputs of type checkbox: when a form is submitted, only checkboxes which are currently checked are submitted to the server, and the reported value is the value of the value attribute. If the value is not otherwise specified, it is the string on by default.
This means you could have a form like this:
<form action="" method="get">
<input type="checkbox" name="c1" value="">
<input type="submit" value="Send">
</form>
If the checkbox is not checked when submitting then $_GET will be an empty array.
If the checkbox is checked then the value of $_GET will be:
array('c1' => '');
To check whether the box was ticked when sending the form you only need isset()
if (isset($_POST['c1']) {
// The box was checked!
}
Sometimes you would like to assign a value attribute to your checkbox. In such situations you can use the shorthand operator for isset() function ??.
// Create a variable from the checkbox value or assign an empty string if the box was not checked
$nyCheckbox = $_POST['c1'] ?? '';
I'm using standard HTML TextBoxFor helpers in an MVC5 project and wanted to set a textbox to accept numeric values only.
So I've set the type to be number.
#Html.TextBoxFor(model => model.PP_IMP_M1, "{0:0}", new { #type ="number"})
I'm not sure what the functionality of the HTML input type=number is supposed to be but when I type only letters in the textbox and tab out, the textbox clears itself as the value was not numeric. This is expected and correct.
However, if I type the first character as a number and follow this with random letters then the mixed text value remains in the textbox. I know the character 'e' may have been acceptable but I'm entering things like '12hgf' & '45dddd' and the textbox accepts the value after I tab out.
Is this the expected behaviour for an input with type set as number?
I was hoping the type=number would only accept numeric values without me having to use javascript or jquery.
Any help on this issue would be appreciated.
Shuja
Firefox seems to submit input fields of type number as decimals independant of its visible value (e.g.: visible value: 1, real value/posted data: 1.0).
My backend cannot handle it as it expects an integer.
But I still want to use the number type as it handles the keyboard layout on mobile devices.
I already tried to set the step attribute to 1 (which is default anyway).
Sorry, but you are stuck with this way of formatting number fields if you want to keep using that type of control.
What you can do is create a hidden input that is updated when the number input field changes. You can format the value you put in there the way you like to.
So in short, the best thing is to get your backend straight, but that might be out of your hands. Else you can use the workaround provided.
Well actually it’s not a bug; the form field is behaving as defined by the W3C.
Numeric input fields can take additional attributes “min” and “step”, which constrain the range of values allowed in your input.
This is because the default step is 1. So far, so obvious.
However, the step attribute also determines which values are valid, so a step of 1 means you can enter 1, 2, 3 etc. and a step of 2 means you can enter 2, 4, 6 etc, and when you click the up/down buttons the number will increase/decrease by 2 each time, but entering 3 or 5 in the box will cause a validation error. You can also use a decimal value: for example, a step of 0.3 will allow values such as 0.3, 0.6, 0.9 etc, but not 1 or 2.
I was completely wrong. I filled the input from my backend and it was a double value. When using the type integer it only submits "1".
today i had a discussion with my colleague. The question was whether to use the additonal value attribute for a single HTML checkbox or not.
My preffered way is using a single checkbox without a additional value attribute and in backend doing a check like if
if (request.getParameter(checkboxName) != null)) {
...
}
My colleague argues that is would be more transparent using a single checkbox with a additonal checkbox value attribute like value="true" and doing a backend check like
if (Boolean.valueOf(request.getParameter(checkboxName))) {
...
}
As we want to make a small convention about our internal checkbox handling im now trying to find a "best practise" but couldn't find yet. I saw so far only examples with multiple checkbox with the same name. In this case of course it makes sense for me to use different values.
For me it seems to be a bit overhead using a value attribute in case of a single checkbox since i get always a String with "on" if its activated/checked.
We are using a Java Servlet/JSP MVC environment and im not 100% sure if this "on" comes from ServletRequest.getParameter.
I see reasons for following either method, which means there's probably no noticable difference between them. Whichever you pick will work out fine; just make sure you pick one. You could flip a coin or do a thumbwar or something.
As long as a single approach is consistently used, both will work. Yours is less code and doesn't require boolean conversion, the other´s html is more consistent with multiple checkboxes but will also break if you put the wrong value for whatever reason.
You could always do a bit of both and insert values in html for clarity but check for != null in the code and get the best of both options.
It makes no difference server-side as long as you are not checking the parameter for having a specific value. By HTML5 definition, which just establishes the longstanding practice as the rule, a checkbox element has the value on by default. This means that your server-side code cannot distinguish between data coming from <input type=checkbox name=foo> and data coming from <input type=checkbox name=foo value=on>.
How to input decimal value in core-range, as in given demo?
With 'step' attribute added:
<core-range step="0.5" min="0" max="200" value="{{value}}" ratio="{{ratio}}"></core-range>
I can paste decimal(e.g. 5.5) in the input field but cannot type it?!
That's pretty interesting. I think it's a bug in the core-range element itself (https://github.com/Polymer/core-range/blob/master/core-range.html). As the input gets validated "5." gets overwritten by the number 5 and set as value. Since it is reflected in the input field itself, the input changes to 5. When you paste it in as a whole, the "5.5" stays and is reflected in the input field. That's why it works when you paste it. I don't think there's a work around other than fixing the bug.
Issue opened:
https://github.com/Polymer/core-range/issues/2